Download and Respond to RFQs
Download and respond to Avinode RFQs from within your system. There is also a possibility to initiate a compare search in Avinode based on an incoming trip request.
Overview
This use case enables the workflow to download and respond to RFQs in the application. The implementation of this use case requires the use of Avinode Webhooks.
Please note
In order to download and respond to RFQs your aircraft availability must be up to date in Avinode.
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. Also read about our webhooks.
There should always be only one version of a quote in both Avinode and the integrating system and these should be kept in sync. Whenever there is an update or change to the quote, i.e. pricing, aircraft, airport fees, or other additional line items, etc. these should be sent to Avinode to reflect in the quote update API call. All line items should be sent, there is however the possibility to hide these from the buyer (read more here), if this is preferred by the seller.
Implementation and API Examples
Download RFQ
The application should complete the following 4 steps when downloading RFQ related data for an RFQ that has not been previously downloaded.
1. Get basic RFQ details
The GET /rfqs/{id} operation is called to get the basic RFQ details. The RFQ always contains:
- sellerCompany – Information about the company that this RFQ was sent to.
- buyerCompany – Information about the company that created this RFQ.
- buyerAccount – Information about the person that created this RFQ
- segments – Information about the requested itinerary.
- tripId – This is the Id of the requested trip. It is the same TripID that can be seen in the Marketplace Trips Selling/Buying pages.
The RFQ may also contain:
- links.tripmsgs – One or more text messages related to this RFQ.
- sellerLift – Information about what specific lift the buyer has requested. The API supports receiving requests on a specific tail, or on an aircraft type or category (the latter options suitable for floating fleets).
- canceled – If the trip has been canceled by the buyer, this property will be set to true. The request cannot be responded to in this state.
If the RFQ contains requested lift, then each requested lift may contain:
- sellerLift.links.quotes – Quotes for this lift.
- sellerLift.links.emptylegs – Empty legs related to this lift. This exists if the buyer has requested an empty leg.
The GET /rfqs/{id} page has more information about the data returned by this operation.
2. Get RFQ text/chat messages
By subscribing to the event type "TripChatFromBuyer" the operator will be notified each time a buyer has added a new message to an RFQ. The GET /tripmsgs/{id} operation inside the notification message is called to get the details of each text message (links.tripmsgs).
For each text message the following information always exist:
- sellerCompany – Information about the company that this message was sent to. For this use case this will always be the same as the sellerCompany in the RFQ.
- buyerCompany – Information about the company that created this message. For this use case this will always be the same as the buyerCompany in the RFQ.
- buyerAccount – Information about the person that created this message. This can be a different person than the person that created the RFQ.
- message – The text message.
The GET /tripmsgs/{id} page has more information about the data returned by this operation.
List all buyer messages in an RFQ
List all current buyer messages directly in the RFQ response by adding the sparse field (query param) buyermessages to the GET /rfqs/{id} call.
3. Get quotes for requested lifts
The GET /quotes/{id} operation is then called to get the details of each quote (sellerLift.links.quotes). The GET /quotes/{id} page has more information about the data returned by this operation.
4. Get information about requested empty legs
The GET /emptylegs/{id} operation is then called to get the details of any requested empty legs (sellerLift.links.emptylegs). The GET /emptylegs/{id} page has more information about the data returned by this operation.
Get information about an updated RFQ
If the application calls the GET /rfqs/{id} operation for an RFQ that has previously been downloaded, then it should look for the following updates:
- sellerLift– Additional lift requested by the buyer.
- sellerLift.links.quotes – If additional lift has been requested, then these may have quotes.
- sellerLift.links.emptylegs – If additional lift has been requested, then these may be requests for empty legs.
- tripmsgs– Additional text messages related to this RFQ.
- canceled– If the trip has been canceled by the buyer, this property will be set to true. The request cannot be responded to in this state.
Respond to RFQ
This section will explain how to implement the possibility of responding to an RFQ. The application should use the different actions that was returned when the RFQ was downloaded with the GET /rfqs/{id} operation.
Quote a specifically requested lift
The application should call the sellerLift.actions.submitQuote action, using the lift Id.
Within the quote, any changed or additional line items should be specified. Below is an example of a typical payload using the POST /tripmsgs/{requestId}/submitQuote where line items are defined and the buyer visibility ("visibleToBuyer" : boolean) is toggled on and off.
...snip...
"lineItems": [{
"visibleToBuyer": false,
"displayName": "One quote line item",
"description": "A description of the line item",
"type": "FLT",
"price": 5100,
"formattedUnitPrice": "5100",
"formattedQuantity": "1"
},
{
"visibleToBuyer": true,
"displayName": "Another quote line item",
"description": "A description of the line item",
"type": "",
"price": 10000,
"formattedUnitPrice": "2500",
"formattedQuantity": "4"
}
]
...snip...
Decline a specifically requested lift
The application should call the sellerLift.actions.decline action, using the lift Id.
Quote or decline a specific tail using the seller lift Id
Add an additional quote
The application should call the actions.submitQuote action, using the RFQ Id. The additional tail should be specified in the request body under quote.lift.aircraftTail.
Decline the entire RFQ
The application should call the actions.decline action, using the RFQ Id.
Quote an additional tail or decline the entire RFQ at once using the RFQ Id
Floating Fleet quoting options
With the addition of Floating Fleet support, the Avinode API is now able to allow quoting on a category or type of aircraft instead of, as previously, only on a tail. This will give you greater flexibility and control over how to structure, and use, the data available through the Avinode API. See input example below.
Action input
- All submit quote actions should use the input described on the POST /tripmsgs/{requestId}/submitQuote page.
- All decline actions should use the input described on the POST /tripmsgs/{requestId}/decline page.
Remember
The requestId used as path param is either a:
- lift Id - using this will decline a specific requested lift in the RFQ. If the RFQ contains other requested lifts, not yet declined or quoted, then these will still be considered unanswered.
- RFQ Id - using this will decline the entire RFQ, including any requested lift.
Answer all RFQs
For each RFQ the operator should ideally complete at least one of these:
- Answer all requested lifts by either calling the sellerLift.actions.submitQuote action or the sellerLift.actions.decline action, using the lift Id.
- Decline entire RFQ by calling the actions.decline action, using the RFQ Id.
As long as the operator hasn’t completed this, the broker will see the RFQ as unanswered or partially unanswered, and the broker would still expect more information from the operator.
Please note
Leaving an RFQ unanswered or partly unanswered will affect the operator response statistics in Avinode negatively.
Trip messaging
This application can be used by operators or marketing agents. It is implemented to integrate the Avinode trip requests into existing software tools used by operators to keep track of their aviation charter requests.
Buyers use the Avinode Marketplace to find suitable aircraft for their customers’ trips. Buyers normally send quote requests to multiple operators for each trip. The operators can use the online Avinode Marketplace to respond to these RFQs.
Using an application like this, the RFQ's can be downloaded into the application which can be used as an external quoting tool. The operator can then create a quote in the application and send it to the buyer by uploading it back to the Avinode Marketplace. Alternatively, the RFQ can be declined if the operator has no availability for this trip or can’t perform it for some other reason.
Data model
This data model shows the top level operator trip messaging related objects and their relationships. It should be used when storing this type of data. This model enables the buyer and operator to use messages to communicate with each other to share information and ask and answer any questions that may arise around this trip. It also enables the operator to, not only respond to the actual requested lift, but to also add additional quotes for alternate aircraft or routes.
RFQ
An RFQ is what a buyer sends to the operator when they want to ask for quotes for a specific trip. It contains information about who the buyer is and the itinerary of the trip. One RFQ can:
- have zero to many lifts
- have zero to many messages
- have zero to many quotes
- get additional message, lift and quote objects over time
Lift
Each lift represents something the buyer has specifically asked to get a quote for. It can be an actual aircraft (i.e. a tail number) , a type (e.g. Falcon 7X) or a category (e.g. Heavy Jet). One lift can:
- have zero to many quotes
- only belong to one RFQ
- be associated to zero or one empty leg. Either it has an empty leg object or it doesn’t. This cannot change over time
Empty Leg
A lift can be associated to an empty leg that the operator previously have published in the Avinode Marketplace. This indicates that the buyer would like to utilize this empty leg for this trip. One empty leg can:
- be associated to zero to many lift. These lift objects can be lift objects belonging to separate RFQs
Message
A message is a text message from either the buyer or the operator. It contains information about when the message was added and by which person at what company. A message can:
- only belong to one RFQ
Quote
Quotes are offers that the operator has communicated to the buyer. A quote contains information about what kind of lift the quote is for, the itinerary (may differ from the requested itinerary in the RFQ) and the price offered to the buyer. A quote may be “Avinode Generated”. This means that Avinode has used the aircraft performance and pricing information, provided by the operator, to generate a quote on behalf of the operator. A quote can:
- belong to one RFQ or belong to one lift
Canceled trip
A buyer has the possibility to cancel a trip. The operator will then be notified that the RFQ has been updated/canceled. A canceled request cannot be responded to, so this should be highlighted to the user, saving them from quoting trips that are no longer valid.
Please note
In order for an application to be allowed to download RFQs, it must also upload responses back to the Avinode Marketplace.
Go Live!
Let's see if you are ready to go to production.
Implementation checklist
All items on this checklist must be true in order for an application implementing this use case to be allowed to call the live Avinode Marketplace environment.
- All necessary webhook notifications are correctly set up and utilized, as required for the use case (trip request and trip chat messages).
- RFQs are downloaded and presented to the user, as per webhook notification.
- The application can handle responses from the GET /rfqs/{id} operation containing multiple sellerLift objects (i.e. the buyer has requested quotes for more than one of the operator's aircraft for this trip).
- The application enables the user to respond to RFQs. This in the form of accepted, or declined quote(s) for some, or all of the lifts requested by the broker. The status of these should also be visible to the user of the application.
- The application sends updated price line items within the quote, keeping it in sync within both the application and Avinode.
- The application has support for sending and receiving trip messages using appropriate chat endpoints.
- The application keeps data in sync, by utilizing webhook notifications. The application submits updated versions of the quote as needed, including all the quote price line items.
Optional feature: Compare in Avinode
Use the data in your incoming trip requests (RFQs) to initiate a compare search in Avinode. This is a way to benchmark yourself against the market when evaluating an RFQ.
Initiate a search from the RFQ response
After you download your RFQs from Avinode, see Download RFQ, it is easy to initiate an automatic search by using the "searchInAvinode" action link. It will be present in the RFQ response data as shown below.
The 'searchInAvinode' action
A browser window will open with the itinerary data from the RFQ already filled out, and the search will run automatically.
Search In Avinode deep-link pop-up in Avinode
Updated 22 days ago
Check out the API reference for all the endpoint details: