Przejdź do dokumentacji
API

Pobierz rolę

Jedna rola w całości, z pełną listą uprawnień i tym, co aktualnie ją ma.

GETapi.openemail.uk/roles/{id}

Uruchamia prawdziwe wywołanie na twojej przestrzeni roboczej, twoim własnym kluczem.

GET /roles/{id}

Jedna rola w całości, z pełną listą uprawnień i tym, co aktualnie ją ma.

Przykład

Wymaga roles:read. Identyfikatory niosą prefiks role_.

curl
curl "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH"
Odpowiedź
{  "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"}

Rola z innej przestrzeni roboczej to 404, a nie 403, ta sama odpowiedź co dla identyfikatora, który nigdy nie istniał, ponieważ powiedzenie kluczowi, które identyfikatory istnieją w przestrzeni roboczej, której nie może czytać, samo w sobie jest wyciekiem.

permissions to całość nadanych uprawnień, płasko i już rozwinięta. Nie ma nic więcej do pobrania ani endpointu na pojedyncze uprawnienie: rolę czyta się jako jedną listę, bo to lista podlega audytowi.

To nie mówi, KTO ją ma. members i apiKeys to liczniki; nazwiska stojące za pierwszym daje GET /members, a endpointu wypisującego klucze przypisane do roli nie ma.