Which Integration Should a South African OTA Choose?
South African travel tech faces a critical distribution decision. Legacy GDS pipes still provide broad airline access, while airlines increasingly push richer content through NDC channels, and low-cost carriers may rely on proprietary APIs for selected inventory. For an OTA building or upgrading its travel software solutions, choosing the right combination of airline connectivity can affect inventory coverage, booking workflows, servicing and long-term scalability.
The Three Channels
GDS (Global Distribution System)
Amadeus, Sabre, and Travelport legacy EDIFACT-based systems aggregating 400+ airlines. Mature servicing (ticketing, voids, refunds, exchanges), BSP settlement, back-office tooling. Cost: $0.50–$3.00/segment + monthly minimums. Limitation: content increasingly incomplete airlines withhold branded fares, ancillaries, and dynamic pricing.
For an OTA, GDS integration remains one of the fastest ways to connect with broad airline inventory without building a separate integration for every carrier.
NDC (New Distribution Capability)
IATA-backed XML/JSON API standard. Airlines retail directly with rich content branded fares, bundles, seat maps, ancillaries. Lower/zero distribution surcharges. Modern REST/JSON patterns. Challenge: fragmented implementations across carriers, post-booking servicing still maturing.
Implementing NDC connectivity typically requires modern API development services, particularly when an OTA needs to normalize different airline responses into a consistent shopping and booking experience.
Direct Airline API
Proprietary, airline-specific APIs outside GDS/NDC standards. Exclusive fares, loyalty integration, often the only way to access LCC inventory. Trade-off: high engineering cost per airline, no standardisation, linear scaling effort.
Direct airline APIs can provide access to specialized inventory and airline-specific capabilities, but they also increase engineering requirements. An experienced API development company can help build the authentication, offer normalization, booking, servicing and error-handling layers required for multiple airline connections.
South African Airline Landscape
| Airline | GDS | NDC | Direct API |
|---|---|---|---|
| SAA | Full (Amadeus, Sabre, Travelport) | Evaluating | Limited |
| Airlink | Available | Active (AirGateway, Verteil) | Partner portal |
| FlySafair | Limited | Via TPConnects Iris | Primary (Radixx PSS) |
| LIFT | Limited | Minimal | Tech-forward, limited 3rd party |
| Global (Emirates, BA, etc.) | Full | Active programs | Selective |
Key insight: SA has a split market. Full-service/international carriers accessible via GDS with growing NDC. LCCs (FlySafair, LIFT) lean direct GDS-only OTA misses domestic inventory.
This fragmented environment creates a strong case for flexible travel portal development. Instead of designing an OTA around a single supplier, the architecture should allow additional airline APIs, GDS connections and NDC sources to be added as business requirements evolve.
Channel Comparison
From a technology perspective, the decision is not only about distribution cost. It also affects API complexity, inventory normalization, servicing workflows and the scalability of the OTA's underlying software architecture.
| Criterion | GDS | NDC | Direct API |
|---|---|---|---|
| Time to market | Fast | Moderate | Slow |
| Content richness | Basic | Rich | Deepest |
| Airline coverage | 400+ carriers | 50–100 via aggregators | 1 per integration |
| Transaction cost | High | Lower | Variable |
| Engineering cost | Low | Moderate | High |
| Servicing maturity | Excellent | Improving | Varies |
| Ancillary revenue | Limited | Strong | Strongest |
| Scalability | Excellent | Good | Poor |
The Hybrid Architecture
No single channel is sufficient. The winning strategy is a normalised, multi-source inventory engine:
- GDS Layer → Amadeus + Sabre + Travelport for breadth, servicing, BSP settlement
- NDC Layer → Aggregator (Duffel/TPConnects) + selective airline-direct NDC for rich content
- Direct API Layer → FlySafair (Radixx), Aerocrs, Mango for LCC inventory access
The normalisation layer converts heterogeneous responses into consistent offers. Smart routing prefers NDC when available (lower cost, richer content), falls back to GDS. Servicing handled per channel changes/cancellations via the booking's originating channel.
Hybrid in Practice: Production Integration Map
A live South African OTA runs 13+ supplier integrations across GDS and non-GDS channels simultaneously, proving the hybrid model works in production:
GDS — Type 1 (Breadth & Servicing)
| Supplier | Role |
|---|---|
| Amadeus | Primary GDS — international coverage, BSP, full servicing |
| Amadeus Fare Families | Branded fare and fare-family content |
| Sabre | Secondary GDS — redundancy, fare comparison |
| Sabre Multi-Ticketing | Complex itineraries, split PNRs |
| Travelport (UAPI) | Third GDS — Galileo/Apollo legacy carriers |
Non-GDS — Type 2 (Direct Access & LCC)
| Supplier | Role |
|---|---|
| Radixx (FlySafair) | Direct LCC fares, no GDS surcharge, ancillaries |
| Aerocrs | Regional airline inventory, no GDS middleman |
| Mango | LCC fares inaccessible through GDS |
| Kulula (Direct) | Direct inventory access |
| Kulula (Traveltalk) | Redundancy via Elleipsis middleware |
| Thomalex/Elleipsis | Normalisation bridge for non-GDS carriers |
| Travelstart | Aggregated LCC content, gap filler |
Bottom line: a 2:1 non-GDS to GDS ratio is the optimal strategy. International carriers need GDS for servicing maturity. Domestic LCCs need direct pipes for inventory access. The hybrid model is the competitive advantage.
The Verdict
The decision between GDS, NDC and direct airline APIs should not be treated as an either/or choice.
- GDS remains essential for broad airline coverage and mature servicing.
- NDC is increasingly important for richer airline content, branded fares and ancillary products.
- Direct APIs are strategic when a carrier provides inventory or capabilities that are unavailable through other channels.
- The winning architecture is hybrid: a normalized multi-source engine with intelligent routing, supplier-specific servicing and scalable API connectivity.
