Introduction
The purpose of this document is to ensure that you as a developer have access to all the necessary information for designing and building solutions on top of FBO One’s API. Please ensure that the FBO for which you are designing and implementing a solution has access to the API as part of their subscription, if you are unsure please contact us via your FBO key contact. First check carefully our examples and if your use case is not covered, please contact us to review your needs. We are more than happy to help you succeed with your solution.
As part of the API we provide access to a Test environment to carry out development and testing. Before going live we can review your API solution in order to allow access for the Live environment.
Before you start implementing your solution, you should read and understand the information below.
Basics
The FBO One API is an event based http REST API where FBO One will notify a subscriber application about changes in FBO One. The notifications can be sent for different data types such as handling orders, crew / pax manifest, flights and invoices. The subscriber application must expose a web URL (an endpoint) where FBO One API can post a ‘webhook update message’. The webhook update message contains the resource identifier for which the ‘subscriber application' is expected to call back the FBO One’s API to get and read the the full data.
Please note that the current API has no support for querying based on a filter range, therefore we support only an event driven API via the webhook notification system.
What is required by your solution
- Expose an endpoint accepting http POST calls. This is where FBO One’s API will send the webhook notification messages.
- Your system needs to call the FBO One API to get the data based on the Id (unique identifier) provided in the webhook notification message from FBO One
- Any call to the FBO One API must contain the Authentication Header Bearer token (FBO One will generate one for your system)
- Our webhook notification has a timeout of 30s. Therefore your endpoint must return a success response within 30s for accepting the webhook message. Keeping the connection open for more than 30s will result in a timeout. We recommed that you queue the message and process it async.
- When calling your endpoint, we can add custom headers to the POST request - we have support for an authorization Bearer token, or a custom header like an ‘app_id’, 'client_secret'
Authorization
- Any call to FBO One’s API is expected to contain a JWT bearer token authorization header.
- The JWT token is to be provided by the FBO One user after authorizing your subscriber application in FBO One.
- Your subscriber application is registered into FBO One under the subscribers page as a webhook record. This webhook record is also linked to an API user which holds the token
- The API user is given permission to specific API commands like Public Api Invoice, Public Api Flight Info, and to specific FBO Location and Administration. This allows your application to only access a specific API and only specific data.
Swagger definitions
See below attached the following JSON files:
- Webhook message definition - FBO One notifying the subscriber application
- FBO One API swagger definition
Comments
0 comments
Please sign in to leave a comment.