AI Web Check-in API for OTAs, TMCs & corporate travel

A web check-in API is a REST interface that lets a travel platform check passengers in with the airline automatically, without anyone visiting the airline's website. You send the PNR, flight details, and passenger details; the API completes the airline's check-in flow when the window opens and returns the boarding pass. Flyo's is the world's first to do that work with an AI agent rather than hard-coded scripts: the agent opens the airline's own site and works through check-in the way a person would.

A scraper is written against one airline's page structure — specific buttons, specific field names. When that airline ships a redesign, adds a consent step, or moves a button, the script breaks, usually silently and usually in peak season. Flyo's agent reads the page instead of following hard-coded selectors, so a new layout, an extra interstitial or a reworded button does not stop it. It also means coverage extends to new airlines and routes without waiting on a release.

It waits for the exact moment that airline and route opens check-in, opens the airline's own website, and works through the flow: passenger details, passport and APIS forms, and any health or consent declarations that carrier asks for. It then reads the live seat map and takes the best free seat matching the row and column preference you sent, completes check-in, and sends the boarding pass to the traveller on WhatsApp and email while pushing it back to you.

Over 500 airlines worldwide, covering both full-service and low-cost carriers on domestic and international routes — IndiGo, Air India, Air India Express, SpiceJet and Akasa Air in India, Emirates, Qatar Airways, Etihad, flydubai and Air Arabia across the Gulf, and Singapore Airlines, Thai, AirAsia, British Airways, Lufthansa, Turkish and United further afield. Flyo has completed more than 60,000 check-ins across them in the last six months. You integrate once against a single schema rather than building a separate check-in flow for each airline. The carriers and routes that are not supported are listed under limits, edge cases and fine print, and a subscribe call for any of them returns REJECTED with the reason rather than failing later.

Yes. IndiGo, Air India, Air India Express, SpiceJet and Akasa Air are among the most-used carriers on the API, and Indian domestic routes are the highest-volume traffic Flyo handles. IndiGo in particular is worth automating because it charges for check-in at the airport counter if the passenger has not checked in online, so an automatic web check-in removes a fee your traveller would otherwise be surprised by. International carriers out of India — Emirates, Qatar Airways, Etihad, flydubai, Singapore Airlines, Thai, Lufthansa, British Airways and Turkish among them — are covered on the same integration.

The first 100 check-ins are free. After that Flyo prices per completed check-in on a volume-tiered basis: $0.40 per check-in up to 3,000 a month, $0.35 from 3,001 to 10,000, and $0.30 above 10,000. There are no setup fees and no platform minimums, and you are not charged for check-ins that never ran. Volumes above 50,000 a month are quoted directly.

Your first 100 check-ins are free, with no card and no contract. They run against real PNRs rather than sandbox stubs, which is enough to prove the flow across your busiest routes and carriers. Billing only starts once you go past the first 100.

Yes. There is a two-minute walkthrough on this page showing a real booking pasted into the portal, the AI agent working through the airline's check-in flow, and the boarding pass coming back at the end. It is also on the Flyo YouTube channel if you want to forward it to a colleague before booking a call.

Yes, and without writing any code. Request access through the form on this page and we send you portal credentials along with your first 100 free check-ins. In the portal you paste a real PNR and watch the check-in run end to end on the airlines and routes you actually sell. You can also run deliberately incomplete bookings to see the exact missing_info codes your integration would receive — missing passport, missing date of birth, departure too close — so you know what data to collect before engineering starts.

Most partners are live in about two days once they start integrating, and can test in the portal first before committing any engineering time. There are only three endpoints — subscribe a booking, get the status of one check-in, and list your check-in requests — plus an optional webhook. Authentication is a single static X-API-Key header with no token refresh flow to build.

Both. Send a callbackData object when you subscribe a booking and Flyo pushes webcheckin.update events to your callback URL, forwarding an auth header you choose so you can verify each request. If you would rather pull, the status and list endpoints return the same normalized payload on your own schedule.

Failed attempts are retried automatically until check-in succeeds or the check-in window closes. You are not responsible for scheduling retries. Every state change — SCHEDULED, IN_PROGRESS, COMPLETED, or FAILED — is pushed to your webhook with a human-readable checkin_message explaining what happened, and you can reproduce the same failure modes in the portal before you go live.

For most international routes the airline requires passport number, expiry date, and nationality. You do not need them at the moment you subscribe: the attempt is stored as SCHEDULED with a MISSING_INFO sub-status and a typed missing_info list, so you can collect exactly what is missing from the traveller before the check-in window opens.

Yes. Each passenger accepts a seat_preference object with a row preference (front, middle, or back) and a column preference (window, aisle, or middle). Flyo applies it during check-in wherever the airline allows free seat selection, which makes check-in a natural place to upsell paid seats and other ancillaries.

Flyo delivers the pass to the traveller on WhatsApp and email, within seconds of check-in completing. Sending on both at once is deliberate: it means the pass is already on the phone before they leave for the airport, and still readable when the terminal wifi is not. The same boarding pass URLs are pushed to your webhook and returned on the status endpoint, so you can put the pass in your own app as well.

Yes, and most partners do. Every completed check-in returns boarding pass URLs in the boarding_passes field — on the status and list endpoints and in the webhook payload — so you can render the pass inside your own app or your own confirmation email with no Flyo branding anywhere in the traveller's path. The two options are not exclusive: plenty of partners take the URLs for their own app and let Flyo's WhatsApp message run as a backstop for travellers who never open it.

Yes. Traffic is encrypted in transit, and Flyo holds a CASA Tier 2 verification, which is explained in full under limits, edge cases and fine print, along with where passenger data is stored and how long it is kept. Every API key is scoped to a single enterprise, so a check-in belonging to another enterprise is indistinguishable from one that does not exist. Keys are issued and revoked from the partner dashboard, and rate limits are enforced per key at 60 requests per minute and 1,000 per hour.

OTAs and booking platforms, TMCs, and in-house corporate travel desks — any team that holds the booking and is currently checking passengers in by hand. It is designed for organisations where check-in volume has outgrown the service desk, and where the boarding pass should come from you rather than the airline's own app.

More than 60,000 completed web check-ins in the last six months, across over 500 airlines. That volume is the reason the agent handles the awkward cases — the extra consent screen, the interstitial that only appears on one route, the airline that reworded a button last week — rather than only the clean ones.