FastX isn't an upgrade anymore. It's how our Network operates.
Posted by
Travelgate
Six months ago, FastX was the new option. Today it's the fastest-growing layer of the Travelgate Marketplace — and the numbers prove it.
📊 The Network, right now:
| Metric | Number |
|---|---|
| Verified Sellers running FastX Technology | 50+ |
| Buyers already connecting through FastX | 30+ |
| Unified code system for hotels, boards & rooms | 1 |
| Cost to migrate as an existing Buyer | €0 |
💡 Already read "What is FastX"? You know the basics: one shared code system, replacing supplier-by-supplier mapping. This article goes further — what's actually happening across our Network right now, why adoption is accelerating, and what it technically means for Buyers and Sellers building on Travelgate today.
Since January 1st, 2026, FastX became the mandatory connection mode for all new Buyers joining Travelgate. Existing Buyers can stay on classic HotelX, but the ones dealing with mapping headaches or aggregation issues are moving over fast.
The Network effect is compounding:
More Verified Sellers → more standardized supply → faster Buyer activations → more Buyers → repeat.
That's the revolution. FastX isn't just a technical spec anymore. It's a growing, self-reinforcing Marketplace layer.
🧩 The Problem It Kills
Every time a Buyer wanted to connect a new Supplier, the same three problems showed up:
- 🐌 Slow onboarding — every new Supplier meant a fresh configuration cycle
- 🔁 Repetitive mapping — hotel, board, and room mappings redone from scratch, Supplier after Supplier
- ⚙️ Operational overload — multiple queries, multiple code systems, more complexity, less performance
❌ Before FastX — the same hotel could have three different codes across three Suppliers. Your system had to understand every format and fire one query per Supplier code.
✅ With FastX — one shared language. Travelgate handles the Supplier translation internally — your system only ever speaks FastX.
⚡ How FastX Actually Standardizes a Marketplace
📌 Note: FastX is not a separate API. You keep using HotelX exactly as before — FastX just gives every hotel, board, and room a single, persistent, marketplace-wide code.
🏨 Hotels & boards — mapped once, valid everywhere
Sellers validate their hotel and board mappings once, using reference data: hotel name, country, address, coordinates. Every mapping is tracked as one of three statuses:
- 🟢 Validated — Seller confirmed the mapping
- 🟡 Pending — awaiting Seller review, available by default
- 🔴 Invalidated — Seller rejected it, never allowed
By default, your booking flow accepts validated and pending codes. Need Seller-confirmed mappings only? Switch to Validated-only mode in your API Settings.
🛏️ Rooms — standardized at the speed of search
Room descriptions change too fast for a static master list, so FastX takes a different approach. An AI-based process reads every Supplier's room description at search time and detects:
Category · Type · Capacity · Environment · View · Features · Beds · Bedrooms
...then returns one standardized FastX room code and description alongside the Supplier's original text.
🔎 Example — five Suppliers, one FastX code:
| Supplier | Supplier Room Description | FastX Code | FastX Description |
|---|---|---|---|
| SUP1 | Sea View Double Room (BB BAR FLEX) | str--AA--d-- |
Standard Double Room views Sea |
| SUP2 | DOUBLE SEA VIEW | str--AA--d-- |
Standard Double Room views Sea |
| SUP3 | Double Sea View AI | str--AA--d-- |
Standard Double Room views Sea |
| SUP5 | Habitación doble con vistas al mar 2A | str--AA--d-- |
Standard Double Room views Sea |
| SUP6 | Main Building Double Seaview Room | str--AA--d-- |
Standard Double Room views Sea |
Six ways of describing the same room, from five different Suppliers. One FastX code. That's the standardization engine doing its job in real time.
🏆 Aggregation — turning standardized data into decisions
Once everything speaks the same language, comparing options across Suppliers stops being guesswork. The Preference plugin groups equivalent options (typically hotel + board + room) and picks a winner per group — cheapest price automatically, or a custom rule you define (e.g. "favor SUP2 within 2% of the cheapest price").
| Group | Winner | Price | Reason |
|---|---|---|---|
| Standard Room + All Inclusive | SUP1 | 100.00€ | 🏅 Cheapest option |
| Suite Deluxe + All Inclusive | SUP2 | 189.00€ | 🏅 Cheapest option |
| Suite Deluxe with Jacuzzi | SUP3 | 218.00€ | 🏅 Only option |
🔄 What a Search Looks Like Once FastX Is On
- Send one Search with FastX codes — no per-Supplier context required; omit the field entirely, or set it explicitly to
FASTX - Travelgate queries every eligible Supplier in parallel — your FastX codes are translated to each Supplier's native codes internally, automatically
- You get standardized data, plus the original — responses include FastX hotel, board, and room codes, and the Supplier-native values on request
- Aggregation rules pick the winners — Cheapest Price or Preference plugin collapse duplicate options into one clean result set
- One result set replaces many queries — what used to be multiple requests across multiple code systems is now a single, unified response
✅ Why "50+ Verified Sellers" Is the Number That Matters
A Verified Seller badge isn't handed out for showing up. Sellers earn it once 80% or more of their hotel and board mappings have been validated against Travelgate's reference data.
🎖️ It's a coverage indicator, not a blanket quality guarantee on every single mapping — but it tells Buyers, at a glance, which Suppliers are ready to search with zero mapping effort on their side.
Every Verified Seller added to the Network is one less mapping job for every Buyer connected to Travelgate — visible directly in the Travelgate Network directory.
🤝 What Growth on FastX Means for Each Side of the Network
🧳 For Buyers
- One code system instead of one per Supplier
- Aggregate multiple Suppliers in a single Search request
- Faster Supplier activations, lower onboarding friction
- Full transparency: FastX and Supplier-native values, always
- GIATA-aligned codes for cross-platform consistency
🏨 For Sellers
- Validate hotel and board mappings a single time
- Serve every FastX Buyer with standardized codes instantly
- Skip the mapping back-and-forth on every new Buyer integration
- Improve portfolio consistency across the whole Marketplace
- Earn the Verified Seller badge and stand out in the Network
💸 For Existing Buyers: Migrating Is Free, and It Doesn't Touch Your API
If you're already live on HotelX, moving to FastX is not a rebuild. It's a handful of adjustments to how you send requests, not a new integration:
- Context becomes optional — omit it and Travelgate assumes FastX codes, or set it explicitly to
FASTX - Your response gets richer, not different —
hotelCode,boardCode, and room code/description now return FastX values by default; addhotelCodeSupplier,boardCodeSupplier, androoms → supplierCode/descriptionSupplierif you still want the Supplier's originals too - Access filtering gets more flexible — one Search can now span multiple accesses across multiple Suppliers, not just one Supplier per request
- Aggregation plugins become worth using — with more Suppliers answering the same Search, Cheapest Price or Preference plugins keep your response clean instead of noisy
📝 Onboarded before January 1st, 2026? You only need to sign an additional annex to activate FastX codes in your booking flow — simple and completely free.
🔗 Go Deeper
- FastX Solution Overview — the full technical breakdown of how codes are generated, validated, and aggregated
- Migrate to FastX for free — step-by-step guide for Buyers already running Hotel-X
- Mapping at Travelgate — how FastX codes sit alongside Supplier codes on the Platform
- Hotels Content Query — retrieve the FastX master hotel list and see what content ships with every FastX search