Skip to content

Developers

TravelCore API documentation

Written for the person who will actually integrate this, including the parts that will go wrong. The hotel surface is in design-partner preview; the rest is documented so you can design against it before it exists.

Request sandbox accessService status

Rate limits

What the limits are, how they are communicated, and how to stay inside them.

Limits exist because searches cost suppliers money too, and a look-to-book ratio that runs away will get your supplier contracts reviewed. The limits below are the sandbox defaults; production limits are set per account against your forecast.

SurfaceSandbox defaultWindow
Token endpoint30 requestsper minute
Search endpoints60 requestsper minute
Content and rate checks300 requestsper minute
Booking writes30 requestsper minute
Read endpoints600 requestsper minute

Response headers

Headers
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 41
X-RateLimit-Reset: 1756377660
Retry-After: 19
  • On 429, honour Retry-After. Retrying sooner extends the window rather than shortening it.
  • Cache tokens. Token-endpoint pressure is the most common cause of a 429 in a new integration.
  • Cache static content (property descriptions, images, amenities). It changes rarely and does not need to be fetched per search.
  • Do not poll booking status. Use webhooks.
PreviousWebhooksNextSandbox