Avinode Group Devportal

API connections

Accessing the APIs require an active API connection.

Permissions

Each API connection has a set of permissions that restrict which operations can be called.

Company access

Each API connection is connected to one Avinode or SchedAero member’s company account. This is used to determine which company accounts’s data the API connection can access and potentially update. If the application needs to handle data for multiple companies, it needs to handle multiple API connections.

Setup

API connections are currently created and maintained by the Avinode and SchedAero support staff.

Application specific

If different kinds of applications are implemented, each application should be able to use separate API connections.

Automatic expiration

API connections that are not used for 60 days are automatically deactivated.

HTTP request headers

Several HTTP headers are required in every request to authenticate and provide other details about the call.

X-Avinode-ApiToken

This required field is a unique token identifying the calling application.

The value for the API token should not be editable by the users of the application. It is preferably hard coded into the application.

IMPORTANT: The API token is used to identify the calling application. To prevent malicious callers from impersonating other software, the API token must not be shared with any external parties that are not directly involved in the project.  Posting code examples, curl commands or similar to online forums or discussion groups where the API token is included is strictly forbidden.

X-Avinode-ApiToken example

X-Avinode-ApiToken: 229B8C9E-B3F2-4FA6-8BAE-71DF00943C0E

Authorization

This required field must contain the unique token that identifies the API connection that should be used for this call. When sending this, the HTTP header with the token must be prefixed by the word ‘Bearer’ in the style of OAUTH tokens.

Please note, when using the Sandbox Swagger page, the ‘Bearer’ prefix will need to be added.

IMPORTANT: Since the authorization token is used to identify and authorize the caller, it must be treated with the same care as any username and password. It must not be shared with any external parties that are not directly involved in the project.  Posting code examples, curl commands, or similar to online forums or discussion groups where the authorization token is included is strictly forbidden.

Authorization example

Authorization: Bearer mF_9.B5f-4.1JqMklj3498dfoFWrw-89qnavn.8234Klnj843jw09ksU

X-Avinode-SentTimestamp

This field is required and must contain a timestamp formatted in accordance to ISO-8601. This is the time of creation for the message. The call will be rejected if this time is off by more than 5 minutes when the message is received. So it is important that the clock used by the application is up to date at all times.

X-Avinode-SentTimestamp example

X-Avinode-SentTimestamp: 2016-01-19T08:10:06.135Z

X-Avinode-ApiVersion

This field is required and must contain the API version that the application will use.

X-Avinode-ApiVersion example

X-Avinode-ApiVersion: v1

X-Avinode-ActAsAccount

This is an optional field. Some operations support sending a personal Avinode Marketplace account username. This means that this person will be registered as the user doing the action of the operation. For example when uploading an RFQ, the system will show the provided user as the user requesting the quote.

The documentation page for each operation handling this HTTP header will have more information about this.

X-Avinode-ActAsAccount example

X-Avinode-ActAsAccount: johnsmith64

X-Avinode-Product

This should always be populated with the name and version of the calling application.

X-Avinode-Product example

X-Avinode-Product: Smart Flight Finder v2.3

HTTP status codes

The APIs use conventional HTTP response codes to indicate success or failure of each API call. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that resulted from the provided information (e.g. a required parameter was missing, an authorization failed, etc.), and codes in the 5xx range indicate an API server error.

Response codes

200
200

OK

201
201

Created. The server created one or more entities as a result of the call.

400
400

Bad Request. The request was somehow invalid (e.g. bad timestamp, etc.).

401
401

Authorization failure (e.g. no permissions, rate limit exceeded, etc.)

404
404

Not found. The application requested a resource that does not exist.

422
422

Entity invalid. Validation failure, relationship failure, or state failure.

500
500

Internal failure.

501
501

Not Implemented. The called operation is disabled, or not yet implemented.

503
503

Service too busy.

504
504

Service temporary unavailable.

HTTP response headers

Service Rate limits

The number of calls that one API connection can make per hour is limited. Every API response will include the following HTTP headers.

After the number of calls has reached the rate limit, all calls to that service will be denied with the HTTP 403 response code until the next hour starts.

X-Rate-Limit-Limit
X-Rate-Limit-Limit

The rate limit for the service that was invoked. This is the allowed number of calls per hour.

X-Rate-Limit-Remaining
X-Rate-Limit-Remaining

The remaining number of  calls allowed within the current hour.

X-Rate-Limit-Reset
X-Rate-Limit-Reset

The number of seconds until the call counter is reset (i.e. the next hour starts).

Internationalization

Dates and times are formatted in accordance to ISO-8601.

Currency

Currency codes use the three letter code defined in ISO 4217.  Price conversions are based on Forex data which is updated daily from Xignite.

Country codes

Country codes use the two letter code defined in ISO 3166-1 alpha-2.

Province codes

Province codes use the format defined in ISO 3166-2. Each code consists of two parts, separated by a hyphen. The first part is the two letter country code and the second part can be up to three letters specifying the region in that country. For example; “US-FL” for Florida.

Sparse fields

For some operations, there is information available that will only be included in the operation output if it is requested when making the API call. This extra information is requested by specifying one or more values in the operation’s field[operation] URL parameter. The documentation page for each operation has information about the available sparse fields.

IDs

Unless specifically stated in this documentation, the format of any object’s identifier is unspecified, and can change at any time. For example, n operation that currently returns an ID that looks like “abc-12345678” could change to “1234-ABCD-5678-EF90”. The calling application should not try to extract parts of the these IDs for any reason. If the format of an ID changes, the API operations using this ID as input will continue to support previous formats.

The application should not display any API generated IDs to the user unless this documentation specifically states that the particular ID can be displayed.

String handling

Data entered in string properties must conform to the following rules:

  • If a string contains multiple lines then new lines must either be sent as line feed (\n) or carriage return and line feed (\r\n).
  • If a string contains a backslash character (\) then it must be escaped with an additional backslash character (\\).
  • If a string contains a double quotation mark (") then this must be escaped with a backslash character (\").

Data returned in string properties should be displayed correctly to the users of the application according to the rules above.

Retry policies

If a call to the API fails for any reason, a retry policy should be sensibly implemented.  This would most likely include concepts like exponential back-off, maximum number of retries, etc…  For some operations, retries are not allowed. The documentation page for each operation may have information about the recommended retry policy.

Automatic testing

No automatic tests are allowed to make calls to the API.  This applies to all types of automatic testing such as load tests, integration test suites, etc…  All logic generating calls to the API must be replaced by mock-ups when running automatic tests.  This is true for both our Production environment as well as the sandbox environment.

API contracts

The contracts in place for each member or partner using the APIs regulates how the APIs can be used, and how the data returned by the APIs can be handeld.  Paragraphs regulating the following can be included:

  • Which API related use cases the application can implement
  • How, and for how long, certain data returned by the APIs can be stored
  • How, and to whom, data returned by the APIs can be shared

Abuse

Calling any API operations in any repetitive or automated fashion for the purpose of harvesting information is strictly forbidden.

Implementation check list

All items on this check list must be true in order for an application to be allowed to call the live Avinode Marketplace and SchedAero environments:

  • The application only implements API call related use cases that are approved by Avinode or SchedAero
  • The application does not store any data returned by the APIs that it is not allowed to store
  • The application does not share any data returned by the APIs that is not allowed to share
  • The application’s API token (the token sent in the X-Avinode-ApiToken HTTP header) is hard coded into the application and is not configurable by the users of the application
  • The application always sends its name and version in the X-Avinode-Product HTTP header
  • The application does not display API generated IDs to the user, unless this documentation specifically states that the particular ID can be displayed
  • The application does not, for any reason, extract any parts of an API generated ID
  • The application handles Authentication Tokens with the appropriate level of security to avoid it from falling into the wrong hands
  • The application escapes and handles string data according to the specified rules
  • The application can handle when an operation suddenly returns properties that were not previously returned at the time of implementation
  • The application has sensible retry policies for failed calls to operations that allow retries
  • Instances of the application built or deployed for development or testing purposes cannot call the live API servers or consume live webhook notifications

Date

Date are formatted YYYY-MM-DD

2015-05-19

Time

Times are formatted HH:MM.

23:57

Timestamp

Timestamps are formatted YYYY-MM-DDThh:mm:ss.sssZ and are always UTC times.

2015-12-17T19:56:03.148Z

Relationships for all contacts

externalIdentities
optional
externalIdentities
optional

Any identifiers for this contact in external systems (/api/externalsystems) linked to SchedAero. See External Identifiers

trips
optional
trips
optional

Quoted or scheduled trips (/api/trips) for which this contact is the requester.

salesperson
salesperson

Staff member (/api/staff) that is the assigned salesperson for this contact.

Relationships for contact people

company
optional
company
optional

Contact company (/api/contacts/companies) that is this contact’s employer.

Relationships for contact companies

employees
optional
employees
optional

Contact people (/api/contacts/people) that are employees of this company.

Relationships for a scheduled trip

requester
requester

Contact (/api/contacts) who is the requester for the trip.

salesperson
salesperson

Staff member (/api/staff) that is assigned as the salesperson for the trip.

itinerary
itinerary

List of active Flight Legs (/api/flightlegs) that are scheduled for this trip.

quotes
optional
quotes
optional

Quote (/api/quotes), if any, for this trip. A scheduled trip can have only a single quote.

reports
optional
reports
optional

Pilot and passenger tripsheets (/api/reports)for this trip.

Relationships for a flight leg

trip
trip

Trip (/api/trips) to which this flight leg belongs.

lift
lift

Aircraft, aircraft type or category (/api/lift) assigned to fly this flight leg.

crew
optional
crew
optional

Assigned crew members (/api/crewassignments) for this flight leg.

reports
optional
reports
optional

Pilot and passenger tripsheets (/api/reports)for this flight leg.

Relationships for quoted trips

requester
requester

Contact (/api/contacts) who is the requester for the trip.

salesperson
salesperson

Staff member (/api/staff) that is assigned as the salesperson for the trip.

quotes
quotes

One or more quotes (/api/quotes) for the requested itinerary.

requestedItinerary
requestedItinerary

One or more request legs for the trip. Request legs are typically the passenger segments of the trip, and do not contain flight times because the aircraft is not yet known.

Relationships for quotes

trip
trip

Trip (/api/trips) to which this flight leg belongs.

itinerary
itinerary

One or more quote legs for the trip on a specific aircraft, aircraft type or aircraft category. Quote legs include the trip’s request legs as well as any required position flights. Since the quote is for a specific aircraft, quote legs have flight times.

Generation links

If a resource in SchedAero API has an associated PDF document, the resource will include a ‘generate-pdf’ link providing the uri to retrieve the PDF content.

Request a resource with a generation link

GET https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789

{
	"data": {
		"id": "schedaero-quote-123456789",
		"href": "https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789",
		"type": "schedaero-quote",
		"links": {
			"generate-pdf": {
				"href": "https://sandbox-schedaero.avinode.com/api/streams/quotes/schedaero-quote-123456789"
			}
		}
	},
	"meta": {}
}

Streamed content retrieval

The generation uri can be requested as you would any other resource through SchedAero API. The request must include all of the normal headers as well as a valid Authorization token.

Unlike normal requests, a request for streamed content will not return a json document. Instead, it will return an array of bytes that is the binary content of the file. The Content-Type and Content-Disposition headers indicate the type and name of the returned file.

Your application should save the response body to disk as a .pdf file or otherwise display the PDF content to your users.

PDF request

GET https://sandbox-schedaero.avinode.com/api/streams/quotes/schedaero-quote-123456789
X-Avinode-ApiVersion: v1
X-Avinode-ApiToken: anidentifier
Authorization: Bearer atoken
X-Avinode-SentTimestamp: 2010-01-01T00:00Z

PDF response

HTTP/1.1 200 OK
X-Avinode-ApiVersion: v1
Content-Type: application/pdf
Content-Disposition: attachment; filename="Quote N100AB (Gulfstream V)  $28,650.00"

31336166320D0A255044462D312E...

Quote PDFs

Every quote resource contains a ‘generate-pdf’ link to retrieve the current quote pdf. The pdf will be created with the formatting and settings chosen for the quote in the SchedAero application.

Request

GET https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789

Response

{
	"data": {
		"id": "schedaero-quote-123456789",
		"href": "https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789",
		"type": "schedaero-quote",
		"links": {
			"generate-pdf": {
				"href": "https://sandbox-schedaero.avinode.com/api/streams/quotes/schedaero-quote-123456789"
			}
		}
	},
	"meta": {}
}

Tripsheet PDFs for Scheduled Trips

Every scheduled trip resource contains a collection of tripsheet reports, representing all PDF-formatted tripsheets that are available through the SchedAero application. Each report contains a ‘generate-pdf’ link to retrieve the corresponding document.

Tripsheets generated from a trip’s reports collection will contain all legs in the trip.

Request

GET https://sandbox-schedaero.avinode.local/api/trips/schedaero-trip-123456789/reports

Response

{
	"data": [{
			"report": {
				"name": "Passenger by leg trip sheet",
				"reportType": "PassengerTripSheet",
				"id": "report-10002",
				"href": "https://sandbox-schedaero.avinode.com/api/reports/report-10002",
				"type": "report"
			},
			"trip": {
				"id": "schedaero-trip-123456789",
				"href": "https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789",
				"type": "schedaero-trip"
			},
			"id": "schedaero-trip-123456789-report-10002",
			"type": "report-trip",
			"links": {
				"generate-pdf": {
					"href": "https://sandbox-schedaero.avinode.com/api/streams/tripsheets/schedaero-trip-123456789-report-10002"
				}
			}
		}, {
			"report": {
				"name": "Pilot by leg trip sheet",
				"reportType": "PilotTripSheet",
				"id": "report-10011",
				"href": "https://sandbox-schedaero.avinode.com/api/reports/report-10011",
				"type": "report"
			},
			"trip": {
				"id": "schedaero-trip-123456789",
				"href": "https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789",
				"type": "schedaero-trip"
			},
			"id": "schedaero-trip-123456789-report-10011",
			"type": "report-trip",
			"links": {
				"generate-pdf": {
					"href": "https://sandbox-schedaero.avinode.com/api/streams/tripsheets/schedaero-trip-123456789-report-10011"
				}
			}
		}
	],
	"meta": {}
}

Tripsheet PDFs for Flight Legs

Every flight leg resource contains a collection of tripsheet reports, representing all PDF-formatted tripsheets that are available through the SchedAero application. Each report contains a ‘generate-pdf’ link to retrieve the corresponding document.

Tripsheets generated from a flight leg’s reports collection will contain only that leg’s information.

Request

GET https://sandbox-schedaero.avinode.com/api/flightlegs/schedaero-flightleg-123456789/reports

Response

{
	"data": [{
			"report": {
				"name": "Passenger by leg trip sheet",
				"reportType": "PassengerTripSheet",
				"id": "report-10002",
				"href": "https://sandbox-schedaero.avinode.com/api/reports/report-10002",
				"type": "report"
			},
			"leg": {
				"id": "schedaero-flightleg-123456789",
				"href": "https://sandbox-schedaero.avinode.com/api/flightlegs/schedaero-flightleg-123456789",
				"type": "schedaero-flightleg"
			},
			"id": "schedaero-flightleg-123456789-report-10002",
			"type": "report-flightleg",
			"links": {
				"generate-pdf": {
					"href": "https://sandbox-schedaero.avinode.com/api/streams/tripsheets/schedaero-flightleg-123456789-report-10002"
				}
			}
		}, {
			"report": {
				"name": "Pilot by leg trip sheet",
				"reportType": "PilotTripSheet",
				"id": "report-10011",
				"href": "https://sandbox-schedaero.avinode.com/api/reports/report-10011",
				"type": "report"
			},
			"leg": {
				"id": "schedaero-flightleg-123456789",
				"href": "https://sandbox-schedaero.avinode.com/api/flightlegs/schedaero-flightleg-123456789",
				"type": "schedaero-flightleg"
			},
			"id": "schedaero-flightleg-123456789-report-10011",
			"type": "report-flightleg",
			"links": {
				"generate-pdf": {
					"href": "https://sandbox-schedaero.avinode.com/api/streams/tripsheets/schedaero-flightleg-123456789-report-10011"
				}
			}
		}
	],
	"meta": {}
}

Create external system

To use external identifiers, you must first tell SchedAero about the system that you will link to SchedAero. You should record the SchedAero-assigned identifier for the system as you will need them to populate identifiers in the future.

You may create as many external systems as you require, but they must each have a unique name.

Request

POST https://sandbox-schedaero.avinode.com/api/externalsystems

{
	"name": "MyCRM"
}

Response

The Location header provides uri for the new system. The system’s SchedAero identifier is the final part of the uri, “external-system-1234546789” in this example.

HTTP/1.1 201 Created
X-Avinode-ApiVersion: v1
Content-Type: application/json; charset=utf-8
Location: https://sandbox-schedaero.avinode.com/api/externalsystems/external-system-123456789

{"meta":{} }

Contact external identity

To link a contact to an external system, PATCH the contact/system with the unique identifier for the external system’s record. The unique identifier must be unique across all SchedAero contacts linked to the same system.

 

Identity attributes

identifier
identifier

Unique identifier for the contact in an external system

uri
optional
uri
optional

When supplied, the SchedAero UI displays this as a deep-link to the external system.

name
optional
name
optional

When supplied, the SchedAero UI displays this as the text of the the deep link

SchedAero UI

After an external identity is assigned, the SchedAero UI will display it when the contact is viewed or edited.

Update contact external identity

PATCH https://sandbox-schedaero.avinode.com/api/contacts/people/contact-123456789/externalidentity/external-system-123456789 

{
	"identifier": "ABCDEF-123456",
	"name": "CRM Customer",
	"uri": "https://app.mycrm.com/customers/edit/abcdef-123456"
}

Remove contact external identity

PATCH https://sandbox-schedaero.avinode.com/api/contacts/people/contact-123456789/externalidentity/external-system-123456789 

{
	"isActive": "false"
}

Retrieve a contact's identities

GET https://sandbox-schedaero.avinode.com/api/contacts/people/contact-123456789?fields[contact]=externalidentities

{
	"data": {
		"externalIdentities": [{
				"identifier": "ABCDEF-123456",
				"name": "CRM Customer",
				"uri": "https://app.mycrm.com/customers/edit/abcdef-123456",
				"isActive": true,
				"id": "contact-123456789/externalidentity/external-system-123456789",
				"href": "https://dotnetvm-schedaero.avinode.local/api/contacts/people/contact-123456789/externalidentity/external-system-123456789",
				"type": "schedaero-identity"
			}
		],
		"id": "contact-123456789",
		"href": "https://dotnetvm-schedaero.avinode.local/api/contacts/people/contact-123456789",
		"type": "contact-person",
	},
	"meta": {}
}

When should I use AvinodeAPI?

If your application is interested in:

  • notification of new Avinode requests
  • notification when an Avinode request is accepted/declined
  • current quote on an Avinode request

you should use Avinode API and its webhooks. Because of the automatic integration, Avinode will always be updated when the SchedAero operator makes changes to the request.

Did a SchedAero Trip originate in Avinode?

If a SchedAero trip originated as an Avinode request, SchedAero API provides several points of data to help your application work with it correctly.

  • The sparse field origin will return a value of “Avinode”
  • The sparse field avinodeid will return the Avinode rfq or client lead identifier, for use with Avinode API
  • The links collection will include “avinode-rfq” or “avinode-lead”, with the uri of the correct Avinode API endpoint to obtain details.

Request for Avinode fields

GET https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789?fields[trip]=origin,avinodeid

{
	"data": {
		"origin": "Avinode",
		"avinodeRfqId": "arfq-123456789",
		"id": "schedaero-trip-123456789",
		"href": "https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789",
		"type": "schedaero-trip",
		"links": {
			"avinode-rfq": {
				"href": "https://sandbox.avinode.com/api/rfqs/arfq-123456789"
			}
		}
	},
	"meta": {}
}

How can I deep-link to the SchedAero UI if I have an Avinode request?

You can use a uri similar to

https://sandbox-schedaero.avinode.com/mvc/trip/fromImportedAvinodeRfq/arfq-123456789

where the final part of the uri is the identifier of the Avinode request. This uri is also returned as a link on the Avinode RFQ by Avinode API.

How can I be notified of new quotes that originated in both Avinode and SchedAero?

You will need to create a webhook that is notified for both event type Trip Messages – Mine from AvinodeAPI and event type SchedAeroOwnQuoteReplies from SchedAero API.

Notification body

The payload of a webhook includes, at a minimum, the following information:

  • the type of event that occurred
  • the resource that changed
  • the uri where full details of the resource can be retrieved

Typically, upon receiving a webhook, your application will immediately call the SchedAero API to retrieve updated information about the resource. Your application must use the href provided in the webhook to retrieve additional details about the resource.

Webhooks for specific event types may include additional properties in the payload. Your application must receive any additional properties in a notification without error.

Example payload

{
	   "id": "schedaero-trip-123456789",
	   "href": "https://schedaero.avinode.com/api/trips/schedaero-trip-123456789",
	   "type": "schedaero-trip"
}

EventType: SchedAeroContacts

Notifies your application when any contact is created, or when any of the api-visible fields on the contact are modified.

Contact details can be retrieved by using

 GET /contacts/people/{contactid}

or

 GET /contacts/companies/{contactid}

operations, as indicated in the webhook payload.

Create contacts webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero contact changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroContacts"
	]
}

Sample notification payload

{
	"type": "SchedAeroContacts",
	"id": "contact-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/contacts/people/contact-123456789"
}

EventType: SchedAeroLogistics

Notifies your application when a service on a flight leg is created or changed.

Logistic Details can be retrieved by using

 GET GET /logistics/{serviceid}

 

Create logistics webhook

POST /webhooks/settings

{
"targetURI": "https://myapplication.com/notifications",
"displayName": "Schedaero logistics changes",
"active": true,
"clientIdentifier": "myapplication",
"clientSecret": "secret",
"clientAuthenticationType": "BASIC",
"eventTypes": [
"SchedAeroLogistics"
]

Sample notification payload

{
    "type": "SchedAeroLogistics",
    "id": "schedaero-logistics-123456789",
    "href": "https://sandbox-schedaero.avinode.com/api/logistics/schedaero-logistics-123456789"
}

EventType: SchedAeroCrewAssignments

Notifies your application when a crew member is assigned to a flight, or when any of the api-visible fields on an existing crew assignment are modified.

Crew assignment details can be retrieved by using the

 GET /crewassignments/{assignmentid}

operation, as indicated in the webhook payload.

Create crew assignments webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero crew changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroCrewAssignments"
	]
}

Sample notification payload

{
	"type": "SchedAeroCrewAssignments",
	"id": "schedaero-crew-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/crewassignments/schedaero-crew-123456789"
}

EventType: SchedAeroFlightLegs

Notifies your application when any flight leg is created, released or cancelled, or when any of the api-visible fields on the leg are modified.

Leg details can be retrieved by using the

GET /flightlegs/{legid}

operation, as indicated in the webhook payload.

Note that the flight legs webhook does not notify when the associated trip changes; use the scheduled trips webhook to receive notifications when a trip changes.

Create flight legs webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero flight changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroFlightLegs"
	]
}

Sample notification payload

{
	"type": "SchedAeroFlightLegs",
	"id": "schedaero-flightleg-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/flightlegs/schedaero-flightleg-123456789"
}

EventType: SchedAeroOwnQuoteReplies

Notifies your application when a quote originally created in SchedAero is sent to the trip’s requester.

Quote details can be retrieved by using the

 GET /quotes/{quoteid}

operation, as indicated in the webhook payload.

This webhook is intended to be used together with the Avinode Trip Messages – Mine webhook. Quotes sent in response to Avinode requests will notify the Avinode webhook, while quotes created in SchedAero will notify through this webhook. If your application subscribes to both, you will receive all quotes sent from SchedAero.

Create own quote replies webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero own quote sent",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroOwnQuoteReplies"
	]
}

Sample notification payload

{
	"type": "SchedAeroOwnQuoteReplies",
	"id": "schedaero-quote-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789"
}

EventType: SchedAeroQuotedTrips

Notifies your application when a quoted trip is created, or when any of the api-visible fields on the trip are modified.

Trip details can be retrieved by using the

GET /trips/{tripid}

operation, as indicated in the webhook payload.

Note that the quoted trips webhook notifies only when a trip-level field changes. Use the quotes webhook to receive notification when a quote changes.

Create quoted trips webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero quoted trip changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroQuotedTrips"
	]
}

Sample notification payload

{
	"type": "SchedAeroQuotedTrips",
	"id": "schedaero-trip-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789"
}

EventType: SchedAeroQuotes

Notifies your application when a quote is created or modified.

Quote details can be retrieved by using the

 GET /quotes/{quoteid}

operation, as indicated in the webhook payload.

Note that the quotes webhook notifies only when the quote or its itinerary changes. Use the quoted trips webhook to receive notification when a trip level field changes.

Create quotes webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero quote changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroQuotes"
	]
}

Sample notification payload

{
	"type": "SchedAeroQuotes",
	"id": "schedaero-quote-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/quotes/schedaero-quote-123456789"
}

EventType: SchedAeroScheduledTrips

Notifies your application when a scheduled trip is created or cancelled, or when any of the api-visible fields on the trip are modified.

Trip details can be retrieved by using the

GET /trips/{tripid}

operation, as indicated in the webhook payload.

Note that the scheduled trips webhook does not notify when an itinerary leg changes; use the flight legs webhook to receive notification when a leg changes.

Create scheduled trips webhook

POST /webhooks/settings

{
	"targetURI": "https://myapplication.com/notifications",
	"displayName": "Schedaero scheduled trip changes",
	"active": true,
	"clientIdentifier": "myapplication",
	"clientSecret": "secret",
	"clientAuthenticationType": "BASIC",
	"eventTypes": [
		"SchedAeroScheduledTrips"
	]
}

Sample notification payload

{
	"type": "SchedAeroScheduledTrips",
	"id": "schedaero-trip-123456789",
	"href": "https://sandbox-schedaero.avinode.com/api/trips/schedaero-trip-123456789"
}
Copyright 2018 Avinode - Policies