Erase an end user's identifier
Removes a caller-supplied user identifier from the usage records it was attributed to, so a deletion request from your own end user can be passed through. Billing rows are kept and only the identifier is cleared, which is why this reports rows CLEARED rather than deleted.
Idempotent: erasing an identifier that is already gone succeeds and reports usage_events_cleared: 0.
This is a point in time, not a lock. Usage rows are written asynchronously after a request completes, so a request already in flight for this end user can re-attribute a row after the call returns. Erase once traffic for the identifier has stopped, or call again.
Authorizations
Enter your MeshAPI key (rsk_...) or, for the admin-keys endpoints, a dashboard session token — sent as Authorization: Bearer <token>.
Headers
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.
2026-08, 2026-09 Body
The user value as it was sent on the original requests. Matched exactly — this is an identifier, not a search.
1 - 256Response
Successful Response
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.
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.
Stores this call did NOT erase. Present so the response cannot be read as a complete-erasure claim when it is not one.
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.