API

멤버 조회

계정 id로 한 사람과 그 역할, 그리고 주소를 조회합니다.

GETapi.openemail.uk/members/{userId}

본인 키로 워크스페이스에 실제 호출을 실행합니다.

GET /members/{userId}

계정 id로 한 사람과 그 역할, 그리고 주소를 조회합니다.

예제

members:read가 필요합니다. 사용자 id 기준입니다. 이메일 주소가 아니라 목록에 있는 userId를 씁니다.

curl

curl "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t" -H "$AUTH"

응답

{  "object": "member",  "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t",  "email": "[email protected]",  "name": "Sam Okonjo",  "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": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44",      "address": "[email protected]",      "access": "member"    }  ],  "createdAt": "2026-08-12T14:20:00.000Z"}

여기에는 이메일로 조회하는 방법이 없습니다. 이메일을 받는 유일한 호출은 POST /members이며, 호출자가 아직 사용자 id를 정말로 갖고 있지 않은 유일한 호출이기 때문입니다.

이 워크스페이스에 없는 사용자 id는 단순한 404입니다. 이 리소스에서 "그런 리소스는 없다"가 분명한 유일한 경우입니다. 같은 조건이라도 쓰기 후 되읽지 못해 발생하면 422로 매핑되는데, 그건 거기서는 맞고 여기서는 틀립니다.

단일 행 조회가 아니라 전체 멤버 목록에서 읽어 오며, 이는 의도적입니다. 멤버는 역할 행과 주소 권한 집합의 합집합이고 둘 중 하나만 존재할 수도 있으며, 그 합집합은 정확히 한 곳에서 계산됩니다. 단일 행 조회는 그 계산의 두 번째 구현이 될 것이고, 그렇게 되면 조용히 빠뜨릴 집단은 오늘날 테이블의 대부분을 차지하는 레거시 권한 보유자들입니다.