멤버 역할 변경
역할만 바꿉니다. 주소는 다른 축이며 별도의 호출이 있습니다.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
PATCH /members/{userId}
역할만 바꿉니다. 주소는 다른 축이며 별도의 호출이 있습니다.
예제
members:write가 필요합니다. roleId가 유일한 필드이며 필수입니다. 이 호출은 적용할 변경이 아니라 원하는 상태를 지정하므로, 두 번 보내도 같은 사람이 같은 역할을 갖는 결과가 됩니다.
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는 전체 교체를 뜻할 수밖에 없는데, 그러면 클라이언트가 오래된 목록을 보낼 때마다 조용한 대량 회수가 됩니다. 두 개의 주소 호출은 한 번에 하나씩 추가하고 제거하므로, 일어난 일은 언제나 요청한 일입니다.
이것은 레거시 권한 보유자가 implied 상태에서 벗어나는 방법이기도 합니다. 그들에게는 멤버 행이 없는데 이 호출이 하나를 upsert하고, 그때부터 그들의 권한은 주소 접근이 우연히 함의한 것이 아니라 누군가 고른 것이 됩니다. 위 응답에서 implied가 false로 바뀌고 createdAt이 나타난 것을 보십시오. 주소는 전혀 바뀌지 않습니다.
호출자가 무엇을 갖고 있든 owner 역할은 부여할 수 없습니다(role_immutable, 409). 누군가를 소유자로 만드는 것은 워크스페이스 이전이며, 결과가 다르고 이 API에는 존재하지 않습니다.
새 역할은 그 사람의 다음 요청부터, 그리고 그 역할로 제한되는 모든 API 키의 다음 요청부터 적용됩니다.