End Client Trip Search
The API solution below offers end clients the possibility to find suitable trip options and additional information for the trip they are planning.
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.
Use case parts
This use case is implemented in one or more front ends, and in most cases, also includes a back end. Front ends are, in most cases, web interfaces on the company’s web site or native mobile apps. The back end can be implemented with any technology preferred by the company, for example, Java, .NET, PHP, Python, Ruby, Go, etc. Using a back end is recommended and required if the front end is a web interface. For a native mobile app it would be possible for a front end to just communicate directly with the Avinode API servers.
The information presented to the end client can be based on all aircraft available in the Avinode Marketplace 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.
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.
The application can use a different source for airport information. However, this may increases the risk of errors if that source has some airport code information that does not match the airport code information available through the API services.
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
Calling the service in any repetitive or automated fashion to collect airport information is not allowed.
Find trip options
This use case should be implemented when the end client wants to find and view available options for a trip. The end client specifies trip details like airports, dates and times. 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 about the trip itinerary and potentially also other criteria like what type of aircraft is of interest etc.
This operation is used to find lifts available to perform the given itinerary. It calculates and returns preliminary quotes for each of the aircraft. 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.
To optimize performance of you 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.
Send booking request
This use case should be implemented 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 application for the company owning the API connection that was used. Here the Avinode member can do the final sourcing of aircraft.
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 booking 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, 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.
Book a specific aircraft
In order to create a booking request for a specific aircraft, the end client must have selected one or more aircraft from the trip options available in the result created in the End Client Trip Search segment.
Booking by type or category
If the end client has been presented with options on a aircraft type och aircraft category level, a booking request can be created for one or more aircraft types or aircraft categories. For example, the end client can create a booking request for a light jet.
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 back-end storage.
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:
- 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
- The application calls on the POST /searches endpoint with valid parameters to run an availability search.
- The application successfully retrieves the search results response.
- 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.
- 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.
- 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.
- The application calls on the appropriate POST /leads endpoint with valid parameters, which will generate a Client Lead in Avinode Marketplace.
- The application does not store any data related to options that aren’t requested by the end client.
Updated about 2 months ago
Read more and check out the API reference for all the endpoint details: