Remove a member from your organization
DELETE/v1/organization/members/:userId
x-scope: "team:write"
Takes a teammate off the team; they lose every agent within a minute. It can't be undone: to bring
them back, invite them again. Only a key created by the owner can remove someone, as only
the owner can in the dashboard. A key never removes an owner (403 owner_only) or the
person who created it (403 self_remove).
Request
Responses
- 204
- 401
- 403
- 404
- 429
- 500
- 503
Removed.
Response Headers
Correlation id for this request — paste into support tickets.
Authentication failed. Single code (invalid_api_key) covers every
sub-case: missing header, wrong scheme, malformed, unknown, revoked or
expired key. The message field disambiguates for humans debugging.
One exception: when the key could not be checked because of a server-side
fault, the status is still 401 but type is internal_error and code
is internal_server_error; retry with backoff.
Response Headers
Correlation id for this request — paste into support tickets.
insufficient_scope: the key lacks team:write, which full access (*) doesn't include.
insufficient_role: the key is limited to some agents, or the person who created it can't
do this in the dashboard any more (only the owner, or an admin with every agent, manages the
team, and only the owner removes someone). owner_only: the teammate is an owner, managed
in the dashboard. self_edit / self_remove: the teammate is the person who created the
key.
Response Headers
Correlation id for this request — paste into support tickets.
not_found: the person isn't on the team, or the invitation isn't one of your
organization's open invitations.
Response Headers
Correlation id for this request — paste into support tickets.
Per-key rate limit hit. Default is 60/min/key; an endpoint with an
x-rate-limit-per-minute of its own counts in a budget of its own
(today the WhatsApp template endpoints, sendBroadcast, retryBroadcast, inviteMember
and resendInvitation, which share one that allows 10/min/key, and
sendConversationMessage, which allows 20/min/key), and its 429
reports that limit in X-RateLimit-Limit. Retry-After tells you when to retry;
X-RateLimit-Reset is the Unix timestamp of the next window.
Per-success-response
X-RateLimit-*headers are a known gap; on 2xx responses these headers are NOT currently emitted. Customers should rely on 429 +Retry-Afterfor backoff signals.
Response Headers
Correlation id for this request — paste into support tickets.
Seconds to wait before retrying.
The per-minute request limit of the endpoint called. Every key has the same limits today.
Remaining requests in the current window. 0 on rejection.
Unix timestamp at which the current window resets.
Unexpected server-side failure. Retry with exponential backoff. If
the failure persists, send us the correlation_id.
Response Headers
Correlation id for this request — paste into support tickets.
Mojeeb couldn't check access because of a temporary fault: the key's,
or on assignLead and assignConversation the teammate's. Nothing was
changed. Retry with backoff.
Response Headers
Correlation id for this request — paste into support tickets.