メンバーのロールを変更する
変更できるのはロールだけです。アドレスはもう 1 つの軸で、専用の呼び出しがあります。
実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。
PATCH /members/{userId}
変更できるのはロールだけです。アドレスはもう 1 つの軸で、専用の呼び出しがあります。
例
members:write が必要です。フィールドは roleId のみで、必須です。この呼び出しは適用する変更ではなく望む状態を指定するので、2 回送っても同じ人が同じロールを持つ状態に落ち着きます。
curl -X PATCH "$OE/members/7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "roleId": "role_2b81de079c1f0a4b7e05d386" }'{ "object": "member", "userId": "7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a", "email": "[email protected]", "name": null, "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": [ "emails:send", "emails:read", "threads:read", "threads:write", "labels:read", "labels:write", "contacts:read" ], "addresses": [ { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": "2026-08-30T15:44:02.000Z"}アドレスはここからは patch できません。この省略は意図的なものです。アドレスは要素ごとにアクセスレベルを持つ集合であり、配列を載せた PATCH は全置換を意味せざるを得ず、クライアントが古い一覧を送るたびに静かな一括取り消しになってしまいます。アドレス用の 2 つの呼び出しは 1 件ずつ追加・削除するので、起きることは常に依頼したことと一致します。
これは、レガシーな付与保持者が implied でなくなる方法でもあります。メンバー行がない相手に対してこの呼び出しが行を upsert し、それ以降その人のパーミッションは、アドレスのアクセス権から推定されたものではなく誰かが選んだものになります。上のレスポンスで implied が false になり、createdAt が現れていることに注目してください。アドレスについては何も変わりません。
オーナーロールは、呼び出し側が何を持っていても付与できません（role_immutable、409）。誰かをオーナーにすることはワークスペースの譲渡であり、結果が異なるうえ、この API には存在しません。
新しいロールは、その人の次のリクエストと、そのロールで制限されるすべての API キーの次のリクエストから有効になります。