Three classes
Everything Maat holds falls into one of three, and each has a different answer.What you never receive
There is no guest identity anywhere on this API except the shortened public reviewer label on the reviews read ("Sarah M.", the same string the public listing page shows). No name, no
email, no phone number, no user id, and no reference you could join back to a person on a
later read — not on a read, and not on any webhook. A booking event tells you what is
happening on your inventory, never who it is happening to, and a delivery body read back
from the delivery log is the same body, so it carries none either.
A booking, on this contract, is a booking_reference and facts about a stay: the dates,
the property’s own door times, the party size as a count, the status, what was paid, the
listing and unit it belongs to, and whether the listing takes instant bookings. That is the
whole shape, and no amount of nesting would change it.
Two things follow that are worth stating because integrations guess at both:
guestsis a count, never a list. There is no per-guest anything. When it isnullthat means “not stated here”, never “nobody is coming” — and the unit’s capacity is not a substitute for it.amount_paidis one object. A decimal string beside its currency, never two fields you pair yourself.nullmeans the amount cannot be stated; a stay that really cost nothing is"0.00", because zero is a price.
console_url, and who is arriving
Every booking, review, listing and property view carries a deep link into the Maat host
console, and so does every booking event.
That answers the question every integration asks next, without moving the answer onto this
wire: follow the link, sign in as a person, and see what a person may see. It is slower than a
field on a JSON response, and that is what it is for — an arrivals board built this way is
built out of the platform’s own access control, which a workspace can grant, audit and
revoke, rather than out of a key nobody can revoke on its own.
Nothing about a guest travels inbound
The other direction is simpler: there is no field for it anywhere. A calendar block says these nights are gone and nothing else — no name, no reservation amount, no free-text note of any kind, because the obvious thing anyone writes in a free-text field is a guest’s name. A host calendar block has a closedcategory and no note. The
property push has a postal address and no delivery detail. building, floor, apartment
and directions are written only through the address replacement
(PUT /v1/properties/{property_id}/address) — the fourth is 400 characters of free text —
because they are your own operational notes about your own building, and they read back to
your own workspace alone. Sending a field this API does not declare is a
400 validation_failed naming it, never a silent drop, so an integration framework that
“helpfully” attaches reservation details finds out on its first sandbox call.
Maat has no relationship with somebody whose stay was sold through your own system, and
therefore no lawful basis to hold anything about them. The schema is what makes that true
rather than a promise.
What the pricing mode tells you when you do not hold it
GET /v1/listings/{listing_id}/pricing-mode answers a caller who does not hold the mode
with two fields: the listing id, and external or rules. Not which vendor, not their
horizon, their currency, or how they price a night they have not covered — those belong to
that tool’s own configuration.
Your own take tells you what you set, because it is yours.