## Обновить поле сотрудника

`PATCH /v1/userfields/users/:id`

Обновляет свойства существующего пользовательского поля сотрудника. Тип поля `userTypeId` и множественность `multiple` изменить нельзя — для смены типа удалите поле и создайте новое. Передавайте только те свойства, которые хотите изменить.

## Параметры

| Параметр | Тип | Обяз. | Описание |
|----------|-----|:-----:|---------|
| `:id` (path) | number | да | Числовой идентификатор поля (из ответа [`GET /v1/userfields/users`](/docs/userfields/users/list) или [`POST /v1/userfields/users`](/docs/userfields/users/create)) |

## Поля запроса (body)

| Поле | Тип | Описание |
|------|-----|---------|
| `label` | string | Подпись поля. Подставляется в `editFormLabel`, `listColumnLabel` и `listFilterLabel`, если они не переданы явно. В ответах раздела подписи не возвращаются — [Подписи поля](/docs/userfields/users#подписи-поля) |
| `editFormLabel` | object | Подпись в форме редактирования по языкам портала. Пример: `{ "ru": "Табельный номер", "en": "Badge number" }`. Именно эта подпись приходит в схеме сотрудника как `label` |
| `sort` | string | Порядок сортировки в интерфейсе Битрикс24 |
| `showFilter` | boolean | Показывать в фильтре: `true` или `"Y"` — да, `false` или `"N"` — нет. Прочитанное `"E"` можно отправить обратно как есть — платформа понимает его как «включён» |
| `xmlId` | string | Внешний идентификатор для интеграций |
| `settings` | object | Настройки поля, специфичные для типа. Структура зависит от `userTypeId` — [Получить поле](/docs/userfields/users/get) |
| `list` | array | Варианты поля типа `enumeration`. Элемент без `ID` добавляется как новый вариант, элемент с `ID` и новым `VALUE` переименовывает существующий, элемент `{ "ID": 3967, "DEL": "Y" }` удаляет вариант. Варианты, не упомянутые в массиве, остаются без изменений |
| `mandatory`, `isSearchable`, `showInList`, `editInList`, `multiple` | boolean | Принимаются, но к полю сотрудника при обновлении не применяются — [Какие свойства применяются](/docs/userfields/users#какие-свойства-применяются) |

Свойства только для чтения — `id`, `entityId`, `fieldName`, `userTypeId` — при передаче игнорируются: идентификатор поля берётся только из пути.

## Примеры

### curl — личный ключ

```bash
curl -X PATCH "https://vibecode.bitrix24.tech/v1/userfields/users/6007923" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sort": "300",
    "list": [
      { "VALUE": "Сутки", "SORT": 40 }
    ]
  }'
```

### curl — OAuth-приложение

```bash
curl -X PATCH "https://vibecode.bitrix24.tech/v1/userfields/users/6007923" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sort": "300",
    "list": [
      { "VALUE": "Сутки", "SORT": 40 }
    ]
  }'
```

### JavaScript — личный ключ

```javascript
const res = await fetch('https://vibecode.bitrix24.tech/v1/userfields/users/6007923', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    sort: '300',
    list: [
      { VALUE: 'Сутки', SORT: 40 },
    ],
  }),
})

const { success, data } = await res.json()
console.log('Обновлено:', data.updated)
```

### JavaScript — OAuth-приложение

```javascript
const res = await fetch('https://vibecode.bitrix24.tech/v1/userfields/users/6007923', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    sort: '300',
    list: [
      { VALUE: 'Сутки', SORT: 40 },
    ],
  }),
})

const { success, data } = await res.json()
```

## Поля ответа

| Поле | Тип | Описание |
|------|-----|---------|
| `success` | boolean | Всегда `true` при успехе |
| `data.updated` | boolean | `true` при успешном обновлении |

## Пример ответа

```json
{
  "success": true,
  "data": {
    "updated": true
  }
}
```

## Пример ответа при ошибке

404 — поля с таким `id` нет:

```json
{
  "success": false,
  "error": {
    "code": "ENTITY_NOT_FOUND",
    "message": "User field 999999999 not found"
  }
}
```

## Ошибки

| HTTP | Код | Описание |
|------|-----|---------|
| 400 | `INVALID_ID` | `:id` не является положительным целым числом — запрос отклонён до обращения к порталу |
| 400 | `INVALID_REQUEST` | Тело запроса не является объектом |
| 404 | `ENTITY_NOT_FOUND` | Поля с таким `id` нет. Существование проверяется до правки, поэтому изменение на портал не уходит |
| 422 | `BITRIX_ERROR` | Владелец ключа не является администратором портала — Битрикс24 отвечает сообщением `Access denied.` |
| 422 | `BITRIX_ERROR` | Другие отказы Битрикс24 — в том числе поле удалили между проверкой существования и самой правкой. Текст приходит в `error.message` дословно |
| 403 | `SCOPE_DENIED` | API-ключ не имеет скоупа `user.userfield` |
| 401 | `TOKEN_MISSING` | API-ключ не имеет настроенных токенов |
| 401 | `MISSING_API_KEY` | Отсутствует заголовок `X-Api-Key` |

Полный список общих ошибок API — [Ошибки](/docs/errors).

## Известные особенности

**Ответ не подтверждает применение свойств.** `updated: true` означает, что Битрикс24 принял запрос, а не то, что каждое переданное свойство изменилось: свойства, помеченные в таблице [Какие свойства применяются](/docs/userfields/users#какие-свойства-применяются) как не применяемые, остаются прежними при успешном ответе. После обновления перечитайте поле — [`GET /v1/userfields/users/:id`](/docs/userfields/users/get).

**Варианты `enumeration` правятся адресно.** Массив `list` не заменяет набор вариантов целиком: не упомянутые в нём варианты сохраняются. Идентификаторы `ID` существующих вариантов берутся из ответа [`GET /v1/userfields/users/:id`](/docs/userfields/users/get). В примере выше к трём вариантам поля добавляется четвёртый — «Сутки».

## Смотрите также

- [Получить поле](/docs/userfields/users/get)
- [Создать поле](/docs/userfields/users/create)
- [Удалить поле](/docs/userfields/users/delete)
- [Поля сотрудников](/docs/userfields/users)
- [Пользовательские поля](/docs/userfields)