Skip to main content
Maat Stays is a property-rental and short-stay platform. This API is how your own software manages what you sell on it:

​
Who this is for

A host, or a property company, with its own system — a website, a booking engine, an app, an internal tool — that wants to manage its Maat listings from that system rather than one screen at a time. From one place you keep your properties, photos, calendars and rates in step, answer booking requests, reply to reviews, read what you have earned, and hear about every booking the moment it happens. Everything is scoped to your own workspace. You issue your keys yourself, from your own Maat account, and a key reaches that workspace’s inventory and nothing else. There is one contract and everybody uses the same one — Get access.

​
Environments

One vocabulary, settled here and used everywhere else.
  • One host. https://maatstays.wtf/v1. There is no second URL, no environment subdomain and no header that switches anything.
  • A key is bound to one workspace, chosen when the key is issued and never changeable.
  • A workspace is either a sandbox or a production workspace. A sandbox is a real Maat tenancy with real endpoints and real writes, kept off every public surface — Sandbox.
  • The token exchange tells you which one you hold. POST /v1/token returns a sandbox field. It is the only place that answer is published, and it is decided by your key rather than by anything you send.
Every operation states what it does on each: real work on a sandbox workspace, and — against a production one — full authentication, rate limiting and validation, then 501 not_enabled with nothing written, nothing read and nothing delivered. The credential exchange (POST /v1/token) is the one operation that also answers a production workspace, because it is how you find out which kind you hold. That status is on each operation’s reference page and machine-readable as x-maat-availability; the changelog records every change.

​
Your first four calls

You need a key for a sandbox workspace — Get access.
1

Exchange your key for a token

POST /v1/token with your API key returns a short-lived, workspace-scoped bearer token. One paragraph covers the whole model — Authentication.
2

Push a property

PUT /v1/properties/{provider_id} — keyed by your own system’s identifier, so retrying is always safe. Properties.
3

Block some nights

PUT /v1/blocks/{external_uid} holds a range on that property’s calendar, and GET /v1/blocks reads it back. Calendar blocks.
4

Register a webhook endpoint

PUT /v1/webhooks/endpoint, echo the signed challenge, and booking notifications arrive at your server. Webhooks.
Every endpoint in the reference carries runnable samples in cURL, Node, Python and Go, and the playground makes real calls against your own sandbox with your own token — nothing here embeds a credential. If you build with an AI assistant, point it at our MCP server first so it reads the real field names instead of guessing at them: Connect your AI assistant.

​
What crosses the wire about a guest

Worth knowing before you design around it, though nothing above depends on it. Nothing about a guest travels inbound — ever. When a stay is sold through your own system, a calendar block says “these nights are gone” and nothing else: there is no field for a name, a reservation amount, or a free-text note, and sending one is a validation error rather than a silent drop. Nothing identifies a guest outbound either. When a guest books one of your listings on Maat, your endpoint receives the stay dates and door times, the party size and the booking’s status — no name, no contact details, no guest identifier. Each booking event carries a console_url that opens the booking in your Maat host console, where the people on your team who may see the guest can. The whole boundary, in one page: The data boundary.