Перейти к документации
API

Обновить роль

Все поля необязательны, а `permissions` заменяет весь список.

PATCHapi.openemail.uk/roles/{id}

Выполняет настоящий запрос в вашем рабочем пространстве, с вашим собственным ключом.

PATCH /roles/{id}

Все поля необязательны, а permissions заменяет весь список.

Пример

Требует roles:write. Пропуск поля оставляет его как есть — это и означает PATCH.

curl
curl -X PATCH "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH" \  -H "Content-Type: application/json" \  -d '{ "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"] }'
Ответ
{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "name": "Support",  "description": "Answers the shared inboxes and nothing else.",  "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"],  "builtin": null,  "editable": true,  "deletable": true,  "members": 3,  "apiKeys": 1,  "createdAt": "2026-08-30T10:41:02.000Z",  "updatedAt": "2026-08-30T13:02:19.000Z"}

permissions ЗАМЕНЯЕТ весь список. Вызова на выдачу одного разрешения нет и не будет: аудиту подвергается список, а патч по индексу — это потерянное обновление в тот же момент, когда открыты две вкладки. Прочитайте роль, измените нужную запись, отправьте их все обратно. Отправка одного разрешения не добавляет разрешение. Она оставляет роль ровно с этим одним, плюс всё, что оно подразумевает.

description не только необязательно, но и допускает null, и в этой разнице весь смысл патча: пропуск сохраняет записанную фразу, отправка null очищает её. Без nullable убрать описание было бы можно только заменив его пробелом.

Владелец — единственная роль, которой PATCH отказывает, и отказывает по любому полю: role_immutable, 409 с param: "roleId". Всё остальное принимает новое имя так же охотно, как новый список разрешений, включая созданные при заполнении роли. builtin фиксирует, откуда взялась роль, а не то, что с ней можно делать. Имя, которое уже держит другая роль, — это role_name_taken, 409 с param: "name".

Правка вступает в силу при СЛЕДУЮЩЕМ запросе любого, кто держит эту роль, включая ключи API, потому что потолок вычисляется на каждый запрос, а не кешируется. Поэтому сужение роли — это живой отзыв доступа, действующий без ротации ключей под ней. Расширение тоже живое, и об этой половине стоит помнить.