Integrations overview

Who this is for: Owner, and the developers an Owner account is opened for — of the default roles only Owner carries integration.mcp.connect, integration.apikey.manage or integration.webhook.manage. Where: Integrations

This section is the developer surface inside the product: the screens where you issue a scoped key, subscribe a system to events, connect an agent, and try a call before you write any code against it. It is not the endpoint documentation — that is Integrations → API Docs inside the product, which renders the OpenAPI contract the server is running, and it describes the wire. These pages describe the screens you configure the wire from.

Six screens. Everything a developer configures inside the product is one of these.

Nothing here is on until somebody turns it on#

The Integration Hub is off on every new property. A property is created with Front Desk, Reservations, Housekeeping, Accounting, Inventory and Point of Sale switched on, and nothing else. Integrations is not in that list.

This is the single most common reason a developer is told "it's in Integrations" and finds no Integrations.

The Hub switched off. There is no Integrations group in the menu, and no error anywhere — a disabled app is invisible, not refused.

A menu item needs two things, not one#

Every item in the left-hand nav is shown when both are true:

1. the app that owns it is enabled on the property you are in, and
2. your role holds the permission that item requires.

Miss either and the item is simply absent. There is no greyed-out row and no "upgrade" prompt, which is why a missing menu is ambiguous from the outside and worth diagnosing in that order — property first, role second.

重要

App enablement outranks your role — Owner included. A disabled app does not merely hide its menu items: its permissions stop resolving at all. An Owner in a property with the Hub switched off holds no integration.* permission, so the screens are unreachable and the API refuses the same calls. Switching the app on is what makes those permissions exist for that property.

You can watch it happen. The property below is the same one, one toggle later:

Eight apps, and the permission count went 97 → 101. Enabling the app is what made its four permissions resolvable; the role did not change.

Switching the Hub on#

App enablement lives on Settings → Hotel, under the property's App enablement block. It needs app.enable, which belongs to core — the one app that is never gated — so this screen is reachable whatever else is switched off.

1. Open Settings → Hotel.
2. Find the property.
3. Switch Integration on.

The Integrations group appears in the nav on the next request. Nothing else has to be provisioned: no key is minted, no endpoint is created, nothing starts sending.

注意

Enablement is per property, not per organisation. A group with two hotels switches the Hub on twice, and a key minted at one property does not read the other.

Who works here#

Role	Integrations
Owner	Everything — keys, webhooks, MCP, the playground, the API docs
Manager	App enablement only (apps.manage). No key, no webhook, no MCP connection
Front Desk	Nothing
Accountant	Nothing
Storekeeper	Nothing
Read-only	Nothing

The practical consequence: integration work is done from an Owner account, or from a role somebody has built for it. There is no shipped "developer" bundle, and the Manager bundle deliberately stops short of one — a Manager can decide which apps a property runs, and cannot mint a credential that reads its data from outside.

Roles are configurable, so this is the default rather than a rule. If you are building a developer role, the three permissions to think about are:

Permission	Grants
integration.apikey.manage	Create and revoke API keys, and read the integration audit log
integration.webhook.manage	Create webhook endpoints, and replay their deliveries
integration.mcp.connect	Connect MCP agents, use the playground, read the API docs

A key can never carry a permission the person who created it does not hold, so these three bound what an integration built by that person can ever do.

What's in this section#

• API keys — scoped credentials for the public API, and the one thing about them you cannot undo. integration.apikey.manage
• Webhooks, retries and replay — signed delivery, what happens when your receiver is down, and why replaying is safe. integration.webhook.manage
• MCP agents — connecting an AI agent so that it can only do what its credential allows. integration.mcp.connect
• The playground — a short-lived key and a live call, without leaving the product. integration.mcp.connect
• Embedding the direct booking widget — selling direct from your own site against the same inventory. crs.vanityproperty.manage

Two of the six screens have no page of their own.

API Docs renders the OpenAPI contract the server is actually running, so it is always current in a way a written page cannot be — read it there rather than anywhere else, and download the schemas from it.

App Directory is the catalog of installable apps. Switching an app on or off for a property is documented above, on Settings → Hotel, which is the route that works whatever is currently enabled — including when the Integration Hub itself is off.

How it connects#

Open Hotel Protocols is the reason this section exists. Keys, events and MCP tools are three views of one contract rather than three integrations bolted on — see Open Hotel Protocols.

Everything an integration does is scoped by the same permission model as a person. A key is not a back door around roles; it is a role, narrowed. Roles and what each one can do is the same list a key is built from.

Every external call is audited. A key's reads, a webhook's deliveries and an agent's tool calls land in the organisation's audit log with the same shape as a human action — actor, target, outcome.

A booking made through the widget is an ordinary reservation. It arrives at the front desk with a folio, counts as direct in analytics, and is bound by the same restrictions as any other channel.