How to integrate a flight supplier API into your website

To integrate a flight API into your website, you connect your booking system to a flight supplier's service so it can search fares, confirm prices, create bookings and issue tickets for you. The work goes well beyond a search box: you also need logging, careful error handling and a certification review by the supplier before you can sell live. This guide covers each step in the order we usually follow.

An API (application programming interface) is a set of addresses and rules that lets one system talk to another. Your website sends a request, such as "one adult, economy, these two cities, this date", and the supplier's system sends back structured data with the flights and fares it can sell. If you are weighing up the whole platform rather than one connection, our OTA platform service page explains how we approach these projects.

What you need before you integrate a flight API

Most delays in a flight API project happen before any code is written. Getting these items ready first saves weeks of waiting later.

1. A commercial agreement with the supplier. Flight suppliers usually give API access only to registered travel businesses. Expect to share company documents and any licences or accreditations your market requires.
2. Test credentials. Suppliers normally provide a test environment, often called a sandbox. It behaves like the real system but never creates real bookings or tickets. You get one set of credentials for testing and a separate set for live use later.
3. The full documentation set. Ask for the API reference, sample requests and responses, the list of error codes and the certification checklist. Read the checklist first, because it tells you exactly what the supplier will test before switching you to live access.
4. Your business rules. Decide which routes, cabins and passenger types you will sell, how you will add your markup, and which payment methods you will accept. These choices affect almost every screen and every call.

Keep credentials out of your code repository. In a Laravel project they belong in the .env file, read through a config file, so test and live keys never get mixed up.

If you are still choosing a flight source, our comparison of GDS and NDC connections explains the differences in content, fares and technology.

Building search and handling large responses

Search is the call your site makes most often, and its responses can be large. A single search may return many flight options, each with several segments (the individual flights in a journey), fare details, taxes and baggage rules.

1. Validate input before sending anything. Check airport codes, dates and passenger counts on your side. Invalid requests waste your supplier allowance and slow the page down.
2. Set clear timeouts. A connection timeout limits how long you wait to reach the supplier. A response timeout limits the total wait for an answer. Without them, one slow supplier can leave customers staring at a loading screen.
3. Convert the response into your own format. Map the supplier's structure into simple objects of your own, such as offer, segment, fare and baggage. If you add a second supplier later, the rest of your site keeps working because it only knows your format.
4. Cache results for a short time. Store each search result for a few minutes so that filtering and sorting do not trigger new supplier calls. Keep this window short, because fares and seat availability change constantly.
5. Keep the data the supplier needs later. Each offer usually carries an identifier or a block of data that you must send back when you price or book it. Save it alongside the cached result.

Here is a short example of a search call using Laravel's HTTP client. FlightOfferMapper stands for your own class that converts the supplier's response into your format.

use Illuminate\Support\Facades\Http;

$response = Http::baseUrl(config('services.flight_supplier.url'))
    ->withToken(config('services.flight_supplier.token'))
    ->acceptJson()
    ->connectTimeout(5)
    ->timeout(30)
    ->retry(2, 500, throw: false)
    ->post('/search', $searchRequest);

if ($response->failed()) {
    return back()->with('error', __('We could not load flights. Please try again.'));
}

$offers = FlightOfferMapper::fromSupplier($response->json());

Retrying a search is safe because searching twice has no side effects. As the next sections explain, that is not true for booking.

If you plan to add hotels later, our guide on how hotel supplier APIs work explains how hotel APIs split static content from live rates.

Pricing, booking and ticketing calls

After search, a typical flight API has a sequence of calls that turn a chosen fare into a ticket. Names differ between suppliers, but the steps are similar.

1. Price check. Before the customer enters passenger details, confirm the chosen fare is still available and get the final price with all taxes. If the price has changed, show the new price clearly and let the customer decide.
2. Create the booking. Send the passenger details exactly as they appear on travel documents, plus contact details. The supplier returns a booking reference, often called a PNR (passenger name record). At this point seats are held, but no ticket exists yet, and there is usually a deadline for issuing one.
3. Take payment. Collect payment in a way that fits your flow. Many agencies authorise the card first and complete the charge only after ticketing succeeds, so a failed ticket does not leave the customer charged.
4. Issue the ticket. The ticketing call returns e-ticket numbers. Only now is the booking truly confirmed with the airline.
5. Retrieve the booking. A retrieve call reads the current state of a booking. You will use it for confirmation pages, support screens and status checks after errors.
6. Cancel or void where allowed. Suppliers have their own rules and time limits for cancelling bookings and voiding tickets. Build these calls in early so your team never has to do them by hand under pressure.

One rule matters more than any other here: never retry a booking or ticketing call automatically. If a booking request times out, you do not know whether the supplier created the booking. Sending it again can create a duplicate booking or a second ticket. Instead, check the result with a retrieve call or ask your operations team to confirm it with the supplier.

Logging every supplier request and response

Logs are your record of what really happened. You will need them to answer customer questions, settle disputes with suppliers, fix bugs and pass certification.

For each call, record:

1. The time, the operation (search, price, book, ticket) and how long it took.
2. Your own booking or search ID, so logs can be linked to a booking.
3. The request sent and the response received, including the HTTP status code.
4. Any error code or message returned by the supplier.

Mask sensitive data before storing it. Passwords, tokens and card details should never appear in logs, and you should only keep passport or identity details if you truly need them. Decide how long to keep logs, in line with the privacy laws that apply to your business.

We usually store booking-related logs in the database and show them on the booking screen in the admin panel. That way a support person can open a booking and see every call made for it, without asking a developer to search server files.

Handling errors and timeouts

Flight APIs fail in several different ways, and each needs its own response.

1. Input errors. The supplier rejects a name, a date of birth or a document number. Translate these codes into clear messages that tell the customer what to correct.
2. Business errors. The fare is no longer available or the flight is full. Explain this plainly and offer to run a new search.
3. Technical errors. The supplier is slow or returns a server error. For search, a short retry is fine. If it still fails, show a helpful message instead of an empty page.
4. Unknown outcomes. A booking or ticketing call timed out. Mark the booking with an "unknown" status, run a status check in the background and alert your operations team.

Run slow or risky steps, such as ticketing and status checks, as queued background jobs. Laravel's queues let a job run after the customer's page has loaded, with its own retry and failure handling. The customer sees a clear "we are confirming your booking" message instead of a page that hangs.

Finally, set up monitoring. You want an alert when a supplier starts failing more than usual, not an angry email from a customer the next morning.

Passing supplier certification

Certification is the supplier's review of your integration before they give you live credentials. Suppliers want to know you will not create bad bookings, overload their systems or leave customers without tickets.

1. Read the checklist at the start. Build what it asks for from day one instead of adding it at the end.
2. Run the required test scenarios. These often include one-way and return trips, different passenger types such as children and infants, price changes, cancellations and error cases. Your supplier's checklist is the source of truth here.
3. Collect logs for each scenario. Many suppliers ask for request and response logs as evidence. Good logging from the earlier step makes this straightforward.
4. Fix the feedback. Expect at least one round of comments. Treat it as free quality review from people who know their system best.
5. Go live carefully. Switch to live credentials in a controlled way and watch the first live bookings closely. Follow the supplier's rules for any live test bookings and cancellations.

If you also sell hotels, the same principles apply there, with some extra work on matching hotels between sources. Our guide on connecting multiple hotel suppliers to one booking engine covers that side.

When you move on to hotels, our comparison of hotel aggregator APIs and direct contracts helps you decide which sources to connect next.

Summary

• Get the agreement, test credentials, documentation and certification checklist before writing code.
• Convert supplier responses into your own format and cache search results only briefly.
• Retry searches if needed, but never retry booking or ticketing calls automatically.
• Log every request and response, masked and linked to its booking.
• Plan for certification from the start and go live in a controlled way.

A well-built flight connection is quiet: customers book, tickets arrive and your team rarely needs to step in. If you're planning to connect a flight supplier to your website, you can tell us about it here.