Understand the scope of the standard and the implementation
IATA describes NDC in the context of distribution using Offers and Orders. A standard provides a common framework; your project still depends on the airline, aggregator or technology provider implementation and the access available to your business.
Avoid treating GDS and NDC as labels on an interchangeable connector. Write down the journey you need to support and ask the provider to demonstrate the relevant operations. Appnox does not claim a vendor partnership or universal connector through this guide.
Confirm commercial and technical access
Who owns the supplier relationship? Which credentials, contracts and testing environments are available? Who can approve a production connection? Establish these dependencies before scheduling engineering around assumed access.
Check the scope of each credential and whether testing covers the products, markets and actions you intend to use. Document any manual steps or separate provider processes. Access to documentation is not the same as permission to run production transactions.
Test the journey after shopping
Build a capability matrix around your actual requirements: search, price confirmation, booking, payment-related status, retrieval and the servicing actions in scope. Mark each as demonstrated, not supported or awaiting confirmation.
Include realistic changes and exceptions. Ask what the system should show when a supplier rejects an action or a result is uncertain. Do not infer that a booking can be changed just because the original offer could be displayed.
Decide which system owns each fact
Identify the authoritative source for traveller data, booking references, order status, supplier confirmation and payment status. Establish how identifiers relate across systems and which updates can be initiated from each side.
A timeout requires careful handling. A repeated request might create an unintended second action if the first actually succeeded. Design duplicate prevention and reconciliation using the provider’s supported mechanisms rather than blindly retrying every failure.
Make failures visible to operations
Give staff a clear distinction between pending, confirmed and failed states. An exception should include enough context for investigation without exposing unnecessary personal or payment information.
Agree who monitors the integration, what triggers escalation and how an unresolved record is reconciled. Test these procedures with operations staff before launch. A technically successful API call is only one part of a usable workflow.
Questions for the proposal review
A scoped proposal should make the unsupported cases as clear as the supported ones. That clarity protects both the implementation plan and your servicing team.
- Which exact actions and providers have been demonstrated in a permitted environment?
- What depends on commercial approval or third-party configuration?
- How are duplicate requests, stale information and partial failures handled?
- Who owns testing, vendor coordination, monitoring and post-launch support?
Sources & further reading
External sources support the specific industry context referenced in this guide. The workflow recommendations are Appnox’s proposed approach, not claims of industry-wide results.