API terms of use

1. Access and keys

• API access is requested from your dashboard and granted after review. We may ask what you are building, for which market and at what volume, and we may decline or limit access at our discretion.
• An API key is issued to one account for one product or integration. It is shown once and stored hashed. Keep it on your servers; never place it in a browser, a mobile app, a public repository or a support ticket.
• You must whitelist the server addresses that will call the API. Calls from other addresses are refused. You are responsible for keeping the list current.
• You are responsible for every call made with your key until you tell us it is compromised. Rotate keys when staff with access leave.
• Sandbox or evaluation access, where offered, returns test data and must not be used for real bookings or shown to end customers as live.

2. Licence

We grant you a limited, revocable, non-exclusive, non-transferable licence to call the API and to use the data it returns inside your own product for the purpose of searching, pricing and booking flights for your customers, in accordance with these terms, the rate limits and fair use rules and the Acceptable Use Policy. All other rights are reserved.

3. What you may do

• Display search results and fares to your customers in your own interface, with or without your own mark-up or service fee.
• Book flights for your customers through the API, paid from your prepaid balance.
• Store booking records, tickets and passenger data that you need to service the bookings you made, for as long as you need them and as the law allows.
• Cache search results for the short period the response headers indicate, to serve the same customer session, provided the age of a cached result is respected and a price is re-validated before booking.

4. What you may not do

• Resell, sublicense, redistribute or syndicate API data to third parties, or build a fare database, price-comparison feed or data product from it, without our written agreement.
• Present cached or stale results as live, or book from a price that was not re-validated.
• Poll the API to monitor fares, scrape it, or generate searches that are not driven by a real user or a real business process. Automated searching without a proportionate number of bookings (an abusive look-to-book ratio) may lead to limits or suspension, because our suppliers charge us for it.
• Remove or alter airline names, codes or fare rules from results shown to customers, or hide conditions that affect the customer's decision.
• Use the API in breach of any law, sanction or third-party right, or for any purpose other than genuine flight sales.
• Reverse engineer the API, probe it for vulnerabilities outside our disclosure rules, or work around rate limits, key scoping or address whitelisting.

5. Bookings made through the API

A booking made through the API is a booking made by you under the Terms of Service, paid from your balance, and governed by the airline's fare rules and the refund policy. You are responsible for the accuracy of the passenger data you send, for informing your customers of the fare conditions, and for passing on schedule changes we notify to you. Booking endpoints are idempotent where documented; use the idempotency key so that a retried request never issues twice.

6. Your product, your brand

You may present flights under your own brand. You may not state or imply that IATA.co is the airline, that we guarantee a fare, or that your product is operated by us. Do not use our name or logo in a way that suggests endorsement without our written consent.

7. Changes and versions

We may add fields and endpoints at any time; your integration must ignore fields it does not know. For breaking changes we publish a new version and keep the previous one available for a reasonable period, normally at least 90 days, announced by email to API account holders and in the documentation. Emergency changes required by a supplier, by law or for security may be shorter.

8. Availability and support

We aim for the API to be available at all times but we do not promise uninterrupted operation; suppliers and networks fail independently of us. Planned maintenance is announced in advance where possible. Support for integration questions is available by email; see contact. Include the request id from the response headers.

9. Suspension and termination of access

We may suspend or revoke a key or API access at once where we see a breach of these terms, a security risk, abusive traffic, unpaid amounts or a supplier requirement, and otherwise with reasonable notice. On termination you must stop calling the API and delete cached results, but you may keep the records of bookings you made.

10. Liability

The API and its data are provided as they are. The limitations and exclusions of liability in the Terms of Service apply to the API, and you indemnify us against claims arising from your product, your customers and your use of the data.