---
title: "Remove a member"
description: "Both axes at once: the role, and every address grant they hold here."
url: "https://openemail.uk/docs/api/members/remove"
area: "API"
category: "Roles & access"
---

# Remove a member

Both axes at once: the role, and every address grant they hold here.

`DELETE /members/{userId}`

## DELETE /members/{userId}

Both axes at once: the role, and every address grant they hold here.

## Example

Needs `members:write`.

**curl**

```
curl -X DELETE "$OE/members/7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a" -H "$AUTH"
```

**Response**

```
{
  "object": "member",
  "userId": "7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a",
  "deleted": true,
  "addressesRevoked": 2
}
```

> Both grants go together. Removing only the member row would be the worst of both outcomes: vanished from this list, still reading the mail.

> It does NOT 404 on somebody who is not a member, and that is not laxness about ids. The population this endpoint most needs to reach is the legacy grant holders, who have address grants and no member row at all, so a pre-flight “is there a member row” would refuse exactly the people whose access most wants revoking. `addressesRevoked` is what actually happened, and a zero there is the honest report of a no-op.

> It removes them from ONE workspace. Their OpenEmail account is untouched, and so is any access they hold somewhere else.

> To take back one address and leave the person in place, use `DELETE /members/{userId}/addresses/{addressId}` instead. That is the call for somebody who moved team rather than somebody who left.