Remove a member
Both axes at once: the role, and every address grant they hold here.
Runs the real call against your workspace, with your own key.
DELETE /members/{userId}
Both axes at once: the role, and every address grant they hold here.
Example
Needs members:write.
curl -X DELETE "$OE/members/7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a" -H "$AUTH"{ "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.