API terms

API access is granted per account, with credentials scoped to specific capabilities. Credentials must not be shared, embedded in client-side code, or committed to source control.

Search endpoints exist to serve genuine customer demand. Scraping inventory, harvesting rates for a price-comparison product you have not disclosed, or generating searches disproportionate to bookings breaches these terms — and, more practically, it puts your supplier contracts at risk, because suppliers monitor look-to-book ratios closely.

Rate limits are set per account. Deliberately circumventing them, including by rotating credentials, is a breach.

Rates and content retrieved through the APIs are licensed for use in your own booking flow. Redistribution to third parties requires a separate agreement, because supplier contracts generally forbid it.

Cached content must respect the freshness rules documented per endpoint. Selling against stale availability is the fastest way to lose both customers and suppliers.

The API is versioned in the path. Additive changes may ship at any time; parse leniently. Breaking changes move to a new version with a published deprecation window once the API is generally available.

This document is a plain-language draft describing intended practice. It has not been reviewed by counsel and is not yet an executed agreement. Before any commercial engagement, a reviewed version will be issued and will govern. If you need the binding text now, ask and we will tell you honestly that it is in preparation.