What is the BoardingPass API?
It is an RESTful API that airlines can use to create and distribute boarding passes for their passengers. One call to the API creates and distributes a mobile friendly boarding pass over email, SMS, web (PC and mobile) and smartphone push notification and mobile wallets such as Apple Passbook.
Does the BoardingPass API support IATA and TSA requirements
Yes. The solution meets all industry standards set by IATA, the industry’s standards body, and country specific encryption requirements, including those set by the Transportation Security Administration (TSA) for USA flights. SITA can:
- sign the barcode on behalf of the airline but all TSA interaction is managed by the airline, or
- enable the airline to retain full control of the process of barcode signing and interaction with the TSA.
Does the Boarding Pass API need to integrate with airline DCS or RES systems?
No. The Boarding Pass API is called after the passenger has checked in on the airline DCS system. The airline’s current online check-in system just needs to make a single call to the API and pass the passenger name and flight details. The Boarding Pass API handles everything else, and provides confirmation of delivery back to the airline.
What mobile devices are supported by the API?
Boarding passes can be distributed to most modern mobile devices with a data connection and a browser. Some features, such as push notifications, only work with Smartphones such as iPhone or Android devices. Many airlines include boarding passes as part of a dedicated Smartphone app though a app is not necessary for the service to work. Apple Passbook, Google Now and Evernote are supported and SITA plans to support other similar services soon.
How secure is the API?
Each airline that registers to use the API is assigned a secure partition in which to develop its boarding pass apps. This partition cannot be accessed by another airline or information cannot be overlapped with any other airline partition. The partition is also protected with different user access levels to restrict access to various features within the partition. An API key is also issued to the airline to authenticate API calls from that airline’s check-in or departure control application. In addition, we can restrict access to only certain IP addresses for a particular airline.
What is an API key? What does it do?
In order to use the API, a developer must first register. As part of the registration approval, a unique API key is assigned. API key(s) are used by the airlines when calling (invoking) the API. They API key is used to authenticate the API call. It is also used for tracking the applications API usage for billing, API health monitoring and reporting purposes. Many times developers have multiple API keys to the same API in order to differentiate between apps (e.g., one key for iPhone app, a different key for Android or web app, etc.)
How do I access the API?
In addition to the developer.aero portal, access is also granted to a separate self-service administrator giving airlines full control over the branding, configuration and information management of online and mobile boarding passes. To demonstrate how this console functions, a Quick Start guide is provided to enable to create your first boarding pass in a few minutes.
Can I evaluate the API?
All airlines can have a free evaluation of the API. All you need to do is register on this page and you can start your free evaluation. It may take a few days for SITA to setup your own test partition.
Does the API support mobile wallets?
The API currently supports Apple Passbook and Google Now. Other mobile OEM wallets and NFC (Near Field Communications) will be supported in the future.
Can flight updates or gate changes be updated on the boarding pass?
Yes. The API uses push notifications to updates any changes to the boarding pass.
Can I customize the look and feel of the boarding pass?
Yes, it is fully customisable. The API provides a fully customisable template for mobile web pages, SMS, Passbook via the console enabling you to upload images and logos, set background colours, set fonts, and emphasise text elements, etc.
Can I target specific categories of boarding passes with information only relevant to them?
The API enables you to set up specific distribution channels which can target information for specific types of boarding passes and specific types of passengers for example, high loyalty status, first class cabin, etc.)
Does the API provide any reports or statistics?
Yes. The API provides a comprehensive set of reports, analytics and API health monitoring views.
What is SITA’s uptime objectives for API servers?
SITA is committed to 99.95% uptime on our servers. Our robust and redundant architecture allowed us to exceed our uptime objectives in 2016."
Service availability is checked every minute by Monitis Inc. from two locations, one in the US and one in Europe. We are currently exceeding our uptime objectives as shown on the availability report for 2016 which is published on http://dashboard.monitis.com/publicReports/report_6312.html.
How often and when will maintenance windows be required?
The system is currently designed to have zero downtime during redeployment i.e. a new revision of software is loaded without downtime.
How frequent are system backups and for how long is data stored?
Full database backups are performed daily for all partitions on the system and stored for a period of 30 days.
What is SITA’s objective for recovery in case of system failure?
The database servers are configured in High Availability mode. A primary DB instance supports the application and synchronously replicates the data to a secondary instance which is located in a different Availability Zone (separate server, network, power, storage and building). In case of failure of the primary or planned maintenance, the application automatically switches over to the secondary.
Disaster Recovery – how quickly does the system take to recover from a critical fault to enable the users to continue?
The application is load balanced across application servers in two availability zones in the US East Region. Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. Failover between Availability Zones is automatic. A system backup is available in the Singapore Region. Failover to this is manual.
How long are boarding pass logs archived for?
Boarding Pass data is retained for a period of 6 months, during which time the pass will be available. This period can be customized per partition/airline by SITA. Currently, configuration of this period is not available via the self-service console, but is planned for the future.
Note: This applies to Boarding Pass Data and Transaction Logs. Key events for the boarding pass, for example SMS delivery acknowledgement, are stored in transaction tables for each partition.
Server logs are currently stored for a period of 30 days to enable problem diagnosis and resolution. As a server may support several partitions, this data is not available to individual airlines.
Airline specific transaction support logs are available in the support section of the self-service console.
How secure is my data?
No sensitive or personal data is:
- Viewable by database administrators
- Transported across JDBC connections, or
- Available unencrypted in database backups.
The tradeoff for this security is that the API does not support searches for boarding passes with partial emails, phone numbers and other searchable fields using SQL LIKE or wildcard statements.
How much does the BoardingPass API cost?
Please contact us details of pricing.
Where can I get more information?
Please refer to the API Documentation section on this page for further information.
You can also contact us.