> ## 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. # Register where deliveries go > Sets the single HTTPS endpoint Maat delivers to, and the events you want. Sending this again replaces both — there is only ever one endpoint per partner and workspace, so that the record of who received which guest's details has one answer. An empty `events` array pauses delivery without discarding the endpoint or its signing secret. ### The challenge round-trip **Nothing real is delivered until your endpoint proves it is yours.** During this call we POST a signed `endpoint.challenge` delivery to the URL you gave us, and your handler must answer `2xx` with a JSON body echoing the same `challenge` string: ```json { "challenge": "" } ``` Echo it and the endpoint becomes `active`. Anything else — a non-2xx, an unreadable body, a different value — leaves it `pending_verification`, and no booking notification is ever sent to it. Call this endpoint again to retry. The challenge is signed exactly like a real delivery, so your verification code is exercised before your first real payload rather than after it. **The challenge is re-armed on EVERY call**, including one that does not change the URL. A URL that verified in March is not evidence about the same URL in September. ### What we check about your URL `https` only, on port 443 or 8443, on a publicly resolvable DNS name. We check the address the name actually **resolves to, at the moment we connect** — not just at registration — and we never follow redirects. If a URL is refused you get one `validation_failed`; we do not report which check failed. If your endpoint's address later stops resolving publicly, we suspend it and stop delivering rather than retrying into it. ### The signing secret Returned **once**, in the response to this call, and never again — we do not store it in a form anything can read back. Re-registering (a corrected path, a new event list) deliberately does NOT mint a new one, so your existing verification keeps working. If you lose it or it leaks, ask us to rotate: we issue the next secret and sign every delivery with **both** for an overlap window, so you can deploy on your own clock. See `X-Signature-Previous` under `booking.confirmed`. ### Availability This contract is **live in the sandbox**. On a production workspace it still returns `501`: outbound delivery of guest data is gated on the data-sharing agreement, the transfer mechanism and the privacy notice, not on code. A `503` means webhook signing is not configured on our side. Nothing was registered; retry. ## OpenAPI ````yaml /docs/openapi/openapi.yaml put /webhooks/endpoint 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: /webhooks/endpoint: put: tags: - booking-notifications summary: Register where deliveries go description: > Sets the single HTTPS endpoint Maat delivers to, and the events you want. Sending this again replaces both — there is only ever one endpoint per partner and workspace, so that the record of who received which guest's details has one answer. An empty `events` array pauses delivery without discarding the endpoint or its signing secret. ### The challenge round-trip **Nothing real is delivered until your endpoint proves it is yours.** During this call we POST a signed `endpoint.challenge` delivery to the URL you gave us, and your handler must answer `2xx` with a JSON body echoing the same `challenge` string: ```json { "challenge": "" } ``` Echo it and the endpoint becomes `active`. Anything else — a non-2xx, an unreadable body, a different value — leaves it `pending_verification`, and no booking notification is ever sent to it. Call this endpoint again to retry. The challenge is signed exactly like a real delivery, so your verification code is exercised before your first real payload rather than after it. **The challenge is re-armed on EVERY call**, including one that does not change the URL. A URL that verified in March is not evidence about the same URL in September. ### What we check about your URL `https` only, on port 443 or 8443, on a publicly resolvable DNS name. We check the address the name actually **resolves to, at the moment we connect** — not just at registration — and we never follow redirects. If a URL is refused you get one `validation_failed`; we do not report which check failed. If your endpoint's address later stops resolving publicly, we suspend it and stop delivering rather than retrying into it. ### The signing secret Returned **once**, in the response to this call, and never again — we do not store it in a form anything can read back. Re-registering (a corrected path, a new event list) deliberately does NOT mint a new one, so your existing verification keeps working. If you lose it or it leaks, ask us to rotate: we issue the next secret and sign every delivery with **both** for an overlap window, so you can deploy on your own clock. See `X-Signature-Previous` under `booking.confirmed`. ### Availability This contract is **live in the sandbox**. On a production workspace it still returns `501`: outbound delivery of guest data is gated on the data-sharing agreement, the transfer mechanism and the privacy notice, not on code. A `503` means webhook signing is not configured on our side. Nothing was registered; retry. operationId: registerWebhookEndpoint requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/WebhookEndpointRequest' example: url: https://hooks.example-partner.invalid/maat events: - booking.confirmed - booking.cancelled - user.erased responses: '200': description: > The endpoint is registered. Check `status`: `active` means the challenge was echoed and deliveries will flow; `pending_verification` means it was not, and nothing will be sent until you call again and echo it. `signing_secret` is present only the FIRST time you register. Its absence on a later call is not an error — your existing secret still applies. content: application/json: schema: $ref: '#/components/schemas/WebhookEndpointResponse' example: url: https://hooks.example-partner.invalid/maat events: - booking.confirmed - booking.cancelled - user.erased status: active signing_secret: whsec_EXAMPLE_0000000000000000000000000000 '400': $ref: '#/components/responses/ValidationFailed' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/WorkspaceScopeMismatch' '429': $ref: '#/components/responses/RateLimited' '500': $ref: '#/components/responses/InternalError' '501': $ref: '#/components/responses/NotEnabled' '503': $ref: '#/components/responses/ServiceUnavailable' x-codeSamples: - lang: bash label: cURL source: | # Your endpoint must answer the signed endpoint.challenge we POST # to it DURING this call — see the webhooks guide. curl -X PUT https://maatstays.wtf/v1/webhooks/endpoint \ -H "Authorization: Bearer $MAAT_PARTNER_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "url": "https://hooks.example-partner.invalid/maat", "events": ["booking.confirmed", "booking.cancelled", "user.erased"] }' - lang: javascript label: Node.js source: > // Your endpoint must answer the signed endpoint.challenge we POST // to it DURING this call — see the webhooks guide. const res = await fetch('https://maatstays.wtf/v1/webhooks/endpoint', { method: 'PUT', headers: { Authorization: `Bearer ${process.env.MAAT_PARTNER_TOKEN}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ url: 'https://hooks.example-partner.invalid/maat', events: ['booking.confirmed', 'booking.cancelled', 'user.erased'], }), }); const body = await res.json(); if (!res.ok) throw new Error(`${body.code}: ${body.detail}`); if (body.signing_secret) { // Present only on the FIRST registration, and never shown again. // Store it in your secret manager NOW. Never log it. } console.log(body.status); // 'active' once the challenge was echoed - lang: python label: Python source: | import os import requests # Your endpoint must answer the signed endpoint.challenge we POST # to it DURING this call — see the webhooks guide. res = requests.put( "https://maatstays.wtf/v1/webhooks/endpoint", headers={"Authorization": f"Bearer {os.environ['MAAT_PARTNER_TOKEN']}"}, json={ "url": "https://hooks.example-partner.invalid/maat", "events": ["booking.confirmed", "booking.cancelled", "user.erased"], }, timeout=30, ) body = res.json() if res.status_code >= 400: raise RuntimeError(f"{body['code']}: {body.get('detail')}") if "signing_secret" in body: # Present only on the FIRST registration, and never shown again. # Store it in your secret manager NOW. Never log it. pass print(body["status"]) # 'active' once the challenge was echoed - lang: go label: Go source: | package main import ( "bytes" "encoding/json" "fmt" "log" "net/http" "os" ) func main() { // Your endpoint must answer the signed endpoint.challenge we POST // to it DURING this call — see the webhooks guide. payload, _ := json.Marshal(map[string]any{ "url": "https://hooks.example-partner.invalid/maat", "events": []string{"booking.confirmed", "booking.cancelled", "user.erased"}, }) req, _ := http.NewRequest(http.MethodPut, "https://maatstays.wtf/v1/webhooks/endpoint", 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"]) } if _, ok := body["signing_secret"]; ok { // Present only on the FIRST registration, and never shown again. // Store it in your secret manager NOW. Never log it. } fmt.Println(body["status"]) // "active" once the challenge was echoed } components: schemas: WebhookEndpointRequest: type: object title: WebhookEndpointRequest required: - url - events additionalProperties: false properties: url: type: string format: uri maxLength: 2048 pattern: ^https:// description: | HTTPS only, a public DNS name only. Checked against the address it resolves to at the moment we connect, on every delivery. events: type: array maxItems: 16 uniqueItems: true items: $ref: '#/components/schemas/WebhookEventType' description: An empty array pauses delivery without discarding the endpoint. WebhookEndpointResponse: type: object title: WebhookEndpointResponse required: - url - events - status additionalProperties: false properties: url: type: string format: uri events: type: array items: $ref: '#/components/schemas/WebhookEventType' status: type: string enum: - pending_verification - active - suspended signing_secret: type: string description: | Returned once, on the call that issues it, and never again. Store it somewhere you can read it back; we cannot. WebhookEventType: type: string title: WebhookEventType enum: - booking.confirmed - booking.cancelled - user.erased 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 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 ServiceUnavailable: description: > A capability this endpoint needs is not configured on our side. Not a fault and not a rejection of your request — nothing was written, and retrying is the right thing to do. content: application/problem+json: schema: $ref: '#/components/schemas/Problem' example: type: https://developer.maatstays.wtf/errors/service-unavailable title: Service unavailable status: 503 detail: >- Webhook delivery is temporarily unavailable. Nothing was registered; retry shortly. instance: urn:maat:request:3b1f7a90-0d4c-4d4e-9b2a-6c1f0a2e5d33 code: service_unavailable 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. ````