New Distribution Capability (NDC) is a travel industry-supported programme launched by IATA for the development and market adoption of a new, XML-based data transmission standard that enhances the capability of communications between airlines and travel agents. It enables the travel industry to transform the way air products are retailed to corporations, leisure, and business travellers by addressing the industry’s current distribution limitations: product differentiation and time-to-market, access to full and rich air content, and finally, a transparent shopping experience.

Yes, all servicing-related functionalities will be made available.

6E NDC content is now available and accessible.

The NDC content will be made available through IndiGo direct NDC APIs, GDSs, and non-GDS NDC aggregators.

IndiGo supports IATA NDC schema version 21.3.5, ensuring alignment with modern airline retailing and industry standards.

To get started with 6E NDC Swagger Portal, you will require to Login and Register. In case you need help,click here to find the process.

Yes

Our NDC products can support fare families, ancillary services offered during booking and post booking, reissue, refund,and hold booking.

You can access content for:

• Domestic Flights
• International Flights
• CodeShare Flights

• Agency
  • Agency Credit (AGT)
• Industry Payment
  • BSP Cash
• Credit Cards (Pass-through / Personal cards)
  • American Express
  • Diners
  • Mastercard
  • VISA

All requests and responses follow XML messaging structure as per IATA NDC 21.3 schema.

Typical APIs include:

• AirShoppingRQ/RS – Flight search
• OfferPriceRQ/RS – Pricing confirmation
• OrderCreateRQ/RS – Booking creation
• OrderRetrieveRQ/RS – Fetch booking details
• OrderChangeRQ/RS – Modification
• OrderCancelRQ/RS – Cancellation

• The NDC Gateway uses TLS 1.2
• All endpoints must be accessed over HTTPS

• Base64-encoded credentials are required for Authorization.
• Typically passed in the HTTP Authorization header.
• Uses Basic Authentication.
• Credentials are encoded in the format username:password.

HTTP Header Example:

Authorization: Basic <Base64Encoded(username:password)>

• Yes, communication must be established via IP-to-IP connectivity.
• Partner public IP(s) must be shared and whitelisted by 6E before access is granted.

• Strict adherence to secure transport (HTTPS).
• Compliance with API security policies (no credential exposure, encrypted payloads via TLS).
• Session/token handling must follow best practices.

• Yes, API supports gzip and deflate compression.
• Compression is recommended for improved latency and bandwidth optimization.

Example:

Accept-Encoding: gzip, deflate
        

• Use compression (gzip) to reduce payload size and improve response times.
• Minimize redundant API calls wherever possible.
• Cache static and reference data to reduce unnecessary requests.
• Handle retries using appropriate backoff strategies.
• Avoid long-running synchronous calls to improve application responsiveness.

Developers must comply with:

• IATA-compliant XML schema structure
• Proper NDC workflow orchestration (Shop → Price → Book → Service)
• API security standards (TLS, Base64 Auth, IP Whitelisting)

Yes (recommended flow):
1. AirShoppingRQ → Fetch offers
2. OfferPriceRQ → Validate pricing
3. OrderCreateRQ → Create booking
4. OrderRetrieveRQ → Confirm order

Integrators should handle:

• Business errors (e.g., fare expired, seat unavailable)
• Technical errors (timeouts, gateway failures)
• Validation errors (schema mismatch)

Yes.

• Certification is mandatory for all partners.

Certification involves:

• Execution of designated test cases
• Covering end-to-end flows:
  • Search
  • Pricing
  • Booking
  • Post-booking scenarios

Please share the test results with the 6E NDC Support Team at:
• 6ENDC.SUP@goIndiGo.in
• Ensure API logs are included, along with complete request and response payloads.

• Formal approval is granted.
• Partner is enabled for Production environment access.

Yes.
• A 6E Partner NDC Solution Design Document is mandatory.
• Required for:
  o Technical alignment
  o Architecture validation
  o Integration approval

• System architecture diagram
• API integration flow
• Authentication & security design
• Error handling strategy
• Performance considerations

• Test/UAT Environment (for certification)
• Production Environment (post certification)

No.
• Production access is granted only after successful certification and approval.

• Reach out to the 6E NDC Support Team at 6ENDC.SUP@goIndiGo.in
• Provide:
  o API logs
  o Request/Response XML
  o Timestamp and environment details

• Yes, but must be reviewed.
• Any deviation from standard schema/workflow requires approval.

• Incorrect XML schema usage
• Skipping OfferPrice step before booking
• Not enabling compression
• Missing IP whitelisting
• Incorrect Base64 encoding credentials

API documentation is shared via:
• Partner-specific Developer Portal / Documentation links
• XML schema (XSD files) for NDC 21.3.5
• Integration guides provided during onboarding

• API documentation (XML-based)
• Sample request/response payloads
• Schema definitions (XSDs)
• Test cases for certification
• Error codes and handling guidelines
• Why am I unable to access API/Portal URL?

• IP not whitelisted
• Incorrect credentials
• TLS not configured properly
• Access restricted to specific VPN/network

Step-by-step approach:
1. Identify onward and return travel dates in AirShoppingRS.
2. Find corresponding SegmentID.
3. Map SegmentID → PaxJourneyID.
4. Search PaxJourneyID → extract:
  o OfferID
  o OfferItemID
• This approach also applies to Multi-city bookings.

Look for PaxJourneyID with multiple SegmentRefIDs.
• More than 1 segment indicates a connecting flight.

Check:

<DatedOperatingSegment>
    <DatedOperatingLegRefID>...</DatedOperatingLegRefID>
    <DatedOperatingLegRefID>...</DatedOperatingLegRefID>
</DatedOperatingSegment>
        

• Same segment with multiple legs indicates a Via flight.

1. Auth (Access Token)
2. AirShopping
3. Seat/SSR Availability
4. OfferPrice
5. OrderCreate (Payment mandatory)
6. OrderRetrieve

• Yes, hold bookings are supported, subject to the applicable business agreement.

Format:
<Domain>\<AgentID>:<Password>

Example:
WWW\XNDXXXXNXX:Abc@54321

Ensure:
• Prefix with "Basic "
• Correct Base64 encoding
• Valid subscription key

Yes, within validity (~30 mins OR as per configuration).
• Use the same token in the Authorization header.

• Authorization
• Ocp-apim-subscription-key
• Content-Type
• Accept-Encoding

• A maximum of 5 IPs (combined for Test & Production environments) is allowed.

Look for:
XML
<OccupationStatusCode>F</OccupationStatusCode>

• F = Free

• L = Leg space
• W = Window
• A = Aisle
• I = Infant

• No
• Use separate APIs:

Feature	API
Seat Availability	/SeatAvailability
SSR Pre-booking	/Selling/ServiceList
SSR Post-booking	/Servicing/ServiceList

• Modify/Delete not supported
• Only addition allowed

• Yes (critical requirement)
• OfferPrice → define FOP
• OrderCreate → complete payment

• No — payment amount must match the quoted price exactly.

• Yes
  o Please refer API Guide

• First Name
• Last Name
• DOB
• Gender
• PaxRefID
• Title
• Phone Number
• ETC (Refer Booking Guide for more)

• Infants are defined under Passenger Type Code INFX (TBD)
• Infant handling is not supported via SSR

• Up to 9 (ADT + CHD)
• Up to 4 INF

• Passport (PT) only

• Not supported

• Not supported

• 2 = Business (Stretch)
• 5 = Economy

• Not supported

• Use PriceClassID

• Seat may already be booked
• Always re-fetch SeatAvailability

• Use correct endpoint /Servicing/ServiceList

• The baggage discrepancy is a known issue at the host system level.
• Similar inconsistencies may occur in related workflows due to existing system limitations.
• Resolution is currently in progress and will be addressed in an upcoming fix.

• No, underpayment or overpayment is not allowed.
• Payments must be completed for the exact amount specified in the OfferPrice response (OfferPrice RS).