Actualizar un rol
Todos los campos son opcionales, y `permissions` reemplaza la lista completa.
Ejecuta la llamada real contra tu espacio de trabajo, con tu propia clave.
PATCH /roles/{id}
Todos los campos son opcionales, y permissions reemplaza la lista completa.
Ejemplo
Requiere roles:write. Omitir un campo lo deja intacto, que es lo que significa PATCH.
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 REEMPLAZA la lista completa. No existe una llamada para conceder uno solo y no la habrá: lo que se audita es una lista, y un patch direccionado por índice es una actualización perdida en cuanto hay dos pestañas abiertas. Lee el rol, cambia la entrada que querías y devuélvelas todas. Enviar un permiso no añade un permiso: deja el rol con exactamente ese, más lo que este implique.
description admite null además de ser opcional, y esa diferencia es todo el sentido de un patch: omitirlo conserva la frase almacenada, enviar null la borra. Sin la posibilidad de null no habría forma de quitar una descripción salvo sustituyéndola por un espacio.
El propietario es el único rol al que un PATCH se niega, y se niega a todos sus campos: role_immutable, un 409 con param: "roleId". Todos los demás aceptan un nombre nuevo con la misma facilidad que una nueva lista de permisos, incluidos los roles precargados. builtin registra de dónde vino un rol, no lo que se le puede hacer. Un nombre que ya tiene otro rol es, en cambio, role_name_taken, un 409 con param: "name".
La edición se aplica en la SIGUIENTE solicitud que haga cualquiera que tenga el rol, claves de API incluidas, porque el techo se resuelve por solicitud en lugar de almacenarse en caché. Estrechar un rol es, por tanto, una revocación en vivo que surte efecto sin rotar las claves que dependen de él. Ampliarlo también es en vivo, que es la mitad que conviene recordar.