Operator: Download RFQ

As an operator, I want to be notified about new RFQ's and download them into my application

This use case should be implemented when the operator wants to view RFQ's in the application. The relationships between the different types of data in this use case is described on the Operator trip messaging page.

Web-hooks and notifications

To be notified of each new, updated or canceled RFQ, the application should implement a web-hook endpoint and subscribe to one of the trip notification types. The web-hook endpoint will receive notifications continuously as soon as there is a new RFQ, or whenever there are changes made to an existing RFQ.
It's also possible to subscribe to be notified of all new text/chat messages added to an RFQ (both sent and received), allowing the application to implement a simple chat feature.
Read more about how to set up web-hooks on the Web-hooks and notifications page and about how to subscribe to trip requests and new buyer chat message notifications here.

Get information about a new 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.

👍

Implementation checklist

All items on this check list must be true in order for an application implementing this use case to be allowed to call the live Avinode Marketplace environment.

  • 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 operators aircraft for this trip).
  • The application can handle downloading an RFQ that previously has been downloaded.
  • Quotes are downloaded and presented to the user.
  • Text/chat messages from the buyer are downloaded and presented to the user.

What’s Next

Read more in the following sections and check out the API reference for all the endpoint details:

Did this page help you?