Tenancy
Data is organized under organization → property group → property. An organization (what users sign into) anchors exactly one property group — the highest-order data tenant. A property group owns properties: single operated entities like one hotel or venue. Every credential resolves to a property group, optionally narrowed to one property.Entities
Guest profiles
GET /v1/guests · reference
A guest profile is one source system’s record of a guest — Mews’ view, Square’s
view — kept exactly as ingested (names, contact details, preferences, tags),
stamped with the integration_id it came from. The same real person appears
once per source that knows them.
Master profiles
GET /v1/master-profiles · searchable by name, email, phone
The golden record. Identity resolution merges guest profiles across source
systems and properties into one master profile per real guest, with
per-attribute provenance (attribute_sources records which system supplied
each canonical field) and the list of merged member records. When you want “the
guest”, not “what one system knows about the guest”, read these.
Reservations
GET /v1/reservations · filter by status, stay window, channel, guest
Stays and bookings, linked to the guest profile that made them. Statuses are
normalized to a canonical lifecycle (pending, confirmed, in_progress,
completed, cancelled, declined, no_show) and channels to canonical
categories (direct, ota, …) — the original vendor values remain in
source_payload.
Transactions
GET /v1/transactions · filter by guest, reservation, consumption date, type
Revenue lines shaped like Pace Transactions V2 — one row per source order item,
with net_revenue and gross_revenue, optional reservation_id, and a
canonical type (e.g. space, product). Guest spend is the sum
of linked transactions.
Consents
GET /v1/consents · filter by contact value/method, purpose, status, integration, observing guest
Contact-grain marketing and compliance observations — one row per decisive source
signal (granted, withdrawn, denied) for a contact method + value and purpose
(email ≠ SMS). Default-unknown: no row means unknown / not eligible; connectors do
not store coverage rows for vendor silence. Effective eligibility within a property
group is the most restrictive status among matching stored observations.
Guest event log
GET /v1/events · timeline or latest mode
The append-only history of everything Casa has observed: every change to every
entity, in order, forever. timeline mode returns the full change history;
latest mode returns the latest delta slice per entity (the rollup alias is
kept for compatibility and behaves the same). This is the replayable source of
truth behind the canonical tables.
Reviews
GET /v1/reviews · GET /v1/reviews/summary
Guest reviews from every connected channel (Booking.com, Google, …) with
ratings, tags, and host responses. The summary endpoint aggregates them —
average rating, rating distribution, per-channel breakdown, top
positive/negative tags — for a scope and date window.
Loyalty
GET /v1/loyalty-programs · GET /v1/loyalty-members
Loyalty program definitions and their memberships. Member search joins each
membership with its guest (name, email) and program, ordered by points —
filter by tier, program, or free-text guest match.
Channels & spaces
GET /v1/channels · GET /v1/spaces
Reference dimensions: the booking channels reservations and reviews arrive
through, and the bookable spaces (inventory types) they concern.
Properties
GET /v1/properties
The roster of properties in your group — useful for populating pickers and for
choosing an X-Property-Id drill-down.
Tables
GET /v1/tables · GET /v1/tables/{id} · GET /v1/tables/{id}/members
Group-scoped ops containers of master or guest members — static curation or
lightweight attribute filters. Each table has a type: static (manual
add/remove) or dynamic (membership from saved filters, updated by manual
Refresh). member_type (master or guest) is fixed at create and never
mixed within one table.
Member responses use profile directory projections. Member rows can still
carry kind (clustered or singleton) — that field describes the
profile row, not the table’s type.
MCP read tools: tables_list, table_get, table_members (scope
read:tables). Writes require write:tables on REST. Tables are not
marketing segments — campaign audiences live in downstream ESPs.
SQL access
POST /v1/sql
For questions the endpoints don’t answer directly, run read-only SQL over the
same tables. Queries execute as a least-privilege database role under
row-level security scoped to your tenant — a query can never read another
tenant’s rows, even without a WHERE clause. Writes are rejected.