An eVisa API exposes the visa process as endpoints: ask what a passport needs for a route, submit an application with its documents, and receive status changes as they happen. Those three calls are the whole surface. They exist so that a booking flow can handle the visa moment where the booking already is, without sending the traveler off to a government portal, a search engine, or one of the lookalike sites that outrank both.
Vendors name and version their endpoints differently, but any serious eVisa API resolves to those same three jobs. The differences that decide an integration sit behind the endpoints.
The three surfaces
A requirements endpoint
In: a passport (nationality, sometimes country of residence), a destination, and the route, including every transit point. Usually the travel dates and the purpose of travel as well, because both change the answer.
Out: whether an authorisation is needed at all, which scheme applies, the documents that scheme requires with their specifications, the government fee, the service fee, quoted processing times, and the validity and entry rules an approval carries.
This call is read-only and repeatable, so it is safe to run early and often. Latency matters more here than anywhere else in the integration: a lookup that takes two seconds will not survive contact with a search results page.
Transit is where requirements endpoints separate. A Paris to Doha to Malé itinerary can require a document for the stop, and an API that reads only origin and final destination returns a confident wrong answer. Ask how a vendor handles a connection, then test it with a real multi-leg route before you believe the reply.
An applications endpoint
In: the traveler’s details, matched character for character to the passport, plus the files the destination requires: a passport scan, a photograph to a published specification, and depending on the scheme an itinerary, an accommodation booking or an invitation letter. Out: an application object with an identifier, a state, and the amount charged, broken into consular fee and service fee.
Two mechanics are worth checking closely. The first is idempotency. A create call should carry a key you generate, so that a retry after a timeout returns the original application rather than filing and charging a second one. Networks fail mid-request, and without that key your retry logic quietly becomes a duplicate-charge generator.
The second is where validation happens. A good implementation rejects a mismatched name or an out-of-spec photograph inside your API call, with a field-level error you can render while the traveler is still on the page. A weak one accepts everything and surfaces the same problem as a government refusal three days later, when the fee is spent and the traveler has stopped reading your emails.
Webhooks
Applications sit in a government queue for hours or days, so decisions arrive asynchronously. Webhooks push those changes to an endpoint you own: submitted, information requested, approved, refused, document ready. Polling a status endpoint on a timer does work, badly. It burns rate limits, it adds delay proportional to your interval, and its cost scales with the number of open applications rather than the number of real events.
Delivery is at least once, so handlers have to be safe to run twice. Dedupe on the event identifier and treat each payload as a signal to fetch current state. Six webhooks we send, three you should actually handle goes through which events earn a handler on day one.
What sits behind the endpoints
The API is a thin front on an operation, and the operation is what you are actually buying. Three parts of it decide whether the integration holds up.
Rules have to be kept current. Governments change fees, eligible nationalities, document specifications and processing times with little notice and no change feed. Somebody has to watch official sources per destination and write the updates into the dataset your requirements calls read. Timatic and modern visa APIs: what each is for covers how this data differs from the airline-side feed you may already licence.
Applications have to be validated before they reach a portal, because government systems reject on formatting and return little reasoning. And somebody has to file them: plenty of schemes still offer no machine interface, so submission means an operator or an automation working the portal, answering requests for further information, and chasing decisions that stall.
This is why two APIs with near-identical documentation behave so differently in production. You are buying an operation, not an endpoint. The endpoint is the part any competent team can build in a fortnight.
Where each surface goes in a booking flow
- Requirements at search or checkout. A line on the results page or the payment step, showing what the route requires before the traveler commits. Earlier placement informs more people; later placement converts more of them.
- The application attached to the booking. The visa becomes an item on the itinerary you already own, with its own state alongside the flight or the room. Most partners pass a booking reference through so the two records stay joined.
- Status into your own notifications. Webhook events feed the emails, push messages and support console your customers already use, so “where is my visa” is answered on your surface instead of arriving as a ticket.
What to evaluate in any eVisa API
- Sandbox access. Keys at signup, or a sales call before you can send a single request? The difference tells you how the vendor thinks about engineering time, and it decides whether you can evaluate the thing in an afternoon.
- Data freshness receipts. A timestamp per rule and a named source beat any general claim that the dataset is current. Ask when a specific fee was last verified; the quality of that answer predicts the quality of the data.
- Fee transparency. The response should break consular fee and service fee apart, and the consular figure should match the government’s published number. A single blended price hides a markup on a fee that is public.
- Webhook coverage. Approvals are easy. Check that information requests, refusals and document-ready events are also pushed, along with retry behaviour, signing, and how far back you can replay.
- Who carries refunds and chargebacks. If the vendor is merchant of record, disputes land on their licence. If you are, they land on yours, and you want the refund rules written down before your first refused application.
How ours works
For reference: SimpleVisa issues sandbox keys at signup without a sales call, and the requirements endpoint returns in 380 ms at the median. The reference documentation, including idempotency and webhook signing, is at /developers. If you would rather see the shape of the data before writing code, the requirements coverage behind that endpoint is browsable at /requirements.