Skip to main content
POST
Erase an end user's identifier

Authorizations

Authorization
string
header
required

Enter your MeshAPI key (rsk_...) or, for the admin-keys endpoints, a dashboard session token — sent as Authorization: Bearer <token>.

Headers

X-Mesh-Version
enum<string>
default:2026-08

Dated version of the API contract to pin this request to. Omit it and the request is served under 2026-08 — the oldest supported version, so an existing integration is never moved by a release. A malformed or unsupported value is rejected with 400 invalid_api_version rather than falling back silently. The version actually served is echoed as X-Mesh-Version on every response, including errors.

Available options:
2026-08,
2026-09

Body

application/json
end_user_id
string
required

The user value as it was sent on the original requests. Matched exactly — this is an identifier, not a search.

Required string length: 1 - 256

Response

Successful Response

end_user_id_sha256
string
required

SHA-256 of <org_id>:<end_user_id>. Returned instead of the identifier so a caller can correlate this erasure in their own records without us echoing back what we just deleted.

usage_events_cleared
integer
required

Rows whose attribution was removed. The billing rows themselves survive — only end_user_id is nulled. Capped per call; if the cap was reached, usage_events appears in pending and the call should be repeated.

pending
string[]
required

Stores this call did NOT erase. Present so the response cannot be read as a complete-erasure claim when it is not one.

reattributable_until_traffic_stops
boolean
default:true

Always true, and stated rather than implied. Usage rows are written ASYNCHRONOUSLY after a request finishes, so a request already in flight for this end user can re-attribute a row after this call returns. The erasure is a point in time, not a lock. Call again once traffic for the identifier has stopped; the call is idempotent.