3. API Reference
Common headers
Every transaction accepts the same set of request headers. Only Authorization is always mandatory; the rest are optional until a feature or account restriction needs them. Send them consistently — they are how the platform attributes, localises, traces and bounds your calls.
Request headers
| Header | Required | Type | Description |
|---|---|---|---|
Authorization |
Yes | string | Bearer credential. The value must be prefixed with Bearer — the token comes from the Ticket response (or an OAuth 2.0 access token; see the API Reference authentication section). The Ticket call itself does not require this header. |
Session-Id |
Booking flow | string | Recommended on every client request, and mandatory throughout the booking flow — HotelRates, CheckAvail, Book and Cancel. See Conventions — Sessions. |
Request-Id |
No | string | Identifies this single request. Values must not repeat across requests — a duplicate is the client's bug, and the echo of the value in the response is how support finds the exact call. |
Trace-Id |
No | string | Correlates a group of related requests. Send the same value for everything belonging to one traveller journey or one batch job. |
Language |
No | string | IETF BCP 47 language tag, e.g. "en", "en-US", "ar". Defaults to en-US. |
Currency |
No | string | ISO 4217 code for the currency rates should be quoted in, e.g. USD, EUR, AED. USD is the default; other majors are supported where the supplier permits. |
Market |
Conditional | string | Point-of-sale market for this call, as an ISO 3166-1 alpha-2 country code. Required only when your account carries a market restriction: an allow-list cannot admit a market you have not stated, so such an account refuses calls that omit it. |
User-Ref |
Conditional | string | Your own identifier for the person on whose behalf this call is made. Required only once named users have been authorised on your account, after which every call must identify one and is authorised against that user's scopes as well as the key's. |
Client-Request-Timestamp |
No | integer | Client request time (when the client began sending the request), as a unix timestamp. |
IP |
No | string | Client IP address; accepts both IPv4 and IPv6. |
Timeout-Milliseconds |
No | integer | Client-imposed timeout; the server makes a best effort to respond within it. |
Test |
No | string | Test switches as key-value pairs, e.g. hotel=HC1&scenario=priceChange. Unrecognised values are ignored and the call proceeds as if the header had not been sent — see Test more scenarios. |
Response headers
| Header | Description |
|---|---|
Request-Id |
Echo of the request identifier, or the server's value when you did not send one — quote it when contacting support. |
Trace-Id |
Echo of the trace correlation value. |
Session-Id |
The verified session id for the flow. |
Server-Cost-Milliseconds |
Server-side processing time for the call, in milliseconds (e.g. 500). |
X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset |
Rate-limit counter state for the endpoint just called — see Rate limit. |
Retry-After |
Sent on a 429 only; the number of seconds to wait before retrying. |
Tracing in practice
A typical integration sends:
Request-Id: 9d1f4b2a-7c60-4f3e-9a58-1b0c2d3e4f50 (fresh UUID per call)
Trace-Id: checkout-2026-01-01-0001 (one per user journey)
Session-Id: 374337a797454a344ad999c7730da01c (one per search-to-book flow)When something goes wrong, the platform can follow Request-Id to the exact call and Trace-Id across the whole journey — include both, plus the timestamp, when you write to integrations@ttdbooking.com.
Need help?
Questions about headers or request context: integrations@ttdbooking.com Full documentation: developer.ttdbooking.com/hotel-api/docs