Introduction

A webhook subscribes to one or many notification types. Different events in Avinode Marketplace will trigger different types of notifications to be sent out. See API reference POST /webhooks/settings page for details on how to subscribe to each type of notification.

📘

Please note!

The receiving webhook server should always respond with a HTTP 200 status to indicate back to Avinode that the notification was successfully received.

Notification types in Avinode

Trip Request

If an operator subscribes to this notification type, the operator will receive a notification each time a broker (buyer) has sent a new trip request to the operator, or an existing one has been updated.

Notifications of this type are sent when:

• A new RFQ has been created for the operator.
• An existing RFQ has been updated with additional information, like another lift added.
• An existing RFQ has been canceled by the broker.

After this notification has been consumed, the application can download the RFQ information as described in the Download and Respond to RFQs use case. The application should always use the URL provided in the notification payload when downloading the RFQ.

{
  "id": "arfq-12345678",
  "href": "https://sandbox.avinode.com/api/rfqs/arfq-12345678",
  "type": "rfqs",
  "tripId": "A1B2C3"
}

Trip Chat - Buyer

If an operator subscribes to this notification type, the operator will receive a notification each time a broker (buyer) has sent a new chat message to the operator.

Notifications of this type are sent when:

• A broker (buyer) has sent a new chat message

{
	"id": "abuyermsg-1000000023",
	"href": "https://sandbox.avinode.com/api/tripmsgs/abuyermsg-1000000023",
	"type": "tripmsgs"
}

Trip Request - Seller Response

If a broker subscribes to this notification type, the broker will receive a notification each time an operator has replied to an RFQ.

Notifications of this type are sent when:

• An operator (seller) has submitted a quote.
• An operator (seller) has declined an RFQ.

After this notification has been consumed, the application can download the trip message information by calling the GET /tripmsgs/{id} operation. The application should always use the URL provided in the notification payload when downloading the information.

{
  "id": "asellermsg-12345678",
  "href": "https://sandbox.avinode.com/api/tripmsgs/asellermsg-1234567",
  "type": "tripmsgs"
}

Trip Chat - Seller

If a broker subscribes to this notification type, the broker will receive a notification each time an operator has sent a new chat message to the broker.

Notifications of this type are sent when:

• An operator (seller) has sent a new chat message associated with an RFQ.

After this notification has been consumed, the application can download the trip message information by calling the GET /tripmsgs/{id} operation. The application should always use the URL provided in the notification payload when downloading the information.

{
	"id": "asellermsg-1000000007",
	"href": "https://sandbox.avinode.com/api/tripmsgs/asellermsg-1000000007",
	"type": "tripmsgs"
}

Trip Request (My Company)

If an operator or broker subscribes to this notification type, they will receive a notification each time they themselves have sent some kind of communication to the other party.

Notifications of this type are sent when:

• Someone in your company sends a trip request
• Someone in your company cancels a trip request

After this notification has been consumed, the application can download the trip message information by calling the GET /tripmsgs/{id} operation. The application should always use the URL provided in the notification payload when downloading the information.

{
	"id": "arfq-1000000017",
	"href": "https://sandbox.avinode.com/api/rfqs/arfq-1000000017",
	"type": "rfqs",
  "tripId": "A1B2C3"
}

Trip Request - Seller Response (My Company)

If an operator (seller) subscribes to this notification type, they will receive a notification each time they themselves have sent some kind of communication to the broker.

Notifications of this type are sent when:

• Someone in your company submits a quote to a trip request
• Someone in your company declines a trip request

After this notification has been consumed, the application can download the trip message information by calling the GET /tripmsgs/{id} operation. The application should always use the URL provided in the notification payload when downloading the information.

{
	"id": "asellermsg-1000000008",
	"href": "https://sandbox.avinode.com/api/tripmsgs/asellermsg-1000000008",
	"type": "tripmsgs"
}

Trip Chat (My Company)

When subscribing to this notification type, a notification will be sent each time someone in your company chats on a trip. It could be as an operator (seller) or as a broker (buyer).

Notifications of this type are sent when:

• Someone in your company has sent a new chat message associated with an RFQ

After this notification has been consumed, the application can download the trip message information by calling the GET /tripmsgs/{id} operation. The application should always use the URL provided in the notification payload when downloading the information.

{
	"id": "asellermsg-1000000008",
	"href": "https://sandbox.avinode.com/api/tripmsgs/asellermsg-1000000008",
	"type": "tripmsgs"
}

or

{
	"id": "abuyermsg-1000000023",
	"href": "https://sandbox.avinode.com/api/tripmsgs/abuyermsg-1000000023",
	"type": "tripmsgs"
}

Empty Legs

When subscribing to this notification type, a notification will be sent each time an empty leg, matching a watch configuration (empty leg subscription), is created, updated, or deleted.

Notifications of this type are sent for empty legs matching any of the empty leg watches set up for the company.

The following events will trigger a notification:

• A new empty leg is published in the Avinode Marketplace.
• An empty leg previously published in the Avinode Marketplace is updated.
• An empty leg is unpublished from the Avinode Marketplace.

After this notification has been consumed, the GET /emptylegs/{id} operation can be called to get the empty leg details. The application should always use the URL provided in the notification payload when getting the empty leg details.
The operation will return a HTTP 404 if the empty leg has been unpublished by the operator.

{
  "id":"el-123456789",
  "href":"https://services.avinode.com/api/emptylegs/el-123456789",
  "type":"emptylegs"
}

Client Leads

When subscribing to this notification type, a notification will be sent each time there is a new client lead sent into Avinode. This could be originating from an Avinode Web App or a custom End Client Trip Search app using the POST /leads operation.

After this notification has been consumed, the GET /leads/{id} operation can be called to get the client lead details. The application should always use the URL provided in the notification payload when getting the client lead details.

{
  "id": "ecl-1000000017",
  "href": "https://sandbox.avinode.com/api/leads/ecl-1000000017",
  "type": "leads"
}

Go live!

👍

Implementation checklist

All items on this check list must be true in order for an application to be allowed to subscribe to and consume webhook notifications from the live environment.

• When a webhook notification is received, the service will return its response as quickly as possible.
• The receiving webhook server should respond with a HTTP 200 status to indicate successful receipt.
• The application should always use the URL provided in the notification payload when downloading the information.
• The service can consume and handle multiple parallel, and even potentially identical, webhook notifications.
• The application does not break if a previously unknown notification type is received.
• The application must be able to handle that additional JSON properties can be added to notification messages at any time.