역할 목록
워크스페이스의 모든 역할을 내장 역할부터, 각각을 몇 명과 몇 개의 키가 갖고 있는지와 함께.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
GET /roles
워크스페이스의 모든 역할을 내장 역할부터, 각각을 몇 명과 몇 개의 키가 갖고 있는지와 함께.
두 개의 축, 그리고 둘은 같은 질문이 아니다
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"역할은 이 워크스페이스에서 무엇을 할 수 있는지를 말합니다. 메일 읽기, 보내기, 템플릿 편집, 도메인 추가 같은 것입니다. 권한 부여는 그것을 어떤 주소에 할 수 있는지를 말하며, 바로 옆 /members/{userId}/addresses에 member(주소를 읽고 그 주소로 보냄) 또는 viewer(읽기만)로 존재합니다. 메시지가 나가려면 둘 다 동의해야 합니다. 권한 부여가 없는 emails:send 역할은 아무 주소로도 보낼 수 없고, viewer 권한 아래 워크스페이스의 모든 주소를 가진 사람도 마찬가지로 아무 주소로도 보낼 수 없습니다.
모든 워크스페이스는 같은 여섯 개 역할로 시드됩니다. Owner, Admin, Member, Viewer는 사다리를 이룹니다. 각각이 다음 것이 가진 모든 것을 갖고 있으므로, 누군가를 강등하면 접근 범위가 다른 것으로 바뀌는 게 아니라 좁아집니다. Developer와 Billing은 그 사다리의 단이 아닙니다. Developer는 연동을 만들고(키, 웹훅, 템플릿, 발송) 워크스페이스의 메일은 전혀 읽지 않으며, Billing은 플랜과 인보이스만 볼 뿐 그 외에는 아무것도 보지 않습니다. 둘 다 Admin 안에 엄격히 포함됩니다. 이들은 워크스페이스 생성 시점이 아니라 첫 읽기 때 시드되므로, 이 기능보다 먼저 만들어진 워크스페이스는 무언가 요청하는 순간 이들을 갖게 됩니다. builtin은 행이 어느 시드에서 왔는지를 가리키며, 그것이 가리키는 전부입니다. 여섯 개는 워크스페이스가 다듬으라고 있는 출발점이며, Owner를 제외한 전부는 이름을 바꾸고, 권한을 다시 주고, 삭제할 수 있습니다. 이름이 아니라 editable과 deletable로 분기하십시오. 누군가 이름을 바꾼 역할도 그 두 값은 정확히 답하지만, 이름은 더 이상 아무것도 말해주지 않습니다.
Owner만이 예외이며, 모든 방향에서 예외입니다. editable: false, deletable: false이고 PATCH /members/{userId}의 대상으로도 거부됩니다. 워크스페이스가 귀속된 계정을 가리키며 나중 릴리스에서 추가된 것까지 포함해 모든 권한을 갖는데, 그래서 그 목록은 저장되지 않고 계산됩니다. 다른 사람을 소유자로 만드는 것은 워크스페이스 이전이며, 여기에는 그것을 수행하는 엔드포인트가 없습니다.
나머지 다섯은 무엇이든 받아들입니다. 새 권한 목록, 새 설명, 새 이름, DELETE까지. 이들은 고정물이 아니라 시드된 기본값입니다. 연동을 만들 일이 없는 워크스페이스는 Developer를 없앨 수 있어야 하고, "Member"가 더 좁은 뜻인 워크스페이스는 자기 말로 그렇게 적을 수 있어야 합니다. 거부하는 것은 owner뿐이며, PATCH가 이름을 담았든 권한 목록을 담았든 전부 하나의 코드로 거부합니다. role_immutable, param: "roleId"를 담은 409입니다. 이제 이름 변경만 따로 거부되는 경우는 없으므로 param: "name" 불변성을 처리할 일도 없습니다. 이름이 여전히 일으킬 수 있는 유일한 409는 워크스페이스의 다른 역할이 이미 그 이름을 쓰고 있을 때의 role_name_taken입니다.
여섯 개를 넘어, 워크스페이스는 자체 역할을 최대 24개까지 만듭니다. 상한은 그것만 세므로, 시드된 역할을 지워도 여유가 생기지 않습니다. 권한은 그대로 받아들여지지 않고 들어올 때 확장되므로(templates:write 하나는 templates:read와 templates:write로 저장됩니다), 보낸 목록 그대로라고 가정하지 말고 응답에서 다시 읽으십시오.
역할은 API 키의 상한이기도 합니다. 역할에 대해 발급된 키는 key.scopes ∩ role.permissions까지만 할 수 있고 그 이상은 못 하며, 경계에서 요청마다 해석됩니다. 그래서 역할을 수정하면 바로 다음 호출부터 그 키들이 할 수 있는 일이 바뀌고, 역할이 없는 키에는 상한이 아예 없습니다. 자세한 내용은 스코프 페이지에 전부 있습니다.
예제
roles:read가 필요합니다. 커서가 없습니다. 엔벌로프는 hasMore와 nextCursor를 담아 클라이언트가 다른 모든 컬렉션과 같은 목록 코드를 쓸 수 있게 하지만, 두 번째 페이지는 결코 없습니다.
curl "$OE/roles" -H "$AUTH"{ "object": "list", "data": [ { "object": "role", "id": "role_1c94e05d3862c1f0a44b7f3a", "name": "Owner", "description": "The person the workspace belongs to. Holds everything, including additions.", "permissions": ["emails:send", "emails:read", "…", "workspace:manage"], "builtin": "owner", "editable": false, "deletable": false, "members": 0, "apiKeys": 2, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" }, { "object": "role", "id": "role_c40a95f21cc65d31c2a89e07", "name": "Viewer", "description": "Reads the mail on the addresses they hold, and changes nothing.", "permissions": [ "emails:read", "drafts:read", "threads:read", "labels:read", "contacts:read", "calendar:read", "templates:read", "rules:read", "connections:read", "settings:read" ], "builtin": "viewer", "editable": true, "deletable": true, "members": 3, "apiKeys": 1, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" } ], "hasMore": false, "nextCursor": null}API의 나머지처럼 최신순이 아니라, 내장 순위 다음 이름순(owner, admin, member, viewer, developer, billing, 그다음 나머지를 알파벳순)으로 정렬됩니다. 권한 매트릭스는 사다리처럼 읽히는데, createdAt으로 정렬하면 가장 넓은 역할이 매주 다른 줄에 놓입니다.
이 목록을 읽는 것이 여섯 개를 한 번도 가진 적 없는 워크스페이스에 그것들을 시드하는 동작입니다. 시딩은 유니크 인덱스에서 충돌해 두 번째부터는 아무것도 하지 않으므로 이 호출은 멱등하고 첫 번째만 씁니다. 그래서 POST /members가 언제나 존재하는 roleId를 지정할 수 있습니다.
시딩은 한 번만 일어납니다. 워크스페이스는 시드되었음을 기록하므로, 이 읽기는 기능보다 오래된 워크스페이스를 채운 뒤 다시는 쓰지 않습니다. 그래서 시드된 역할의 삭제가 영구적입니다. 이전 빌드는 읽을 때마다 빠진 템플릿 행을 다시 넣었기 때문에 삭제된 Billing이 다음 페이지 로드에서 새 id로 돌아왔습니다. 지금은 그렇지 않습니다.
members와 apiKeys는 역할을 없애기 전에 옮겨야 할 것들이며, 덕분에 클라이언트가 409를 받은 뒤가 아니라 삭제를 제안하기 전에 경고할 수 있습니다. owner 행은 대개 members: 0으로 읽힙니다. 소유자는 자기 워크스페이스의 멤버가 아니라 그 워크스페이스가 귀속된 계정입니다.
커스텀 역할이 24개로 엄격히 제한되는 것은 바로 이것이 한 번의 응답일 수 있게 하기 위해서입니다. 역할이 마흔 개인 워크스페이스는 "누가 billing@으로 보낼 수 있는가"를 눈으로 훑어 답할 수 없는데, 그 답을 가능하게 하는 것이 이 기능의 유일한 존재 이유입니다.