Overview
How StayBind is shaped, the surfaces you can integrate with, and where to start.
StayBind exposes two HTTP surfaces you integrate with, plus inbound webhooks. Everything is multi-tenant: a request is always pinned to one organization (an operator, a small chain, or a property-management company), and can only ever touch that org's data.
The surfaces
| Surface | Path | Auth | Who calls it |
|---|---|---|---|
| Booking API | /public/trpc/* | org-scoped API key | a storefront / front end built on StayBind |
| Channel webhook | /webhooks/channel/:connectionId | per-connection secret | your OTA, posting reservations in |
| Operator API | /trpc/* | session (cookie) | the StayBind operator console |
| MCP / AI | /api/mcp | OAuth token | AI clients acting under an operator's RBAC |
This documentation covers the two integration surfaces: the Booking API and the channel webhook. The operator API and MCP server are internal to the StayBind apps.
The mental model
Your OTA / booking source ──┐ reservations (webhook + pull)
Your storefront (Booking API)─┤ create booking
Airbnb · Booking · MMT ───────┤ reservations (via the OTA Network)
▼
┌────────────────────────────────────┐
│ StayBind availability ledger │
│ (single source of truth) │
└────────────────────────────────────┘
│ availability out
▼
every other connected channel stays in syncA reservation from any source writes the ledger; the ledger then fans the new availability out to every other connected channel. That is the whole promise: a booking anywhere blocks those dates everywhere, within seconds.
Where to start
StayBind for Developers
Connect a custom OTA, build a direct-booking storefront on the Booking API, and receive reservations over webhooks, all backed by one source-of-truth availability ledger.
Concepts
The availability ledger, channel adapters, the canonical reservation model, and the reliability guarantees that hold across every integration.