ロールを作成する
名前とパーミッションの一覧を送ります。返ってくるものは、送ったものより長くなります。
実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。
POST /roles
名前とパーミッションの一覧を送ります。返ってくるものは、送ったものより長くなります。
例
roles:write が必要です。201 を返します。カスタムロールは builtin: null、editable: true、deletable: true で、誰かが移されるまで保持者はいません。
curl -X POST "$OE/roles" -H "$AUTH" -H "Content-Type: application/json" \ -d '{ "name": "Support", "description": "Answers the shared inboxes and nothing else.", "permissions": ["emails:send", "threads:write", "labels:write", "contacts:read"] }'{ "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": 0, "apiKeys": 0, "createdAt": "2026-08-30T10:41:02.000Z", "updatedAt": "2026-08-30T10:41:02.000Z"}4 つのパーミッションを送って 7 つ返りました。emails:send は emails:read を、threads:write は threads:read を、labels:write は labels:read を含意します。開けないスレッドをアーカイブできるロールは、誰かがチェックを忘れた結果であって誰かが意図したポリシーではないので、この含意は拒否ではなく保存されます。一覧は正規の順序でも返るので、クライアントは 2 つのロールを JSON として差分比較し、保存ボタンを有効にするかどうかを判断できます。
未知のパーミッションは、ここでは捨てられるのではなく拒否されます。templates:writ は invalid_parameter、422 になり、その文字列を示します。サービスが黙って正規化するのは、そこがシード処理のパスでもあり MCP のパスでもあり、認識できない単語 1 つでロール全体を失敗させるほうが悪いからです。しかし、人が意図して行った呼び出しでは誤りです。テンプレートを編集できないロールを 200 で返しても何も伝えたことにならず、その人は午後いっぱいそれに費やすことになります。
同じワークスペース上の重複した名前は role_name_taken、409 です。25 個目のカスタムロールは role_limit_reached、422 です。これは誰も監査しなくなるほど権限マトリクスが大きくなるのを防ぐためのもので、プランの境界ではありません。
ロールを作成しても、それは誰にも与えられません。人をそのロールに移すのは PATCH /members/{userId} で、キーをそのロールに向けるのはキーを発行する画面で行います。