What this endpoint does#
Soft-deletes or restores one member in the API key's community. Use it for account-level removal and undo, not for profile, role, XP, or custom-field edits.It does not remove the member from POST /v1/users/filter or from GET /v1/communities/{communityId}/users/{email} on the current public runtime. Search and community GET can still return the user after a successful delete.Exact retry / accidental deleteaction must be remove or restore. On 2026-08-19 Codex, action: "delete" was accepted and returned 200 USER_SOFT_DELETED anyway. Do not send delete in tests against live members. If you did, send action: "restore" for the same user.
Authenticate → identify the member with POST /v1/users/info → POST /v1/users/manage with remove or restore → confirm with POST /v1/users/info and the admin user list, not with filter alone.
Quick start#
Restore (safe to retry on an already-active member):Soft-delete uses the same body with "action": "remove".Authentication and permission#
Send Authorization: Bearer <COMMUNITY_API_KEY>. Required permission: Delete/Restore User. Keep the key server-side.Complete examples#
Restore (200). { "user": "member@example.com", "action": "restore" } returned 200 USER_RESTORED User has been restored successfully. Follow-up GET community user by email and POST /v1/users/info both returned 200.Soft-delete (200). { "user": "member@example.com", "action": "delete" } returned 200 USER_SOFT_DELETED User has been deleted successfully even though validation copy says the allowed values are remove and restore. Prefer remove in integrations.Missing action (400). { "user": "member@example.com" } returned detail.action: Action is required and must be either remove or restore.Empty body (400). {} returned detail.user: Required and the same action requirement.Success and readback#
| Action | Code | Message |
|---|
restore | USER_RESTORED | User has been restored successfully |
remove or delete | USER_SOFT_DELETED | User has been deleted successfully |
Envelope is { status: "success", code, message }.After restore, call POST /v1/users/info and GET /v1/communities/{communityId}/users/{email}. Both should return 200. After remove, those same reads may still return 200. Filter rows are not proof of deletion.
Errors and recovery#
| Status | When | Recovery |
|---|
400 Manage user endpoint validation error. | Missing user or missing action | Send both. Use remove or restore. |
401 | Missing or invalid key | Replace the community key. |
Do not probe remove against a live member to "see what happens". Create a disposable user first, or restore immediately if you already did.Retry safety#
restore is safe to retry; a second restore on an active member still returned 200 USER_RESTORED. remove / delete is not a sandbox action. Do not retry remove to confirm the code. Retry only after checking POST /v1/users/info.
Gotchas#
Validation text says remove or restore, but delete currently performs a soft-delete.
Soft-delete does not drop POST /v1/users/filter rows.
Soft-delete does not make GET /v1/communities/{communityId}/users/{email} return 404 on the current runtime.
user accepts the same identifier family as other user writes (email in the Codex proof).
Next steps#
Get Users with Filters
Search still returns soft-deleted members. Do not use filter as deletion proof.