The API for tour operators.
Read trips, sync bookings, manage CRM contacts, and react to events as they happen. Server to server, signed, and versioned.
- Resources
- 7
- Methods
- 23
- Event types
- 11
- Burst limit
- 60/s
GET
/api/v1/tripscurl https://app.tourical.com/api/v1/trips \
-H "Authorization: Bearer tk_live_…"200 · application/json
{
"data": [
{
"id": "cmb7q2f4k0001v9",
"tripNumber": "TR-2026-00042",
"title": "Balkan Loop",
"status": "active",
"publicSlug": "balkan-loop",
"daysCount": 9
}
],
"meta": { "cursor": null, "hasMore": false }
}Seven resources, one contract
Full endpoint referenceTrips
GETPOSTPATCH
Itineraries — list, fetch, create, partially update.
Bookings
GETPOST
The booking ledger for your published trips. Reads are live; creation hands off to the storefront checkout.
Clients
GETPOST
CRM contacts — list, fetch, create.
Payments
GET
The payment ledger per booking, read-only.
Libraries
GET
Your hotel, activity, vehicle and guide catalogs.
Webhooks
GETPOSTDELETE
Subscribe to events, rotate signing keys, inspect and replay deliveries.
Token introspection
GET
Read back the tenant, scopes, expiry and environment behind the calling token.
Read these once
Getting startedMint a token, make the first call, read the envelope.AuthenticationToken format, the ten scopes, storage, rotation, leak response.ErrorsEvery failure is a problem+json document with a stable type URL.Rate limitsTwo per-token buckets, and the headers that tell you where you stand.IdempotencyRetry any write safely with an Idempotency-Key.WebhooksSigned deliveries, a retry cascade, and replay when you need it.OpenAPI specificationThe machine-readable contract, generated from the running API.ChangelogWhat changed, and the deprecation and sunset rules.
Getting a token
Tokens are minted from the operator dashboard, on a plan that includes API access. One token per integration, each revocable on its own.

Need help? Write to developers@tourical.com.
