Récupérer un rôle
Un rôle dans son intégralité, avec sa liste complète de permissions et ce qui le détient actuellement.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
GET /roles/{id}
Un rôle dans son intégralité, avec sa liste complète de permissions et ce qui le détient actuellement.
Exemple
Nécessite roles:read. Les identifiants portent un préfixe role_.
curl "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "description": "Answers the shared inboxes and nothing else.", "permissions": [ "emails:send", "emails:read", "threads:read", "threads:write", "labels:read", "labels:write", "contacts:read" ], "builtin": null, "editable": true, "deletable": true, "members": 3, "apiKeys": 1, "createdAt": "2026-08-30T10:41:02.000Z", "updatedAt": "2026-08-30T12:15:44.000Z"}Un rôle appartenant à un autre espace de travail donne un 404 plutôt qu'un 403, la même réponse qu'un identifiant qui n'a jamais existé, parce qu'indiquer à une clé quels identifiants existent sur un espace de travail qu'elle ne peut pas lire constitue en soi la fuite.
permissions constitue l'intégralité de l'octroi, à plat et déjà développé. Il n'y a rien d'autre à récupérer ni d'endpoint par permission : un rôle se lit comme une liste unique, parce que c'est une liste que l'on audite.
Cela ne dit pas QUI le détient. members et apiKeys sont des compteurs ; les noms derrière le premier s'obtiennent avec GET /members, et aucun endpoint ne liste les clés rattachées à un rôle.