> ## 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.

# The data boundary

> What this API carries about a person, and what it never carries.

This API moves a workspace's **business** data. A person is seen in the Maat host app, by a
human who signed in. That split is mechanical rather than a policy anyone has to remember,
and this page is what it means in practice.

## Three classes

Everything Maat holds falls into one of three, and each has a different answer.

| Class | What is in it | On this API |
| :- | :- | :- |
| **A — Personal data** | Identity documents and verification records; the documents a guest shares for the people travelling with them; a guest's name, email, phone, address, date of birth, nationality or user id; a workspace's members; chat messages and attachments; billing profiles, withdrawal methods and card data; login, device and IP signals. | **Never**, with one exception: the shortened public reviewer label (`"Sarah M."`) on the reviews read, the same string the public listing page shows. |
| **B — Commercial internals** | The per-booking payment split — commission, service fee, PSP fee, host payout, platform revenue — the commission rate, transaction ids, the nightly breakdown, which rules were applied, coupon and exchange-rate snapshots. | **Never per booking.** A booking carries `amount_paid` as one `{ value, currency }` object and nothing behind it. |
| **C — Workspace business data** | Properties, units, listings, photos, amenities, house rules, door times, calendars and blocks with their provenance, pricing configuration, quick actions and rules, booking **facts**, reviews in their public form, webhook configuration and delivery envelopes — including, on the single-delivery read, the exact body that was sent — the reference catalogues. | **Yes** — each through a projection that lists its fields rather than passing a row through. |

## 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:

* **`guests` is a count, never a list.** There is no per-guest anything. When it is `null`
  that means "not stated here", never "nobody is coming" — and the unit's capacity is not a
  substitute for it.
* **`amount_paid` is one object.** A decimal string beside its currency, never two fields you
  pair yourself. `null` means the amount cannot be stated; a stay that really cost nothing is
  `"0.00"`, because zero is a price.

The rule is enforced rather than reviewed. Every projection is a hand-built list of fields —
nothing is spread, nothing is passed through — and each one's test asserts the exact key set,
that no key path matches a shared sensitive-name pattern, and that no class-A or class-B
**value** appears anywhere in the serialized bytes, which is the case where something is
smuggled under an innocent-looking key.

## `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 closed `category` 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.