Kalo te dokumentacioni
API

Merr një rol

Një rol i plotë, me të gjithë listën e lejeve të tij dhe me atë që e mban aktualisht.

GETapi.openemail.uk/roles/{id}

Ekzekuton thirrjen reale kundrejt hapësirës suaj të punës, me çelësin tuaj.

GET /roles/{id}

Një rol i plotë, me të gjithë listën e lejeve të tij dhe me atë që e mban aktualisht.

Shembull

Kërkon roles:read. Id-të mbartin një prefiks role_.

curl
curl "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH"
Përgjigje
{  "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"}

Një rol në një hapësirë tjetër pune është 404 dhe jo 403, e njëjta përgjigje si një id që nuk ka ekzistuar kurrë, sepse t'i thuash një çelësi se cilat id ekzistojnë në një hapësirë pune që ai nuk mund ta lexojë është vetë rrjedhja.

permissions është i gjithë grantimi, i sheshtë dhe tashmë i zgjeruar. Nuk ka asgjë tjetër për të marrë dhe asnjë endpoint për leje të veçanta: një rol lexohet si një listë e vetme, sepse lista është ajo që auditohet.

Kjo nuk thotë se KUSH e mban. members dhe apiKeys janë numërime; emrat pas të parit merren me GET /members, dhe nuk ka asnjë endpoint që liston çelësat e një roli.