Permissions
Areas and levels — what each permission lets a key read and change.
A key's permissions are areas × levels. Each area is off, read, or write; write includes read. A permission never widens what the key's owner can do in the app: it only narrows it.
| Area | Read | Write | Covers |
|---|---|---|---|
trips |
12 operations | 13 operations | Trips, their itinerary, design and metadata; change history and undo. |
catalog |
14 operations | 16 operations | The catalog (places, accommodation, activities, routes), the block library and trip templates. |
quotes |
5 operations | 9 operations | Quotes, their lines and packages, and quote templates. |
documents |
7 operations | 8 operations | Trip documents and folders. |
travelers |
4 operations | 7 operations | Passengers, the booking contact and app access. Every read is audited. |
Scopes are spelled area:level — trips:read, quotes:write. Each reference page and each MCP tool names the scope it needs. A call without it answers 403 insufficient_scope, and over MCP the tool is simply not offered.
Webhook subscriptions need no extra permission, but each event type needs read on its area: a key with travelers off cannot subscribe to traveler.added.
Choosing
Give each integration its own key with the least it needs. A reporting job needs trips:read; a booking sync that writes passengers needs travelers:write. Separate keys also make the activity log readable.