A named key per channel
"Web principal", "App móvil", "Agencia Roma": as many keys as channels, each named for what it is, so a leak or a mistake traces back to one integration, never the whole account.
Booking API
The same door our own dashboard walks through.
There's no separate, lesser version of Tiqory for integrations. A WordPress plugin, a reseller connection or our own admin panel all call the exact same engine, through a key scoped to exactly what it needs.
- 5 abilities products.read, checkout.create, leads.create, support.create and feedback.create, granted independently per key
- 10 to 10,000/min Each key sets its own rate limit, isolated from every other key on the account
- Shown once The full secret appears a single time; Tiqory only ever keeps its hash and a lookup prefix
Four pieces of access control.
Each one narrows what a given integration can actually do, without narrowing what the platform itself can do.
Scoped abilities, not a master key
A key gets exactly the abilities it needs, reading a product, creating a checkout, sending a lead, never blanket access to everything the API can do.
Public where it helps, gated where it doesn't
Each organization decides per ability whether a browser can call it directly or whether it must route through a server holding a key. Leads, support and feedback always require one.
Instant rotation and revocation
A compromised key gets rotated, and every caller still using the old secret stops working on their very next request, with no token expiry to wait out.
How it resolves
How a call gets authorized, step by step
Five steps, every single time a request carries an API key.
- 1
The key gets authenticated
The plaintext key arrives as prefix.secret. The prefix looks up the row, then the secret gets compared against its stored hash with a constant-time check, never a plain equality.
- 2
The ability gets checked
The requested action must appear explicitly in that key's granted list. Missing it returns the same generic error whether the key exists or not.
- 3
The key's own limiter applies
Traffic on that key counts against its own configured rate limit, isolated from any other key on the same account. Keyless public traffic counts by IP address instead.
- 4
Every query runs scoped, automatically
Once authenticated, the call operates inside that key's organization only. There's no path from one key to another tenant's catalog, even by guessing an internal id.
- 5
The call gets recorded
Last used time and the calling IP update on every successful request, so an idle or forgotten key becomes visible long before anyone thinks to go looking for it.
The API, as it is
One call, the whole storefront payload
A product looked up by its public alias returns its options, ticket types, available dates, resolved prices and remaining capacity, already correct for the requesting currency and country.
GET /api/v1/products/city-food-tour
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
{
"data": {
"name": "City Food Tour",
"alias": "city-food-tour",
"currency": "EUR",
"options": [
{
"code": "general",
"next_slot": "2026-08-14T10:00:00+02:00",
"remaining": 12,
"price": {
"amount": 42.5,
"currency": "EUR"
}
}
]
}
}200 Product resolved
The detail almost nobody explains
A wrong key and someone else's product look identical
A product that belongs to a different organization and a product that simply doesn't exist both return the exact same "not found", never a permission error that would confirm the product exists somewhere else. An invalid or revoked key gets its own distinct error, but nothing in any response ever reveals whether the resource being asked for belongs to another tenant.
Frequently asked questions
Rotate it. Rotation immediately issues a new prefix and secret and invalidates the old pair, so every caller still using the leaked secret starts failing on its very next request, with no propagation delay to wait through.
No. Every query authenticated by a key runs scoped to that key's own organization. A product belonging to someone else returns the same "not found" as one that doesn't exist at all.
No. products.read and checkout.create can run directly from a browser if the organization leaves them public. leads.create, support.create and feedback.create always require a key, since they exist specifically to be called from a server the organization controls.
A sensible per-ability default, counted by IP address: generous for browsing, tighter for creating a checkout or sending a lead. A key overrides that default with its own configured limit, from 10 to 10,000 requests per minute.
A 429 response with a Retry-After header, plus the limit and remaining request count, so an integration can back off automatically instead of guessing when to try again.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.