---
title: "AI Web Check-in API for OTAs, TMCs & Corporate Travel | Flyo"
description: "The world's first AI web check-in API. An agent checks passengers in on the airline's own site across 500+ airlines — not a scraper that breaks. First 100 free."
url: https://www.flyo.ai/en/web-check-in-api
lang: en
updated: 2026-09-03
---

# AI Web Check-in API for OTAs, TMCs & Corporate Travel

> An AI agent opens the airline's own website the minute check-in opens, checks your passenger in, picks the seat, and sends the boarding pass. Across 500+ airlines.

**URL:** https://www.flyo.ai/en/web-check-in-api

## In one paragraph

Flyo's AI Web Check-in API completes airline web check-in for a travel platform's passengers automatically and returns the boarding pass. It 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 website the moment check-in opens, works through the flow the way a person would, selects a seat from the live seat map, and delivers the boarding pass on WhatsApp and email. Coverage is 500+ airlines, 60,000+ check-ins have been completed in the last six months, integration takes about two days across three REST endpoints, and the first 100 check-ins are free on real bookings from a no-code portal.

## Key facts

| | |
|---|---|
| What it is | A REST API that completes airline web check-in for your passengers automatically and returns the boarding pass |
| How it works | An AI agent completes check-in on the airline's own website — the world's first, and not a hard-coded scraper |
| Built for | OTAs and booking platforms, TMCs, corporate travel desks |
| Airlines covered | 500+ worldwide, domestic and international, full-service and low-cost |
| Check-ins delivered | 60,000+ completed in the last six months |
| API uptime | 99.9%, measured monthly |
| Boarding pass delivery | WhatsApp and email, plus boarding pass URLs pushed back to you for your own app |
| Free tier | First 100 check-ins free, no card required |
| Testing | No-code portal on real PNRs, shared once you request access — no integration needed |
| Typical integration | About 2 days: three REST endpoints and one static API key |
| Security | CASA Tier 2 verified, encrypted in transit, API keys scoped per enterprise |
| Pricing | Free for the first 100, then $0.40 / $0.35 / $0.30 per completed check-in by monthly volume |

## Watch it work

A 2 min 11 sec walkthrough of the test portal — a real booking pasted in, the AI agent working through the airline's own check-in flow, and the boarding pass coming back: https://www.youtube.com/watch?v=BGI80F5c8Pk

## Try it before you integrate

Request access through the form at https://www.flyo.ai/en/web-check-in-api#get-access and we send portal credentials along with your first 100 free check-ins. Paste a real PNR and watch the check-in run end to end — no API keys to wire up, no engineering time to commit.

- **Real PNRs, not mock data.** Run the flow against live bookings on the airlines and routes you actually sell.
- **See the failure cases too.** Run deliberately incomplete bookings and the portal shows the exact `missing_info` codes your integration would receive (missing passport, missing date of birth, departure too close), so you know what to collect before you build.
- **First 100 check-ins free.** No card, no contract, no minimum. Billing starts only once you go past them.

## What is a web check-in API?

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, and passenger details once; the API completes the airline's check-in flow the moment the window opens and returns the boarding pass.

Check-in is the most repetitive job in post-booking operations: every ticket generates one, the window opens 24-48 hours before departure, and it almost always falls outside office hours. Automating it means:

- Travellers get their boarding pass automatically instead of a reminder to do it themselves.
- Check-in cost per booking stops scaling with volume — a desk that checked in 300 passengers a month can support 30,000.
- Check-in becomes a service you control and can charge for, and an upsell surface for seats, baggage, lounge access, and insurance.

## Airlines covered

500+ airlines worldwide, full-service and low-cost, domestic and international, with nothing hard-coded per carrier. Carriers partners run through the API most often:

- **India:** IndiGo (6E), Air India (AI), Air India Express (IX), SpiceJet (SG), Akasa Air (QP)
- **Middle East:** Emirates (EK), Qatar Airways (QR), Etihad Airways (EY), flydubai (FZ), Air Arabia (G9), Saudia (SV)
- **Asia Pacific:** Singapore Airlines (SQ), Thai Airways (TG), Malaysia Airlines (MH), AirAsia (AK), Cathay Pacific (CX), Vietnam Airlines (VN)
- **Europe & North America:** British Airways (BA), Lufthansa (LH), Air France (AF), KLM (KL), Turkish Airlines (TK), United Airlines (UA)

Coverage is not limited to that list. A subscribe call for an unsupported airline or route returns `REJECTED` with the reason immediately, rather than failing silently before departure. See "Which airlines are not supported?" below for the exceptions.

## How it works: one API call in, a boarding pass out

1. **You send us the booking** (the moment a ticket is issued). One POST with the PNR, the flight and the passengers, days or weeks before departure. Or paste it into the portal if you have not integrated yet. Nothing else is asked of you after that.
2. **Flyo watches for the check-in window** (until the window opens). Every airline opens check-in at a different time, and moves it by route and fare class. Flyo holds your booking and tracks when yours opens. There is nothing for you to schedule, poll or remember.
3. **The AI agent checks the passenger in** (the second check-in opens). The agent opens the airline's own website and works through the real check-in flow the way a person would: passenger details, passport and APIS forms, consent screens, then the live seat map for the seat preference you sent.

**If an attempt fails, it goes again on its own.** A page that times out, an airline that throttles, a seat map that will not load. The agent backs off and comes back, until check-in succeeds or the window closes. You never schedule a retry or watch a queue.

Then one of two things happens, and both are reported to you:

- **If it succeeds — The boarding pass goes out.** Delivered to the traveller on WhatsApp and email, and pushed back to you as URLs you can render in your own app. If the airline has not released the pass at that moment, the completed check-in is reported straight away and the pass follows automatically as soon as it is available.
- **If it cannot be completed — You are told exactly what is blocking it.** A passport number you never sent, a missing date of birth, a document the airline wants verified in person. You get a typed reason and a missing_info list with days still on the clock, not a silent failure on departure day.

**Either way, your system is told.** Every state change is pushed to your webhook — SCHEDULED, IN_PROGRESS, COMPLETED, FAILED — each with a human-readable message saying what happened. Nothing in this flow needs a person watching it.

### The subscribe request

```http
POST /extPartner/api/webcheckin/subscribe
X-API-Key: flyo_<issued-key>

{"pnr":"ABC123","flights":[{"airline":"6E","flight_number":"6E2341","origin":"DEL","destination":"BOM","departure_datetime":"2026-09-14T04:30:00Z"}],"passengers":[{"first_name":"Priya","last_name":"Sharma","email":"priya@example.com","phone":"+919876543210","seat_preference":{"row_preference":"front","column_preference":"window"}}],"callbackData":{"clientId":"acme","clientName":"Acme Travel","callbackUrl":"https://acme.example.com/webhooks/flyo","auth_header":"X-API-Key: A1B2C3D4E5F6G7H8"}}
```

## Boarding pass delivery

Check-in is only half the job: a completed check-in that leaves the traveller hunting for their pass has not saved anyone any work. The pass goes out the moment check-in finishes and comes back to the platform as URLs it can render itself.

- **WhatsApp and email** — both channels at once, so the pass is on the traveller's phone before they leave for the airport and still readable when the terminal wifi is not.
- **Or white-labelled in your own app** — every completed check-in returns `boarding_passes`, an array of HTTPS URLs (one per passenger and segment), on the status and list endpoints and in the webhook payload. Render them in your app or confirmation email and the traveller never sees Flyo.
- **Or pull it, if you would rather not rely on a push** — the same `boarding_passes` array is returned by the status and list endpoints, so a webhook you missed is never a boarding pass you lost.

The pass arrives as part of the same event that reports check-in completion. No second call and no polling loop:

```json
{"occurredAt":"2026-09-14T02:31:04.000Z","checkin_id":"CHK-783245","changes":{"status":"COMPLETED","sub_status":"BOARDING_PASS_AVAILABLE","checkin_message":"Check-in completed and boarding passes are available","missing_info":[],"boarding_passes":["https://files.example.com/boarding-pass.pdf"]}}
```

## An AI agent, not a scraper

Conventional check-in automation hard-codes each airline's website. When that airline ships a redesign, adds a step, or moves a button, the script breaks — usually silently, usually in peak season.

- **It reads the page, not a selector.** The agent looks at the airline's site the way a person does, so a new layout, an extra interstitial or a reworded button does not stop it.
- **New airlines without new code.** Nothing is hard-coded per carrier, so coverage extends without waiting on a release cycle.
- **It keeps trying.** If a page times out or an airline throttles, the agent backs off and returns until check-in succeeds or the window closes.

Endpoints, payloads and the webhook format live in the developer reference: https://www.flyo.ai/en/api-docs

## Capabilities

- **500+ airlines, one integration** — one schema instead of a check-in flow per airline. Unsupported routes return a typed REJECTED reason, never a silent failure.
- **Boarding passes where travellers are** — WhatsApp and email delivered together, or take the URLs and render them in your own app under your own brand.
- **Webhooks instead of polling** — register a `callbackUrl` and an auth header once; delivery is queued and retried.
- **Seat preferences** — a row preference (front, middle, back) and column preference (window, aisle, middle) per passenger.
- **Missing-info handling** — incomplete passenger data waits instead of failing, with a typed list of what to collect.
- **Enterprise-grade by default** — CASA Tier 2 verified, per-enterprise API keys, rate limits of 60 requests/minute and 1,000/hour, and a quota snapshot on every subscribe response.

## Who it is for

- **OTAs and booking platforms** — every ticket you sell gets checked in automatically, and the boarding pass arrives from you rather than the airline's app, so the traveller returns to your platform on departure day.
- **TMCs** — thousands of business travellers checked in without a consultant opening an airline website; the service desk stops absorbing check-in tickets at 2am.
- **Corporate travel desks** — seats assigned and boarding passes issued for every employee trip, with an auditable status per booking.

## Limits, edge cases and fine print

Every buyer asks these on the first call, and the answers are the ones with a caveat or a no in them. Here they are in public, before you look at the price.

### Which airlines are not supported?

A handful of carriers cannot be automated and we would rather say so than let you find out on departure day. The exceptions fall into three groups: airlines that require a mobile app or an airport kiosk and publish no web check-in at all, a small number of US carriers that gate check-in behind a logged-in loyalty account, and charter or codeshare-only operators with no public check-in page. Some routes are also excluded rather than airlines — India-to-US sectors requiring in-person document verification, for instance. You never have to guess which case you are in: a subscribe call for an unsupported airline or route returns REJECTED immediately, with the reason, instead of failing silently hours before the flight.

### What happens on low-cost carriers where every seat is paid?

Check-in still completes and the boarding pass is still issued — the agent takes whatever the airline assigns for free rather than buying anything. On carriers that charge for every seat, that usually means the airline allocates a seat at check-in and the agent accepts it. The agent never spends money on your behalf: paid seats, baggage and extras are surfaced back to you so you can offer them to the traveller in your own flow and keep the margin, which is the whole reason check-in is worth owning. If you want a specific paid seat taken automatically, that is a per-partner configuration rather than a default.

### Does it work on codeshare bookings?

Yes, as long as you send the operating carrier and its flight number rather than the marketing ones. A ticket sold as an AI-coded flight actually operated by another carrier has to be checked in on the operating airline's website, because that is the only site that recognises the PNR. Send the operating carrier's flight details in the flights array and the agent goes to the right place. If you only hold the marketing carrier's details, the subscribe call will come back REJECTED with the reason rather than trying and failing, and this is the single most common integration mistake we see in the first week.

### Where is passenger data stored, and how long do you keep it?

Passenger data is processed and stored on infrastructure in the India region by default, and EU or Middle East residency is available for enterprise partners who need it — raise it during onboarding rather than after, since it determines which environment your API key is issued in. Passport and identity fields are retained only as long as the check-in window needs them and are purged after departure; boarding pass URLs expire. If you have a specific retention window or a DPA to paper, that is handled per contract, and we will sign yours rather than insisting on ours.

### What does CASA certified actually mean?

CASA is the Cloud Application Security Assessment run by the App Defense Alliance, the security programme Google, Amazon and Meta founded. Flyo holds a Tier 2 verification, which means an independent assessor tested the application against the OWASP Application Security Verification Standard and checked how it authenticates, authorises and stores data — it is an audited assessment, not a self-declaration. In practice it is the bar a security reviewer at an OTA or a corporate procurement team asks for. It is not the same thing as SOC 2 or ISO 27001; if your review requires one of those specifically, ask us where that sits rather than assuming CASA substitutes for it.

### What if the traveller already checked themselves in?

Nothing breaks and you are not charged twice. A booking already checked in with the airline comes back as ALREADY_SUBSCRIBED on subscribe, or resolves to COMPLETED with the existing boarding pass attached, so your system converges on one state either way. This matters more than it sounds: in practice a meaningful share of travellers check themselves in the moment they get a reminder, and an automation that treats that as a failure generates support tickets for something that went right.

### Can it handle group and multi-passenger bookings?

Multi-passenger PNRs are the normal case — the passengers array takes as many travellers as the booking holds, each with their own passport details and seat preference, and the agent checks them in together in one pass so the group is seated together where the airline allows it. True group bookings held in a separate group PNR, the sort with twenty or more seats and a negotiated fare, are worth flagging during onboarding, because a few airlines handle those outside their normal web check-in flow entirely.

### How is this different from a GDS or an NDC check-in?

GDS and NDC give you booking, ticketing and servicing, but check-in is largely outside what they expose — which is exactly why so many OTAs still have a service desk logging into airline websites by hand despite a full GDS integration. This API sits after the ticket is issued and is deliberately agnostic about where the ticket came from: it takes a PNR and passenger details, whether the booking originated in Amadeus, Sabre, an NDC connection, a consolidator, or your own inventory. It replaces the manual work at the end of the funnel rather than any part of your booking stack.

## Pricing

First 100 check-ins free, no card required. After that, priced per completed check-in with no setup fee and no platform minimum.

| Monthly volume | Price per check-in |
|---|---|
| First 100 (one-off) | Free |
| 1 - 3,000 | $0.40 |
| 3,001 - 10,000 | $0.35 |
| 10,000+ | $0.30 |

Volumes above 50,000 check-ins a month are quoted directly.

## Building in-house vs. the Flyo API

| | Building it yourself | Flyo Web Check-in API |
|---|---|---|
| Airline coverage | One hard-coded scraper per airline, owned by your team | 500+ airlines, one AI agent, nothing hard-coded |
| Time to first check-in | Months of engineering per carrier | Test this week in the portal, integrate in ~2 days |
| When an airline changes its site | The script breaks silently; your on-call engineer | The agent reads the new page and carries on |
| Boarding pass delivery | Build WhatsApp and email pipelines yourself | Included, or white-labelled in your own app |
| Retries on failure | Your own scheduler, queue and backoff | Automatic until check-in succeeds |
| Cost model | Fixed engineering headcount regardless of volume | First 100 free, then from $0.30 per completed check-in |

## Frequently asked questions

Coverage exclusions, codeshare bookings, low-cost carriers, data residency and the CASA certification are answered under "Limits, edge cases and fine print" above.

### What is an AI web check-in API?

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.

### How is this different from a check-in scraper or bot?

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.

### What does the AI agent actually do during check-in?

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.

### Which airlines does the Flyo web check-in API support?

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.

### Does the web check-in API work with IndiGo, Air India and other Indian carriers?

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.

### How much does a web check-in API cost?

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.

### Is there a free trial?

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.

### Is there a demo of the web check-in portal?

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.

### Can we test the API before integrating it?

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.

### How long does it take to integrate the web check-in API?

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.

### Do we have to poll for status, or do you support webhooks?

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.

### What happens if the airline check-in fails?

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.

### Do you need passport details for international check-in?

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.

### Can we select seats through the API?

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.

### How are boarding passes delivered to passengers?

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.

### Can we white-label the boarding pass and the check-in?

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.

### Is the web check-in API secure and compliant?

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.

### Who is the Flyo web check-in API built for?

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.

### How many check-ins has Flyo completed?

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.

## Get access

Request portal access and API keys at https://www.flyo.ai/en/web-check-in-api#get-access, or email nitish@flyo.ai. Access includes the no-code test portal and the first 100 check-ins free.

---

_Source: https://www.flyo.ai/en/web-check-in-api_