API

ロールを取得する

1 つのロールの全体を、パーミッションの一覧全部と、現在それを保持しているものとともに取得します。

GETapi.openemail.uk/roles/{id}

実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。

GET /roles/{id}

1 つのロールの全体を、パーミッションの一覧全部と、現在それを保持しているものとともに取得します。

例

roles:read が必要です。id には role_ プレフィックスが付きます。

curl

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"}

別のワークスペースのロールは 403 ではなく 404 で、存在したことのない id と同じ応答になります。読めないワークスペース上にどの id が存在するかをキーに教えること自体が漏洩だからです。

permissions は権限全体で、フラットかつ展開済みです。ほかに取得するものはなく、パーミッション単位のエンドポイントもありません。ロールを 1 つの一覧として読むのは、監査されるのが一覧だからです。

これは「誰が持っているか」は示しません。members と apiKeys は件数です。前者の中身は GET /members で分かりますが、ロールに紐づくキーを一覧するエンドポイントはありません。