title: “Flight Supplier Strategy — Duffel vs Verteil” category: Supply Strategy status: Draft created: 2026-02-25 context: origin: India primary_corridor: India ↔ GCC secondary: Global long-haul model: Hybrid (Meta + Booking Engine) expected_scale: 100k–1M searches/month related:

• “Aggregated Reference”
• “Complete Findings”

← Section Index · Master Index

Flight Supplier Strategy & Architecture Blueprint

Duffel vs Verteil — Coverage, Risks, Unit Economics & Production Architecture

Context

1. Executive Summary

After structured analysis and research:

• Both Duffel and Verteil are relevant for the GCC corridor
• Verteil has stronger publicly documented airline-recognized partnerships in GCC
• Duffel provides broad global airline access and developer-friendly APIs
• A dual-supplier model increases coverage and leverage but adds significant complexity
• Recommended approach: staged hybrid — Duffel-first, Verteil selective addition

[!IMPORTANT] Bottom line: Start with Duffel for broad coverage and fast MVP. Add Verteil selectively when corridor volume justifies the complexity. Design supplier-agnostic from day one.

2. Business Context

Confirmed Decisions

3. Coverage Analysis

Verteil — GCC Strength

Documented NDC partnerships include:

Implication: Strong corridor relevance and direct airline NDC relationships. Verteil excels for GCC-specific airline content.

Duffel — Global Breadth

Duffel claims:

• Access to 300+ airlines
• NDC + GDS coverage in a single API
• Offer & Order capability for key carriers including Emirates, Etihad, Qatar

Limitations:

• ⚠️ No publicly enumerated airline-by-airline list
• ⚠️ GCC LCC coverage requires vendor validation (Air Arabia, FlyDubai, etc.)

Implication: Strong global long-haul coverage and mature API design. Developer experience is industry-leading.

Coverage Comparison Matrix

4. Strategic Decision

Option A: Duffel Only

Option B: Verteil Only

Option C: Hybrid Model ✨ (Recommended)

Recommendation: Option C (Hybrid) with Duffel as primary and Verteil added in Phase 2.

5. Production-Grade Supplier Abstraction Architecture

Core Principle

Suppliers are plugins behind stable internal contracts. Your system owns: normalization, ranking, booking orchestration, servicing logic, and observability.

Dual-Supplier Parallel Search & Deduplication Flow

sequenceDiagram
    participant Gateway
    participant Orch as Search Orchestrator
    participant Duffel as Duffel Adapter
    participant Verteil as Verteil Adapter
    participant Norm as Normalization Layer
    participant Dedup as Dedup Engine

    Gateway->>Orch: Search (India to GCC)
    par Query Duffel
        Orch->>Duffel: Request Deals
        Duffel-->>Orch: Schema A Res
    and Query Verteil
        Orch->>Verteil: Request Deals
        Verteil-->>Orch: Schema B Res
    end
    Orch->>Norm: Normalize both schemas to CanonicalOffer
    Norm-->>Orch: Normalized Results
    Orch->>Dedup: Merge identical segments
    Note over Dedup: If PriceDiff < 2%, use cheapest
    Dedup-->>Gateway: Consolidated ranked offers

High-Level Architecture

flowchart TD
    GW[API Gateway] --> SO[Search Orchestrator]
    SO --> SR[Supplier Registry]
    SR --> DA[Duffel Adapter]
    SR --> VA[Verteil Adapter]
    DA & VA --> NL[Normalization Layer]
    NL --> DE[Dedup Engine]
    DE --> RE[Ranking Engine]
    RE --> CACHE[Cache]

    BO[Booking Orchestrator] --> RP[Reprice Service]
    RP --> OS[Order Service]
    OS --> PS[Payment Service]
    PS --> TS[Ticketing Service]
    TS --> PBS[Post-Booking Service]

Cross-reference: See Aggregated Reference § Architecture for the full enterprise topology.

6. Canonical Offer Model (Internal)

All supplier responses are normalized into this internal model:

type CanonicalOffer = {
  offerId: string;
  supplier: "DUFFEL" | "VERTEIL";
  supplierOfferId: string;
  expiresAt: string; // ISO 8601 timestamp — offers have TTLs
  price: {
    total: number;
    currency: string; // ISO 4217 currency code
  };
  itinerary: {
    slices: Slice[]; // Each slice = one direction of travel
    durationMinutes: number;
    stops: number;
  };
  fare: {
    fareFamily?: string;     // e.g., "Economy Saver", "Business Flex"
    refundability?: string;  // "refundable" | "non-refundable" | "partially-refundable"
    changeability?: string;  // "free" | "fee-based" | "not-allowed"
  };
};

[!TIP] Designing the canonical model early is critical. Every new supplier added later must map into this model. Keep it extensible but not overly generic.

7. Implementation Roadmap

gantt
    title Supplier Integration Roadmap
    dateFormat  YYYY-MM
    section Phase 1 (0–6m)
    Duffel Integration      :2026-03, 4m
    Canonical Models        :2026-03, 2m
    Search + Booking Orch.  :2026-04, 3m
    Observability Setup     :2026-05, 2m
    section Phase 2 (6–12m)
    Verteil Adapter         :2026-09, 3m
    Airline-Based Routing   :2026-10, 2m
    Controlled Rollout      :2026-11, 2m
    section Phase 3 (12m+)
    Margin-Based Routing    :2027-03, 3m
    Airline Negotiations    :2027-04, 3m
    Predictive Pricing      :2027-06, 3m

Phase 1 (0–6 Months) — Foundation

• ✅ Duffel integration (search + booking)
• ✅ Canonical offer/order models
• ✅ Search + booking orchestrator
• ✅ Observability setup (latency, errors, mismatch rates)

Phase 2 (6–12 Months) — Expansion

• ✅ Add Verteil adapter behind abstraction layer
• ✅ Airline-based routing (route Verteil for GCC airlines, Duffel for global)
• ✅ Controlled rollout with shadow testing

Phase 3 (12+ Months) — Optimization

• ✅ Margin-based routing (choose supplier per-request by expected margin)
• ✅ Airline incentive negotiations (leverage volume data)
• ✅ Predictive pricing layer

8. Final Recommendation

[!IMPORTANT] Start with Duffel. Design supplier-agnostic architecture from day one. Add Verteil selectively when corridor volume justifies complexity.

Hybrid is a strategic advantage only if architecture is strong. Without proper abstraction, dual-supplier integration becomes a maintenance nightmare.

Quick Flashcards

← Section Index · Master Index