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.

Flyo schedules check-in for the airline window and works through the airline website using the supplied passenger details and seat preferences. Available boarding-pass URLs are returned through status and callbacks for your system to display or deliver.

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. Confirm carrier and route coverage during onboarding. Missing check-in timing can lead to manual fulfillment, reported as SCHEDULED, rather than immediate rejection.

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 four endpoints — subscribe a booking, get its status, list requests, and update missing passenger details or a PNR — 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.

Follow status and checkin_message to track fulfillment. Failed automation may be handled manually; do not assume a retry schedule or a successful boarding pass. If you configured a callback, reconcile webhook updates with the status endpoint. Collect any missing passenger information and send a complete passenger update when requested.

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 rear) 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.

Available boarding-pass URLs are returned in boarding_passes on status, requests and callback events. Your system can display them in your app or send them through your own email or messaging flow. COMPLETED does not always mean a pass is already available.

Yes. Use the URLs in boarding_passes to display available passes inside your own app or send them through your own confirmation email. The array may be empty even when check-in is COMPLETED; use sub_status and keep checking for updates. Passenger or segment mapping is not exposed in this array.

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.