Introduction

This API enables Operators and Trip Support Providers to send handling requests and receive real-time status updates, replacing traditional email and phone communication with the FBO.

Handling requests can include arrival and departure flight details, requested services, and crew/passenger manifests. These requests are directly integrated into FBO One, eliminating manual data entry and reducing errors.

Operators and trip support are notified almost instantly about handling status updates through webhook messages and can retrieve detailed information by calling the FBO One API. This comprehensive approach removes the need for redundant phone calls or email exchanges. Updates such as flight changes, aircraft substitutions, passenger manifest adjustments, or service requests are automatically reflected in FBO One, ensuring no critical information is lost in email backlogs.

Basics

The FBO is identified using the FBO Name field (FboName). Provide the FBO name as it is recorded in your system, and FBO One will automatically map it to the corresponding FBO record in our database.

The handling airport is identified by the (HandlingStationIcao), specifying where the handling services will occur. This airport must match the arrival or departure airport in the flight legs. A handling request typically includes two flight legs: the inbound leg (arrival at the FBO) and the outbound leg (departure from the FBO).

The Operator Request Number (OperatorsHandlingNumber) is a unique value your system generates for sending new requests and updates. FBO One uses this value to identify and update an existing handling order. If the number is new, FBO One will create a new handling order. This field appears on both the arrival and departure legs. Use the same value for both legs if the request represents a turnaround handling, allowing FBO One to consolidate the arrival and departure legs into a single handling order.

Other details such as aircraft, passenger, crew and service requests are optional.

Datetime fields are to be provided in UTC in Iso8601 format. 

What is required by your solution

• Your solution should expose an endpoint to receive webhook messages from FBO One.
• Extract the handling order ID from the webhook message and use it to call the FBO One API to retrieve full handling request status details.
• The webhook message will include the FBO name provided in the Handling Request Message.
• The Handling Request Status response will include the Operator Request Number, allowing your system to map it to the handling request in your Flight Scheduling System.

Typical data flow

• Step 1: The scheduling system sends a handling request using the PUT handling request endpoint.
• Step 2: FBO One receives the request and creates a handling order with the provided details.
• Step 3: FBO One sends a webhook notification to your solution, indicating the handling's existence in FBO One. Subsequent updates made by the FBO to this handling will also trigger webhook notifications.
• Step 4: Your solution extracts the ID (FBO One's unique identifier for the handling) from the webhook message and uses it to call the API to retrieve the full handling request status details.

Authorization

• Authentication is per FBO using Bearer token authentication.
• FBO One will supply an access token for your solution to authenticate API requests.

Swagger definitions

December 2024 - Samples attached.

HTTP responses

• Status 200: the JSON payload is valid, all mandatory fields have been provided
• Status 400: bad request. The response will indicate details about invalid fields