One guest with every booking, thread and held send
const url = 'https://quikstik-core.fly.dev/guests/example';const options = { method: 'GET', headers: { 'x-tenant-id': '2489E9AD-2EE2-8E00-8EC9-32D5F69181C0', Authorization: 'Bearer <token>' }};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://quikstik-core.fly.dev/guests/example \ --header 'Authorization: Bearer <token>' \ --header 'x-tenant-id: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0'key is a GuestHit.key: person:{uuid} (the key whenever a person exists,),
an email address (any case — a valid alias that resolves to the same person),
booking:{uuid} (an obligation ref) or identity:{kind}:{value} (any identity the person
owns: email, phone, viator_relay, gyg_relay, ota_ref). A person merged into another
reads as the survivor. Bookings are newest departure first and include cancelled ones with
their status; each carries its balance from the same read as
GET /obligations/{obligation_ref}/balance. Threads are awaiting_us first, then by last
activity. 404 when the key names nothing in this tenant, 422 invalid_key when malformed.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Header Parameters
Section titled “Header Parameters”Tenant identifier (UUID).
Authn/authz semantics are intentionally TBD for this contract slice; this header exists to keep the contract explicitly multi-tenant from day 0.
Responses
Section titled “Responses”The guest.
object
The person’s room, so the card opens it without a second lookup. Null when the guest is not a person yet.
object
object
Guest-lane entries.
Team-lane entries (0 on a guest session’s read).
Task entries still open (0 on a guest session’s read).
Threads in this room awaiting our reply (0 on a guest session’s read).
object
Newest departure first; cancelled bookings included with their status.
object
OTA confirmation code (VIA-…, GET-…); null for storefront bookings.
The OTA’s own booking reference (BR-…, GYG-…), normalised; absent when the booking has none.
Null when the booking’s obligation row is missing (the booking is then left out of the totals).
object
gross_minor − settled_minor; equals GET /obligations/{ref}/balance.
The condition a pin on this booking should carry: a balance due suggests obligation_settled/paid; null when nothing observable applies.
object
object
awaiting_us first, then by latest activity.
object
The thread’s state (open enum). notice: a bulk/system sender’s thread — in the stream and searchable, never waiting on us.
The condition a pin on this thread should carry: a thread awaiting us suggests outbound_on_thread; null otherwise.
object
object
object
object
Stable rule slug, e.g. fault_or_apology, amount_without_link, states_amount, no_cc.
The rule in operator words.
object
object
Active (non-cancelled) bookings.
Example
{ "room": { "ref_type": "person" }, "person": { "status": "active" }, "bookings": [ { "status": "created", "suggested_condition": { "kind": "obligation_settled" } } ], "threads": [ { "relay": "none", "suggested_condition": { "kind": "obligation_settled" } } ], "prospect": { "status": "inquired" }}Missing or invalid session bearer token
object
Stable, machine-readable reason code (e.g. “sold_out”, “processor_not_configured”, “rail_refused”).
Example
{ "reason": "sold_out"}The session’s effect authority does not cover this operation
object
Stable, machine-readable reason code (e.g. “sold_out”, “processor_not_configured”, “rail_refused”).
Example
{ "reason": "sold_out"}Expired, consumed, unknown, or unresolvable — indistinguishable by design
object
Example generated
{ "reason": "example"}key is not an email, person:{uuid} or booking:{uuid} (reason invalid_key).
object
Stable machine-readable error code
Human-readable explanation (never leaks SQL, URLs, or secrets)
Example generated
{ "code": "example", "message": "example"}No durable backend is wired for this operation (fail-closed)
object
Stable, machine-readable reason code (e.g. “sold_out”, “processor_not_configured”, “rail_refused”).
Example
{ "reason": "sold_out"}