Amadeus, Sabre, and Travelport each speak their own dialect — different API architectures, different response schemas, different error handling — so an integration built for one GDS rarely transfers cleanly to another. This RFP template is for travel agencies, OTAs, and tour operators evaluating a custom travel booking platform build.
Before You Start
- [ ] Decide which GDS(s) and supplier APIs you need: Amadeus, Sabre, Travelport, plus airline consolidators, hotel wholesalers, and bed banks
- [ ] Confirm whether you need single-GDS depth or multi-source aggregation for redundancy and rate comparison
- [ ] Map your NDC (New Distribution Capability) requirements separately from traditional EDIFACT/GDS integration — these run on different timelines and neither fully replaces the other yet
- [ ] Set realistic expectations: full Offer & Order capability under NDC is still an early-stage effort even for advanced airlines
Section 1: GDS and Supplier Integration
- [ ] Which GDS platforms does the vendor have production experience normalizing (not just theoretical API access)?
- [ ] How does the platform handle differing response schemas and error handling across Amadeus, Sabre, and Travelport?
- [ ] Does the architecture support automatic failover to alternative suppliers if one GDS or API experiences downtime?
- [ ] What's the vendor's plan for the multi-year NDC/EDIFACT hybrid period — are they building for both simultaneously?
Section 2: Core Platform Features
- [ ] AI-powered or rules-based fare/rate comparison across integrated sources
- [ ] Multi-currency and multi-language support if you serve international travelers
- [ ] Booking management and self-service portal for customer-initiated changes and cancellations
- [ ] Automated ticketing workflow with confirmation and itinerary generation
Section 3: Payments
- [ ] PCI-DSS compliance scope for any component that touches card data
- [ ] Support for regional payment methods relevant to your customer base, not just major card networks
- [ ] Refund and cancellation workflow that reconciles correctly with supplier payment terms (some suppliers have stricter refund windows than others)
Section 4: Cost and Ongoing Support
- [ ] Full cost breakdown: development, per-transaction GDS fees, and ongoing maintenance
- [ ] Who maintains the integration when a GDS changes its API version — you or the vendor, and under what SLA?
- [ ] Migration plan if you need to add or replace a GDS/supplier later
Vendor Scorecard
| Criterion | Weight | Score (1–5) | Notes |
|---|---|---|---|
| Production GDS integration experience | 25% | Ask for reference clients on your specific GDS mix | |
| Redundancy and failover architecture | 20% | Confirm automatic fallback, not manual intervention | |
| NDC/EDIFACT hybrid readiness | 15% | Ask how they're handling the multi-year transition | |
| Payment and compliance depth | 20% | Confirm PCI-DSS scope and regional payment support | |
| Total cost of ownership | 20% | Include per-transaction GDS fees, not just build cost |
Red Flags to Watch For
- A vendor who claims "GDS integration" without naming which specific GDS platforms they've shipped in production
- No failover plan if a GDS or supplier API goes down
- Vague answers about who owns fixing the integration when a GDS changes its API version
- No clear NDC strategy, treating it as a future problem rather than a parallel build-track today
How to Use This Template
Send this to three to five shortlisted vendors and require specific, named GDS experience — not generic claims of "multi-GDS support." Weight redundancy and failover heavily, since a single-source dependency is the most common cause of booking platform outages during supplier downtime. Score every vendor with the same evaluators before signing.