> ## Documentation Index > Fetch the complete documentation index at: https://developer.maatstays.wtf/llms.txt > Use this file to discover all available pages before exploring further. # Confirm you deleted the records > Confirms that the records named in a `user.erased` delivery are gone from your systems. `event_id` is the `event_id` of that delivery. Call this only when the deletion is done. There is no way to report a failure and no state to park a request in: not calling it **is** the signal, and a request that stays unacknowledged is escalated on our side. The body is almost empty on purpose. There is no free-text field, because the one thing anybody would write there is a detail about the person whose erasure is being confirmed. `completed_at` is recorded as *your* claim about when you finished; the `acknowledged_at` we return is our own receipt clock and is the figure that appears in our compliance record. Your acknowledgment never blocks or delays the erasure itself. Maat completes on its own clock; this is the recipient-notification record. Repeat calls are safe and return the same `acknowledged_at` as the first — a compliance timestamp does not move because a request was retried. **Sandbox: this records your confirmation. Production: `501`.** No production partner has ever been sent a `user.erased` delivery, so there is nothing there to acknowledge, and answering `200` would let you record satisfying a request you never received. Do not treat a `501` from this endpoint as evidence of anything. ## OpenAPI ````yaml /docs/openapi/openapi.yaml post /deletion-requests/{event_id}/acknowledge openapi: 3.1.0 info: title: Maat Stays Partner API version: '2026-08-26' summary: Two-way property and calendar sync for commercial channel partners. contact: name: Maat Stays partner integrations url: https://developer.maatstays.wtf description: > The Partner API is a two-way sync between a channel partner's platform and Maat Stays. ``` Your system ── properties, calendar blocks ──▶ Maat Stays Your system ◀── booking notifications, deletion requests ── Maat Stays ``` Inbound, you push **what you have**: the properties you manage and the nights that are already taken on your own platform. Outbound, we push **what happened here**: a guest booked one of those properties on Maat, a booking was cancelled, or a guest exercised their right to erasure and you have records to delete. Nothing about a guest travels inbound. Maat has no relationship with somebody who booked on your platform, so a calendar block says "these nights are gone" and nothing else. # Contract status — read this before you build **The calendar-blocks contract is live in a sandbox workspace.** Push a block, read your blocks back, release one, and the nights really are held and released on a real calendar. Everything else in this document — and calendar blocks against a **production** workspace — is **published and not yet enabled**: a request that authenticates and validates receives `501 Not Implemented` with a problem document whose `code` is `not_enabled`. Nothing is written, and nothing is delivered. The split is decided by the workspace your key was issued for, not by a flag you can send. That is deliberate, and it is the honest version of a pre-release API. A fabricated `200` would tell you a calendar block was applied — so you would stop holding those nights on your side, and the next guest would book a room that is already occupied. It would tell you a deletion request was acknowledged, so you would record a compliance step that never happened. Neither is a mistake you could detect from our response. What IS live everywhere: authentication, authorization, the sandbox boundary, rate limiting and **every schema in this document**. Send us a malformed payload today and you get the same `validation_failed` you will get the day the contracts are enabled. Build against it now; nothing will change shape underneath you. One thing you can only exercise in the sandbox is a **conflict**. If nights you push are already booked or held on Maat, we refuse the whole range with `409` and name the colliding dates — we never apply part of a block, because a partial apply you were told succeeded is the one failure you could not detect. # Authentication You hold a long-lived API key (`maat_partner_…`) and exchange it for a short-lived bearer token. The key never reaches a contract endpoint; the token never lives longer than an hour. ```bash # 1. Exchange the key for a token. The body is empty on purpose: # the workspace, the environment and your identity all come from # the key itself, never from the request. curl -X POST https://maatstays.wtf/v1/token \ -H "Authorization: Bearer maat_partner_a1b2c3d4e5f60718_REPLACE_WITH_YOUR_SECRET" # → 200 # { # "access_token": "eyJhbGciOiJIUzI1NiIs…", # "token_type": "Bearer", # "expires_in": 900, # "workspace_id": "3f6b0f2e-1c3a-4d5e-9a70-8b2c4d6e0f11", # "sandbox": true # } # 2. Call a contract with the token. curl -X PUT https://maatstays.wtf/v1/blocks/ota-res-55123 \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs…" \ -H "Content-Type: application/json" \ -d '{"provider_id":"ota-prop-9001","check_in":"2026-09-01","check_out":"2026-09-05"}' ``` The token endpoint is the one place in this API that does not answer with a problem document: it returns `{ "message": … }` when a key is refused or the service is not configured, with one indistinguishable `401` for an unknown key, a revoked key and a wrong secret. An unexpected fault there is a problem document like everywhere else, and every other response in this API is one. Revoking a key kills its outstanding tokens on their **next request**. We re-check the key on every call rather than waiting for a token to expire. # Sandbox Every key is issued for exactly one Maat workspace and is either a sandbox key or a production key. A sandbox workspace is a real tenancy with real endpoints and real create-then-read loops, and everything in it is kept off every public surface: it does not appear in search, on the map, in the guest feed, on a public listing page, or in any notification. The environment is not a parameter and there is no header that changes it. Your token carries the environment it was issued for, we compare it against the workspace on every request, and a disagreement in either direction is a `workspace_scope_mismatch`. A sandbox booking that ends in a real charge is not available: sandbox workspaces do not reach a payment provider at all, and a hold on one is refused rather than faked. # Idempotency The two inbound contracts are `PUT` to a URL that contains **your** identifier — your `provider_id` for a property, your `external_uid` for a block. Retrying is safe by construction; there is no idempotency header to remember and no request-body field that can be forgotten. Your identifiers are unique to you. Two partners can use the same `provider_id` for different properties and neither will ever see the other's. # Errors Every response outside the token endpoint uses `application/problem+json` ([RFC 7807](https://www.rfc-editor.org/rfc/rfc7807)): ```json { "type": "https://developer.maatstays.wtf/errors/not-enabled", "title": "Not implemented", "status": 501, "detail": "The calendar-blocks contract is published but not yet enabled…", "instance": "urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33", "code": "not_enabled" } ``` **Branch on `code`, never on `type` or on the wording of `detail`.** `code` is the contract; the rest is documentation. | `code` | Status | What it means | | -------------------------- | ------ | -------------------------------------------------------------------- | | `validation_failed` | 400 | The payload does not match this document. `errors[]` names the fields. | | `unauthorized` | 401 | No usable token: missing, malformed, expired, or its key was revoked. | | `workspace_scope_mismatch` | 403 | The token's environment does not match the workspace it addresses. | | `property_not_found` | 404 | No such property in the workspace your key addresses. | | `deletion_request_not_found` | 404 | No deletion request with that `event_id` — for you. Never says which. | | `conflict` | 409 | The nights collide with a Maat booking or hold. `conflicts[]` names them.| | `rate_limited` | 429 | Too many requests for this key. See `Retry-After`. | | `internal_error` | 500 | Our fault. Retry an idempotent request; quote `instance` if it persists.| | `not_enabled` | 501 | The contract is published and not yet enabled. Nothing was written. | | `service_unavailable` | 503 | A capability we need is not configured. Nothing was written; retry. | `instance` is an occurrence identifier, not a URL. Quote it when you contact us. We do not tell you which of several refusals you hit — an unknown key, a revoked key and a wrong secret all answer identically, and so do the three ways a workspace scope can fail. Distinguishing them would let anyone enumerate our customers. # Rate limits 600 requests an hour per API key across all contract endpoints. Every response carries: | Header | Meaning | | --------------------- | ------------------------------------------- | | `RateLimit-Policy` | The quota and its window, e.g. `600;w=3600` | | `RateLimit-Limit` | The quota | | `RateLimit-Remaining` | What is left in the current window | | `RateLimit-Reset` | Seconds until the window resets | A `429` adds `Retry-After`, in seconds. The token endpoint has its own, separate ceiling. # Webhooks Booking notifications and deletion requests are delivered to one endpoint you register with `PUT /webhooks/endpoint`. Deliveries are signed: ``` X-Signature: hex(HMAC-SHA256(secret, "v1:" + timestamp + ":" + raw_body)) X-Signature-Timestamp: 1788000000 ``` Verify against the **raw request body, before parsing it**. Re-serialised JSON does not round-trip byte-identically and your signature will not match. Reject a timestamp more than five minutes old. Every delivery carries an `event_id` that is stable across our retries, so you can be idempotent. We never follow redirects, and we only ever deliver over HTTPS to a public address. servers: - url: https://maatstays.wtf/v1 description: Staging. The only environment this contract is published against today. security: - partnerAuth: [] tags: - name: properties description: | Push the properties you manage into Maat, keyed by your own `provider_id`. - name: blocks description: > Push the nights that are already taken on your platform. Carries no guest data of any kind — no name, no booking reference, no amount, no free text. - name: booking-notifications description: > Where Maat delivers a booking on one of your properties, and the payloads it sends. - name: gdpr description: > Erasure requests Maat sends you when a guest exercises their right to be forgotten, and how you confirm you acted on one. paths: /deletion-requests/{event_id}/acknowledge: post: tags: - gdpr summary: Confirm you deleted the records description: > Confirms that the records named in a `user.erased` delivery are gone from your systems. `event_id` is the `event_id` of that delivery. Call this only when the deletion is done. There is no way to report a failure and no state to park a request in: not calling it **is** the signal, and a request that stays unacknowledged is escalated on our side. The body is almost empty on purpose. There is no free-text field, because the one thing anybody would write there is a detail about the person whose erasure is being confirmed. `completed_at` is recorded as *your* claim about when you finished; the `acknowledged_at` we return is our own receipt clock and is the figure that appears in our compliance record. Your acknowledgment never blocks or delays the erasure itself. Maat completes on its own clock; this is the recipient-notification record. Repeat calls are safe and return the same `acknowledged_at` as the first — a compliance timestamp does not move because a request was retried. **Sandbox: this records your confirmation. Production: `501`.** No production partner has ever been sent a `user.erased` delivery, so there is nothing there to acknowledge, and answering `200` would let you record satisfying a request you never received. Do not treat a `501` from this endpoint as evidence of anything. operationId: acknowledgeDeletionRequest parameters: - $ref: '#/components/parameters/EventId' requestBody: required: false content: application/json: schema: $ref: '#/components/schemas/DeletionAcknowledgeRequest' example: completed_at: '2026-09-02T09:15:00Z' responses: '200': description: Your confirmation is recorded. Sandbox only. content: application/json: schema: $ref: '#/components/schemas/DeletionAcknowledgeResponse' example: event_id: 4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55 acknowledged_at: '2026-09-02T09:15:04Z' '400': $ref: '#/components/responses/ValidationFailed' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/WorkspaceScopeMismatch' '404': $ref: '#/components/responses/DeletionRequestNotFound' '429': $ref: '#/components/responses/RateLimited' '500': $ref: '#/components/responses/InternalError' '501': $ref: '#/components/responses/NotEnabled' x-codeSamples: - lang: bash label: cURL source: > # Call this only AFTER the records named in the user.erased # delivery are actually gone from your systems. curl -X POST https://maatstays.wtf/v1/deletion-requests/4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55/acknowledge \ -H "Authorization: Bearer $MAAT_PARTNER_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "completed_at": "2026-09-02T09:15:00Z" }' - lang: javascript label: Node.js source: | // eventId is the event_id of the user.erased delivery. Call this // only AFTER the records it names are actually gone. const eventId = '4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55'; const res = await fetch( `https://maatstays.wtf/v1/deletion-requests/${eventId}/acknowledge`, { method: 'POST', headers: { Authorization: `Bearer ${process.env.MAAT_PARTNER_TOKEN}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ completed_at: '2026-09-02T09:15:00Z' }), }, ); const body = await res.json(); if (!res.ok) throw new Error(`${body.code}: ${body.detail}`); console.log(body.acknowledged_at); - lang: python label: Python source: | import os import requests # event_id is the event_id of the user.erased delivery. Call this # only AFTER the records it names are actually gone. event_id = "4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55" res = requests.post( f"https://maatstays.wtf/v1/deletion-requests/{event_id}/acknowledge", headers={"Authorization": f"Bearer {os.environ['MAAT_PARTNER_TOKEN']}"}, json={"completed_at": "2026-09-02T09:15:00Z"}, timeout=30, ) body = res.json() if res.status_code >= 400: raise RuntimeError(f"{body['code']}: {body.get('detail')}") print(body["acknowledged_at"]) - lang: go label: Go source: | package main import ( "bytes" "encoding/json" "fmt" "log" "net/http" "os" ) func main() { // eventID is the event_id of the user.erased delivery. Call this // only AFTER the records it names are actually gone. eventID := "4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55" payload, _ := json.Marshal(map[string]string{ "completed_at": "2026-09-02T09:15:00Z", }) req, _ := http.NewRequest(http.MethodPost, "https://maatstays.wtf/v1/deletion-requests/"+eventID+"/acknowledge", bytes.NewReader(payload)) req.Header.Set("Authorization", "Bearer "+os.Getenv("MAAT_PARTNER_TOKEN")) req.Header.Set("Content-Type", "application/json") res, err := http.DefaultClient.Do(req) if err != nil { log.Fatal(err) } defer res.Body.Close() var body map[string]any if err := json.NewDecoder(res.Body).Decode(&body); err != nil { log.Fatal(err) } if res.StatusCode >= 400 { log.Fatalf("%v: %v", body["code"], body["detail"]) } fmt.Println(body["acknowledged_at"]) } components: parameters: EventId: name: event_id in: path required: true description: The `event_id` of the `user.erased` delivery being acknowledged. schema: type: string format: uuid example: 4e2c1b90-77a3-4a51-9d0e-6b1f3c8a2d55 schemas: DeletionAcknowledgeRequest: type: object title: DeletionAcknowledgeRequest additionalProperties: false properties: completed_at: type: string format: date-time description: > When you completed the deletion. Defaults to the time we receive this. DeletionAcknowledgeResponse: type: object title: DeletionAcknowledgeResponse required: - event_id - acknowledged_at additionalProperties: false properties: event_id: type: string format: uuid acknowledged_at: type: string format: date-time Problem: type: object title: Problem description: > An RFC 7807 problem document. Every error outside the token endpoint is one of these, served as `application/problem+json`. Branch on `code`. `type` is a stable identifier for the same thing, `title` and `detail` are for people, and `instance` identifies this one occurrence. required: - type - title - status - code properties: type: type: string format: uri example: https://developer.maatstays.wtf/errors/not-enabled title: type: string example: Not implemented status: type: integer example: 501 detail: type: string instance: type: string description: | An occurrence identifier, not a URL. Quote it when you contact us. example: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: type: string enum: - validation_failed - unauthorized - workspace_scope_mismatch - property_not_found - deletion_request_not_found - conflict - rate_limited - internal_error - not_enabled - service_unavailable conflicts: type: array description: > Present on `conflict`. The complete list of colliding dates — never truncated, unlike the sentence in `detail`. Act on this, not on the prose. items: type: string format: date example: - '2026-09-02' - '2026-09-03' errors: type: array description: > Present on `validation_failed`. Names the rejected fields and the rule each one broke — never the value you sent. items: type: object required: - field - code additionalProperties: false properties: field: type: string example: body.check_out code: type: string example: too_big responses: ValidationFailed: description: The payload does not match this document. Nothing was written. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/validation-failed title: Validation failed status: 400 instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: validation_failed errors: - field: body.check_out code: custom Unauthorized: description: > No usable partner token. One answer covers a missing token, an expired one, a revoked key and a human credential — telling them apart would report which credentials exist. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/unauthorized title: Unauthorized status: 401 detail: A valid partner token is required. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: unauthorized WorkspaceScopeMismatch: description: > The token's environment does not match the workspace it addresses — a sandbox token against a production workspace, or the reverse. One answer covers both, and also a workspace that does not resolve. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/workspace-scope-mismatch title: Workspace scope mismatch status: 403 detail: This token is not valid for the requested workspace. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: workspace_scope_mismatch DeletionRequestNotFound: description: > No deletion request with that `event_id` — for you. One answer covers an id that does not exist and one that belongs to another partner, and the two are deliberately indistinguishable in wording, in status and in timing. Telling them apart would let you walk ids and learn that some specific person was erased and that a named competitor held their booking. Nothing was recorded. Check the id against the `user.erased` delivery you are confirming. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/deletion-request-not-found title: Deletion request not found status: 404 detail: >- No deletion request with that event_id. Check the id against the user.erased delivery you are confirming. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: deletion_request_not_found RateLimited: description: > Too many requests for this API key. `Retry-After` gives the wait in seconds. headers: Retry-After: description: Seconds to wait before retrying. schema: type: integer RateLimit-Limit: description: The quota for the current window. schema: type: integer RateLimit-Remaining: description: Requests left in the current window. schema: type: integer RateLimit-Reset: description: Seconds until the window resets. schema: type: integer content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/rate-limited title: Too many requests status: 429 detail: Too many requests for this API key. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: rate_limited InternalError: description: Our fault. Retry an idempotent request. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/internal-error title: Internal error status: 500 detail: The request could not be completed. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: internal_error NotEnabled: description: > **What every contract endpoint returns against a production workspace**, and what the not-yet-enabled contracts return everywhere. The request was authenticated and validated in full; nothing was written and nothing will be delivered. The calendar-blocks and properties contracts do real work in a sandbox workspace — see their operations for what changes. Webhook registration and deletion acknowledgment return this in both tenancies. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/not-enabled title: Not implemented status: 501 detail: >- The calendar-blocks contract is published but not yet enabled. This request was authenticated and validated; no dates were blocked. Keep holding these dates on your own platform. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: not_enabled securitySchemes: partnerAuth: type: http scheme: bearer bearerFormat: JWT description: > A short-lived partner token, obtained by exchanging your API key at `POST /token`. Send it as `Authorization: Bearer `. 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. ````