Ask someone who has worked an airline check-in desk what Timatic is and the answer takes one sentence: it is what tells you whether the passenger boards. That sentence is accurate, and it is also the design brief. Almost everything the system does well follows from it, and so does everything it leaves alone on purpose.
If you fly people, that brief is your brief. If you sell them trips, it covers one moment of yours and stops short of the rest. The line between the two is worth drawing precisely, because a lot of buying decisions get made on a fuzzy version of it.
What Timatic is, and who runs on it
Timatic is IATA's travel documentation database. It has been in service since 1963, which makes it older than most of the border regimes it describes and very much older than any API you have integrated this decade. Airlines consume it inside check-in itself: the AutoCheck product wires the verdict into departure control, so the agent gets a decision on the passenger standing in front of them without leaving the workflow. Star Alliance carriers are among the airlines running on it, and the footprint across the industry is wide enough that most international check-ins you have been through were backed by it whether the agent named it or not.
The content underneath is curated rather than crawled. IATA puts its source network at more than 2,000 government and airline sources, and publishes the result as six databases: passport, visa, health, airport tax, customs and currency. The first three feed the personalised check on a named passenger. The other three are country reference material that a human reads.
The question it answers
The check takes a passenger and an itinerary: nationality, destination, the transit stops in between, and the documents actually held. It returns whether the documentation is sufficient for that journey. The verdict has three states rather than two: yes, no, and conditional.
That third state is the honest one, and it is a large part of why the system has lasted. Entry rules are full of conditions that no database can settle on its own, because they depend on something the record cannot see: a visa held for a third country, an onward ticket, how long the stop actually lasts, which vaccination certificate is in the bag. A binary engine would have to guess. Timatic hands the condition back to the agent and lets a person resolve it.
Notice who the answer is for. The consumer is a carrier carrying a legal exposure. Fly someone who should not have been flown and the fine, the return sector and the handling all land on the airline. Timatic exists to protect that decision at the moment it is taken, and it is very good at protecting it.
Where the answer stops
A boarding verdict is a fact about a passenger. It moves nobody closer to holding the document. Once the verdict says a visa is required, four things still have to happen, and none of them are in scope:
None of this is a flaw. A check-in engine that also took card payments and chased consulates would be a worse check-in engine, and IATA has never suggested otherwise. The confusion lives on the buying side, where a travel seller reads "travel documentation" and assumes the traveler's problem is handled. The traveler has been told something true. Nobody has done anything for them yet.
Telling a traveler they need a visa and getting one into their hands are two different products. Only the second one ends with a document.
Which one you need
Three jobs sit around the visa moment, and they happen at different times, to different people, under different pressure. Sorting your requirements by which job you are actually doing makes the tooling question answer itself.
Airlines need all three rows and usually staff them separately. Online agencies, tour operators and corporate travel platforms rarely need the first row at all, because the carrier owns that decision and the liability attached to it. Their money and their support load sit in rows two and three, which is where a requirements-plus-fulfilment layer belongs: requirement data across 190-plus destinations, and end-to-end processing on the 60-plus we handle ourselves.
Running both
These are complements, and the sequencing is the interesting part. Compliance runs at the gate, hours before departure, with no time left to fix anything. Resolution runs at booking, with weeks of runway. Every document problem you catch in the second place is a problem the first place never has to catch.
Leave the boarding check where it is. If you operate flights, do not try to replace a check-in verdict with a commerce API. Different job, different liability. Nothing below asks you to move it.
Pull the discovery forward to the sale. The passport and the full routing are known at booking, transit stops included. Resolving requirements there gives the traveler weeks instead of the four hours they get from a desk agent who has just delivered bad news.
Make the answer something they can act on. A requirement with no way to satisfy it sends people to a search engine, which is where lookalike sites are waiting with a markup on a consular fee. Put the application next to the finding and the trip stays inside your flow.
There is a practical version of this argument that lands with ops teams faster than the revenue one. A meaningful share of what shows up at the desk as a documentation failure began weeks earlier, with a traveler who was never told in time to do anything about it. Those cases arrive as a conditional or a refusal at the worst possible moment, and they cost rebooking, goodwill and a review. Catching them at checkout converts the desk check into what it should be, which is a formality that confirms a document the passenger already holds.
GET /v1/requirements takes the passport and the routing, transit stops included, and returns what the journey requires, the processing expectation, and the consular fee at cost. Where we process end to end, the same route continues into an application and a status feed on the booking. The response shape is documented for developers, and sandbox keys come with signup.
One thing to plan for if you run both: they will occasionally disagree. Two curated datasets with different sources and different update cadences will not always publish a rule change on the same day, and a traveler who reads one answer at booking and hears another at the desk remembers only that your brand said something wrong. The desk verdict wins at the gate, always. What you want is a way to see the disagreement early, which means both a timestamp on the rule you showed and a route back to whoever curated it, so a discrepancy becomes a support answer instead of an argument.
Timatic has spent six decades getting one question right, and the airline industry is correct to keep running on it. The mistake worth avoiding is treating a boarding verdict as the whole of the visa problem. It answers whether a traveler may fly. The rest of the work is making sure that by the time anyone asks, the answer is yes.