A guest exercised their right to erasure
Delivered when somebody whose booking details you received has had their Maat account erased. You are asked to delete the records this names.
The payload contains no personal data at all — not a name, not an email, not even a Maat user id. It says which records, because you already hold everything else from the booking notifications we sent you. Restating the person’s details at the moment they are being destroyed would put them into your delivery log, and a durable user id would hand you a key that links their bookings together.
You are sent this only if you actually received that guest’s booking details: the recipients are the partners we successfully delivered to, and nobody else. Being asked about somebody you never heard of would itself tell you something about them.
records names every booking of theirs we ever sent you, so one request covers
the lot. It is idempotent on event_id across our retries.
Confirm with POST /deletion-requests/{event_id}/acknowledge once the deletion is
done. That confirmation is a compliance record; it never delays Maat’s own
erasure, which completes regardless — including when every delivery of this
request fails.
Delivered on sandbox workspaces. Not delivered in production, where no partner data is disclosed yet at all.
Authorizations
A short-lived partner token, obtained by exchanging your API key at
POST /token. Send it as Authorization: Bearer <access_token>.
Tokens live for fifteen minutes by default and never for more than an hour. Mint one per batch of work, not one per request.
The token carries the workspace and the environment its key was issued for. You cannot change either by asking: the exchange ignores everything in the request body for exactly that reason.
Never send it as a cookie or in a query string, and never store it — store the API key, mint tokens from it.
Body
Response
Return any 2xx to acknowledge receipt of the request.