Future Scheduled Flights to Your External System

This use case helps you automate the process of extracting future scheduled flights and sending them to other systems, reducing the risk of errors and ensuring all systems have the most up-to-date information. This data can be used for many different purposes, such as flight risk assessment, crew fatigue management, displaying or selling empty legs, or flight routing/planning tools.

Overview

Many Schedaero integration scenarios involve sending future scheduled flights to another system. Automating this through Schedaero API saves time and avoids errors by eliminating the double-entry of flight data. Since a flight's information can change frequently while it is being planned, a Schedaero API integration can additionally ensure that all systems are working from the most current information.

There are many situations where the future schedule might be needed, but some common ones are:

  • Tools that perform flight risk assessment or crew fatigue management
  • Applications that display or sell empty legs
  • Portals for passengers, or tools that send automated communication to passengers
  • Flight routing/planning tools

Overall, implementing this use case is a straightforward process that can have a significant impact on your business. The possibilities for leveraging this data are endless.

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.

The next step is to curate the information you need. As mentioned above, this will depend on the parts of the website you utilize. Once you have a better understanding of what you'd like to pull through the API, you can compare it to the swagger documentation to make sure it's available.

📘

Helpful tip

We recommend creating a checklist of the specific data points that you need. This will help you identify the specific points in the system that you would like to extract and, if needed, enable our API team to help match up specific permissions.

Permission Gathering

As a part of the project, you will collaborate with our API team to tailor your permissions based on your specific data requirements. The information you require will dictate the appropriate level of permissions that need to be granted to your API account. It is worth noting that certain endpoints of our API have the capability to write data to our system. Therefore, providing clear specifications on the intended actions can aid in streamlining the permissions-gathering process.

Should the need arise, additional permissions are usually granted on request. Permissions can always be updated/adjusted as your needs change during development, as well as after you "go live" in our production environment.

Once the permissions are defined, next steps would be to grant access to the sandbox environment.

🚧

Please note

If your project requires a specific data point that is not currently available in the API, please inform your account manager.

Implementation & API Examples

Retrieve Future Scheduled Trips

To retrieve all future scheduled trips, you can use the following base request:

https://sandbox-schedaero.avinode.com/api/trips/scheduled/current

This request will return the trip IDs along with reference links for those trips:

"data": [
        {
            "id": "schedaero-trip-29930531",
            "href": "https://schedaero.avinode.com/api/trips/schedaero-trip-29930531",
            "type": "schedaero-trip",
            "links": {
... snip ...
        {
            "id": "schedaero-trip-29921352",
            "href": "https://schedaero.avinode.com/api/trips/schedaero-trip-29921352",
            "type": "schedaero-trip",
... snip ...
        {
            "id": "schedaero-trip-29920144",
            "href": "https://schedaero.avinode.com/api/trips/schedaero-trip-29920144",
            "type": "schedaero-trip",
            "links": {
... snip ...
                }
            }
        },

... snip ... 

    "meta": {
        "copyright": "Copyright © 2001-2023 Avinode AB",
        "pagination": {
            "totalCount": 12,
            "pageNumber": 0,
            "batchSize": 100
        }
    }
}

To retrieve more details of each trip, you can use filters. For instance, the following example will pull the requester and itinerary of the trip:

https://sandbox-schedaero.avinode.com/api/trips/scheduled/current?fields[trip]=requester,itinerary

Webhooks

Setting up webhooks is the most efficient way to stay updated on the specific information you're interested in. A webhook configured for Scheduled Trips will send notifications to your endpoint whenever there is an update to an existing trip or a new trip is created.

Posting to the endpoint below:

https://sandbox.avinode.com/api/webhook/settings

With the following:

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

This will trigger an alert whenever an existing trip is updated or a new trip is created.

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

🚧

Please note

The webhook only provides notification of changes made but not the actual changes. Therefore, it's necessary to use the IDs sent in the webhook to retrieve the updated information.

More information can be found on the Schedaero Webhooks page.

Go Live!

Before going live with your project, it's essential to ensure that certain key points have been checked off. This will help to minimize the risk of errors or other issues that could impact the performance of your system.

👍

Implementation Checklist

Here's a checklist of important points to consider before going live with your project:

  • All necessary webhook notifications are correctly set up and utilized in order to avoid an overabundance of requests to the endpoints.
  • Token(s) are kept secure. They grant access to sensitive information, and should only be utilized by the team/project originally granted permission.