Working towards a Gold Standard of Airline NDC API Onboarding
Airlines have been onboarding agencies, aggregators, and other partners for a couple of years now. With NDC presented as the holy grail of standardization, one would expect this technical onboarding process to be pretty… standard. However, when looking at the state of the industry today, we could not be further from the truth.
Let’s look at what it means for an agency to get connected to an NDC airline today. We will focus on the technical aspect of it, but of course, commercials are a key factor in the go-live process as well.
The long path to go-live
A critical step to going into production is for implementers to pass the airline certification process. However, this is only the third piece of the equation. First, implementers need to familiarise themselves with the API through documentation, before using the sandbox environment where they build the connections. As we will see, each step on this journey can be quite tedious.
The airline’s NDC API documentation exhibits significant disparities and limitations resulting in many challenges for implementers.
Firstly, the documentation showcases a wide range of formats employed by different airlines, each varying in detail and structure. While most airlines offer implementation guides, they differ in presentation and format. They are available in either PDF format or accessible through searchable Wikis on their websites. In more comprehensive instances, airlines go the extra mile by sharing Postman or SoapUI projects that include ready-to-run scenarios, facilitating implementers in jumpstarting their implementations with tangible, functional examples.
When examining the actual content, certain deficiencies come to light. While default scenarios are consistently addressed, there is a noticeable lack of information from the majority of airlines regarding API limits and error cases, let alone providing guidelines or mechanisms for testing them. As a result, implementers are frequently left to speculate or manually test these error cases without sufficient guidance.
Overall, the first thing the implementers will see of your API is documentation. Making sure it is easily readable and well-structured is key to being able to quickly kickstart any implementation.
After understanding the API documentation, agencies usually gain access to a sandbox environment, or a test environment provided by the airline. The sandbox environment allows agencies to experiment, simulate transactions, and test their integration without affecting live systems or incurring any financial implications.
Obtaining sandbox access can sometimes be a multi-step process involving registration, approval, and acquiring necessary credentials such as API keys. The complexity arises from configuring the integration to work seamlessly with the sandbox environment, ensuring the correct handling of requests and responses, and addressing any technical challenges encountered during testing.
This brings us back to the first issue, with a lot of documentation skipping the whole “authentication/security” part of the API. Airlines should explain the required steps for authentication, including obtaining API keys or tokens, with clear examples.
The additional problem with some sandbox environments is how much they can differ from the actual production environment. Some sandboxes are lagging behind the production environment, while others are used for experimental features. Both cases result in instability and divergences between documentation and actual implementation.
Once agencies have successfully tested their integration in the sandbox environment, they need to undergo a certification process. Certification involves demonstrating compliance with the airline’s technical and business requirements. This process ensures that the agency’s integration meets the necessary standards and is ready for production usage.
Certification processes vary a lot among airlines, requiring agencies to fulfil specific criteria, such as passing specific test scenarios, properly displaying the airline offering, and proving their technical capabilities. Agencies may need to provide test logs, validate the accuracy of offer display, handle many scenarios, and sometimes even demonstrate error handling capabilities. The complexity lies in meeting the airline’s expectations, ensuring that the integration is robust, scalable, and able to handle real-world scenarios effectively, while properly reflecting the airline’s values.
While some airlines are very upfront with the validation methodology (going as far as putting the full list of scenarios on their onboarding platform), others do not yet provide such a structure. Therefore, implementers end up seeing more and more test cases, without a clear view of the end of the implementation. This results in, undoubtedly, the most frustrating part of the process for the agencies, sometimes with many months of back-and-forth on the testing scenarios.
Is there a solution?
This article was a bit bleak, so let me reign it back a little. While it is unavoidable to have differences between various companies, there can be light at the end of your NDC tunnel.
There is undeniably a willingness in the industry to simplify. As a key example, IATA has been trying to help airlines bring a kind of “standard methodology” for many years. One approach that IATA took was the “At Scale” certification, which required a “good enough” onboarding methodology. This certification is now discarded, but its contents are part of the IATA ARM (Airline Retailing Maturity) index. However, while it is a good base, it is not yet “strict” enough to enforce similar methods for all.
The state of the airline industry, when it comes to onboarding processes, is very reminiscent of the early days of web APIs. Each airline is trying its spin on the onboarding formula, with some more successful than others. Luckily, airlines are now learning from each other and discussing this topic at various forums. Those discussions will drive the way to a more aligned, and hopefully better, onboarding method for all.
One question remains, though. Should we let the industry slowly define those better processes through trial and error, or should IATA drive this shift by enforcing strict guidelines for a proper onboarding standard?
From interactions with many airlines and agencies in the past, we feel strongly that there is a need for clearer definitions. If these are not standardised at an industry level, we should at least work together to define the best practices to follow.