End Client Trip Search

Overview

The API solution offers the end clients the possibility to find information about available lift for trips they are planning. The information can include aircraft details, flight times, estimated prices, etc. The end client can then request the lift options that are of interest. This information will be available as a lead in the Avinode Marketplace. The lead will have information about the trip the end client is planning, the options the end client has requested, and the end client’s contact information. The company owning the app can then access the lead directly in the Avinode Marketplace and use all the Marketplace features to find a suitable solution for the end client.

Pre-requisites

Gaining an understanding of our APIs and fundamentals is essential to the success of your project. To do so, start by reading our introductions page, including the pages linked in the "Before you start" section.

Implementation and API Examples

Use case parts

This use case is implemented in one or more frontends, and in most cases, also includes a backend. Frontends are, in most cases, web interfaces on the company’s website or native mobile apps. The backend can be implemented with any technology preferred by the company, for example, Java, .NET, PHP, Python, Ruby, Go, etc. Using a backend is recommended and required if the frontend is a web interface. For a native mobile app it would be possible for a frontend to just communicate directly with the Avinode API servers.

Searchable aircraft

The information presented to the end client can be based on all aircraft available in the Avinode Marketplace matching the search criteria, or a subset of these. Brokers implementing this application usually base the information on all aircraft, while operators usually base the information on their own fleet.

Workflow

Find airports

The Airports API can be used to create features enabling the end client to find airports by entering airport or city names. The Airports API also returns the airport codes that are required when calling other API operations.

📘

Airport information source

The application can use a different source for airport information. However, this may increase the risk of errors, should that source have airport code information that does not match the airport code information available through the Avinode API services.

GET /airports/search

You can search airports using a text filter to match the airport code or name etc. or using Geo-location data and a max distance (radius). It is not possible to combine filter search with location search.

The results will be sorted by airport popularity based on usage data from the Avinode Marketplace.

See more at GET /airports/search

❗️

Abuse

Calling the service in any repetitive or automated manner to collect airport information is not allowed.

Find trip options

The end client specifies trip details like airports, dates and times, pax numbers, aircraft category, etc. The application then calls the aircraft search API service and presents the result as options to the end client.

Search for available options

The application should call the POST /searches operation with details regarding itinerary, and other potential criteria such as aircraft type, aircraft category, year of make, etc.

This operation is used to find lifts available to perform the requested itinerary. It calculates and returns preliminary quotes for each of the lifts. The routes and prices are, in most cases, calculated based on the aircraft pricing information, aircraft performance details, availability information, etc., provided by the companies marketing the aircraft in the Avinode Marketplace. Alternatively, the route and pricing may have been calculated by an external module controlled by the operator.

The operation then returns the full result, or optionally, it can return results aggregated on for example an aircraft type level. More information about available input parameters, and what can be included in the output, is described on the POST /searches page.

Search results will be sorted by price in ascending order.

📘

Search performance

To optimize performance of your application, especially when requesting multiple optional data attributes in the search query – please ensure you are requesting GZIP compression to decrease response times. See API Basics for more info.

End client request

This part of the implementation deals with when the end client wants to create a booking request. The booking request will be available as an end client lead in the Avinode Marketplace for the company owning the API connection that was used. From here the Avinode member can perform the final sourcing of aircraft to suit the end client's needs. The Avinode API supports the end client request to be on a specific aircraft type or an aircraft category.

It's also possible to download the client lead data into an external quoting tool, store the customer info etc., and then initiate a pre-filled aircraft search in Avinode directly from the external system, to avoid any double entry.

Create end client request

The application should call the POST /leads operation with details about what the end client has requested, and also the end client’s contact information. This lead will show in the broker's Trips - Client Leads page in Avinode Marketplace, and from here it's easy to initiate an aircraft search from the given itinerary.

Client leads push notifications

There is also the option as a broker to subscribe to notifications for every incoming client lead that your application generates. Once notified, the lead data can be downloaded into an external quoting tool.
In the same data response there will be a deep link to use for opening up a new browser window with the Avinode search, which will be initiated immediately, see the picture below.

Read more about how to setup Avinode Webhooks notifications.

End client request for a specific aircraft

In order for an end client to create a request for a specific aircraft, they must have selected one or more aircraft from the trip options available in the result created in the End Client Trip Search segment.

End client request by type or category

If the end client has been presented with options on an aircraft type and/or aircraft category level, they can also send a request on these. For example, the end client can create a request for a light jet category, instead of on a specific aircraft as described in "End client request for a specific aircraft".

Restrictions

Data displayed to the end client

Without explicit approval from Avinode, any information that can easily identify operators may not be displayed to the end client.

Storing data returned from the API operations

The application may only store data that is required to complete the business transaction with the end-client. So, for example, if the APIs returned information for 100 aircraft and the end-client makes a request for 2 of these, then any information about the other 98 aircraft may not be stored in the application’s backend storage.

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 /searches 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 information displayed to the end client is based on all available aircraft in the Avinode Marketplace matching the search criteria, or a subset of these.
7. The application does not store data retrieved from searches in its own backend, nor does it build a “database” based on returned search results.
8. The application does not allow the end client to send out an RFQ directly to an operator based on a search result. The search results preferred by the end client should be used to generate a lead in Avinode Marketplace.
9. The application calls on the appropriate POST /leads endpoint with valid parameters, which will generate a Client Lead in Avinode Marketplace.
10. The application does not store any data related to options that aren’t requested by the end client.