---
title: "Retrieve a member"
description: "One person, their role and their addresses, by account id."
url: "https://openemail.uk/docs/api/members/get"
area: "API"
category: "Roles & access"
---

# Retrieve a member

One person, their role and their addresses, by account id.

`GET /members/{userId}`

## GET /members/{userId}

One person, their role and their addresses, by account id.

## Example

Needs `members:read`. By USER ID: the `userId` off the list, not their email address.

**curl**

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

**Response**

```
{
  "object": "member",
  "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t",
  "email": "sam@acme.com",
  "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": "help@acme.com",
      "access": "member"
    }
  ],
  "createdAt": "2026-08-12T14:20:00.000Z"
}
```

> There is no lookup by email here. `POST /members` is the one call that takes one, because it is the one call whose caller genuinely does not have a user id yet.

> A user id that is not on this workspace is a plain 404. It is the one case in this resource that is unambiguously “no such resource”. The same condition raised by a write that could not be read back maps to 422, which is right there and wrong here.

> Read off the full members list rather than by a single-row query, deliberately: a member is the UNION of a role row and a set of address grants, either of which can exist without the other, and that union is computed in exactly one place. A single-row query would be a second implementation of it, and the population it would quietly miss is the legacy grant holders, who are most of the table today.