Automating Flight Support Services: From Email to API Integration

From Email to API: Automating Handling Requests and Flight Support Services

Ordering services for a flight is still, across most of business aviation, an email process. Leon generates the Handling Request itself, from flight data, using the operator's own template — but the exchange it belongs to runs on people. A dispatcher sends the request, waits, reads the reply, works out what it confirmed, records it, and sends another message every time the schedule moves.

This is one of the most time-consuming parts of the dispatch role, and one of the least visible. It produces no artefact anyone reviews. It simply has to be done, correctly, for every leg.

It is also changing. This article describes what Leon automates while the channel is still email, where email reaches its limit, and how the Flight Support API replaced part of that correspondence with structured data exchange — including what that architecture was designed to protect.

1. What the work actually consists of

For a single leg, a dispatcher may need to arrange ground handling at departure and arrival, fuel, catering, crew transport, hotels, landing and overflight permits, slots, PPR, customs paperwork. Each of these has a counterparty, a request, a confirmation, and an unknown number of updates.

Three properties make the work expensive:

Every step is a human action. Sending, tracking, chasing, interpreting, updating — each request needs someone's attention from start to finish, whatever the message itself looks like.
Changes propagate manually. A schedule change is not a change to the handler until someone sends a second email. Until then, two parties hold two different plans, and only one of them knows it.
State lives in an inbox. Whether a service is confirmed is knowable only by reading correspondence. It is not a field, so it cannot be seen at a glance, reported on, or handed over at shift change.

2. What Leon automates while the channel is still email

Long before any API existed, most of the preparation of a request was already automated. This remains the baseline for every airport and provider that is not connected electronically.

Automated	How
Composing the request	The Handling Request email is generated from flight data — schedule, aircraft, crew, passengers — using the operator's own template. See Handling Requests and Handling Requests settings
Choosing the recipient	The handling agent resolves down a chain: requester's preferred handler → aircraft `SALES` setting → 'Favourite' handler in the Airport Directory → approved handler
Deciding what to request	Default 'Requested items' on departure and arrival, and HOTAC details, are configured once and populate every request
Attaching documents	GenDec, PAX Manifest and a customisable Handling Request Manifest are attached by checkbox
Tracking state	Each service is a Checklist item with a status and a full change history, so flight readiness reads as a coloured dot rather than a thread
Keeping the request honest	Leon records which flight changes occurred after the request was sent, and offers an update or cancellation email
Adjacent paperwork	Landing and overflight permit requests, country lists generated from the routing, and UK GAR submission documents follow the same pattern

The result is that a dispatcher does not compose requests. They review and send them.

3. Where email stops

A generated request is still a block of prose, addressed to a person and answered by a person, and that sets the limit.

The provider's reply is text, so someone has to read it and translate it into a status — a partial confirmation, handling yes, catering pending, fuel awaiting price, becomes one email and three manual updates. The provider cannot see the current plan, only the last plan somebody told them about, so every change needs a fresh outbound message. And because the exchange lives in a mailbox rather than in fields, none of it can be queried, reported on, or handed over cleanly at shift change.

Removing that limit requires the provider's system and the operator's system to talk to each other directly.

4. The first integration: Jetex

In 2022 Jetex approached Leon to build exactly that. The result was a direct connection allowing operators to send full-service requests, receive status updates and briefings, and exchange messages with the Jetex operations team without leaving the flight they were working on. Requests and answers landed on the flight itself, not in a mailbox.

At the time of writing it is used by roughly 45 operators, predominantly larger ones. Adoption was quick, and the most telling response was the question that followed it from users: which provider would be connected the same way next.

That question is the one worth taking seriously. One provider integrated is a partnership. The industry problem is not solved by one partnership.

5. The second generation: a provider-agnostic Flight Support API

Rather than repeat the Jetex work per provider, Leon built a second version of the interface as a general Flight Support API. Three requirements shaped it, and each one is visible in how the feature behaves today.

Requirement	Why	How it shows up
Connect new providers quickly	Bespoke integrations do not scale; every provider added by hand delays the next one	One documented interface that a provider implements on their side, without development work in Leon per provider
One workflow, regardless of provider	A dispatcher should not have to learn a different procedure for each supplier	Every connected provider is a checklist item that behaves identically: same request window, same service selection, same status semantics
Least-privilege data access	Operational data is sensitive, and a service provider needs only what the requested service requires	A provider sees only the flights it has been asked to support, and the data scope is limited to what those services need. Sharing passenger data and access to aircraft documents are separate, explicit opt-ins in 'Add-ons'

The consistency requirement deserves emphasis, because it is the part users feel. Status mapping between a provider's service states and Leon's checklist statuses uses the same best-match logic for every supplier, either predefined per service or by a generic rule. Adding a second provider therefore adds no new procedure to learn — which is what makes it realistic for an operator to work with several.

6. What it looks like in operations

The whole interaction happens inside the flight.

flight-support-integration-workflow (1).svg

The provider's item appears in the OPS checklist — added automatically where default services are configured, otherwise by the Checklist Configuration rules, or manually with + ADD ITEM.
Click EDIT, select the services required, optionally add a note per service and one for the request as a whole, and save. Requests are made per flight, separately for departure, en-route and arrival.
The provider receives the request with the airports, aircraft, crew details and passenger count already populated. Nothing is retyped.
Each requested service is linked to its corresponding checklist item, which shows that it has been requested with that provider.
When the provider moves a service to in progress or confirmed, the corresponding checklist item status changes with it, and any comment the provider leaves is written into that item.
Subsequent flight changes do not require a re-send. The provider sees the current state.

Point 6 is the one that changes a shift. The update email — the message a dispatcher sends because a time moved, and then sends again — stops existing.

Technical detail on the interface, including the status mappings, is published in the Flight Support API documentation.

7. Providers currently connected

Each provider offers its own range of services, and the services available through the integration are the ones that provider supports — check with them directly. More connections are in progress. The publicly documented list of API-connected suppliers is maintained in the Checklist article, and activation is arranged directly with the provider, who will guide the operator through their side of it.

8. What this changes, and what it does not

We are not aware of another flight operations platform with a comparable number of flight support providers connected through a single, uniform interface. That is worth stating plainly rather than loudly, because the significance is not the count. It is that the count became possible: the second version of the API made each additional provider an onboarding exercise rather than a development project, and it is that property — not any individual integration — that displaces email at scale.

What has not changed:

Providers that are not connected are still email. For them, the automation described in section 2 is the whole of it, and it works well.
Services outside a provider's scope are still email. A connected provider covers the services it offers, not everything on the checklist.
The decisions are still yours. Which handler, which fuel supplier, whether a turnaround is realistic — the integration removes transcription and waiting, not judgement.
The channel is a choice per airport. Many operators run both: API where the provider is connected, email where the relationship is local and direct.

The honest summary is that a substantial share of routine service correspondence has moved out of the inbox and into structured data, and the part that remains is the part where a person is genuinely required.

Last updated: August 12, 2026