End Client Empty Leg Search

The empty leg search operation can be used to find empty legs that interest your end clients.

Empty Leg Search

The empty leg search operation can be used to find empty legs that could be of interest given the input parameters specified. The input can be a start airport and/or an end airport, along with a time span. The empty leg search algorithm tries to match empty legs available in that time span that can be of interest given the input parameters.

For example, if the entered input is from Paris to Rome, a search might return an empty leg from London to Rome since Paris is almost on that route.

The operator can in this case fly empty from London to Paris, pick up the passengers and fly them from Paris to Rome. The operator can then make some money on this otherwise non-profitable flight from London to Rome.

Similar matches are made if only the start airport or only the end airport is specified in the input. For example if the start airport is in San Francisco and no end airport is specified, then an empty leg from Los Angeles to New York can be returned since it is a relatively short distance between Los Angeles and San Francisco compared with the total distance of the empty leg.

📘

Feasibility

For an empty leg to match it has to be deemed feasible in terms of the ratio between the distance of the empty leg segment (NM) and the requested distance (NM). If they differ too much the empty leg will not match.

Go Live!

👍

Implementation checklist

All items on this checklist must be implemented for an application of this type to be allowed to call the live production environment of Avinode Marketplace:

  1. The application must comply with the Basic Go Live requirements.
  2. If the Avinode Airport lookup API is used; when an end client is entering itinerary details, the application should call on the GET /airports/search endpoint for airport lookup.
    Note:The application is not allowed to call the service in any repetitive or automated fashion to collect airport information
  3. The application calls on the POST /api/emptylegs/search endpoint with valid parameters to run an availability search.
  4. The application successfully retrieves the search results response.
  5. The application does not display any information (seller name, aircraft tail number, etc) or images from the search results that could easily identify the seller/operator.
  6. The application does not store data retrieved from searches in its own back-end, nor does it build a “database” based on returned search results.
  7. The application does not allow the end client to send out a request RFQ directly to an operator based on a search result. The empty leg preferred by the end client should be used to generate a lead in Avinode Marketplace.
  8. The application calls on the appropriate POST /leads endpoint with valid parameters, which will generate a Client Lead in Avinode Marketplace.
  9. The application does not store any data related to options that aren’t requested by the end client.