CURRENT STATUS
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.
1. Documentation
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.
2. Sandbox
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.
3. Certification
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.
BONUS: SOME RECOMMENDATIONS
If you are part of an airline and would like to make your onboarding process as smooth as possible, here are some recommendations. To learn more from the author of this article, feel free to contact Travel in Motion where we can support you with these steps.
Note that those are not guidelines, but rather some suggestions.
1. Documentation
- Accuracy: documentation needs to be “to the point” and up to date. If at all possible, include versioning to indicate when the last update to the documentation was done.
- Implementation samples: provide snippets in the documentation and a SoapUI/Postman project.
- Easily searchable: have a proper structure, allowing for quickly getting to the needed documentation.
2. Sandbox
- Ease of access: make sure the “access procedure” is clearly described on your onboarding platform, to be able to provide developers with everything they need to do their first API call with as little delay as possible.
- Stability: any issue with the sandbox will result in longer implementation time for the partners, and reduced trust in the API itself.
- Up to date: to reduce the risk of surprises when going live, it is important that the sandbox environment is fully aligned with the production systems. In case the sandbox has any discrepancies, those need to be indicated to the implementers.
3. Certification
- Upfront validation: Indicate to your implementers all the requirements (test cases) for them to go live, as early as possible. This helps to build trust and shows that you both want to reach an accessible goal.
- Regular meetings: To make sure the implementation is advancing as desired, regular checks are mandatory.
- “Live support”: Either through a JIRA board or dedicated chat it’s important to provide as reactive and efficient technical support as possible. Any delay in the implementation caused by the wait for technical answers usually results in frustration and slower go-live.
4. Learn!
Probably the most important advice here: take each implementation as a learning opportunity. At the end of those implementations, sit down internally, and (if possible) with the implementer, and try to figure out how your onboarding process could be made better. Implementers see a lot of different airlines and onboarding methods: their input is extremely valuable.
Finally, Travel in Motion is of the opinion that an onboarding platform, often referred to as an NDC microsite, is invaluable. TiM has considerable experience defining these microsite, and works closely with a technology partner if airlines require an “out of the box” solution which has been deployed for multiple leading airlines.