Full-transaction logging
Every supplier call is archived with raw request/response bodies and timing — a complete replay trail for support and reconciliation.
TravelMatic · Multi-supplier booking platform
One search.
Every supplier. Fully ticketed.
TravelMatic sells bus, ferry, rail, flights and hotels from one experience. Appnox engineered the layer underneath: 13 supplier integrations across REST, SOAP and NDC, normalised into one fast, consistent booking flow.
20 minutes with a solutions architect · No obligation
Why it matters
Travellers see one result list. Your team sees one booking.
Before this work, every supplier spoke a different language — different auth, different shapes, different failure modes. Now a customer search fans out across suppliers, merges into one ranked list, and every confirmed booking lands in the same operational record, no matter who fulfilled it.
How it is built
One pattern, repeated thirteen times.
Every integration follows the same disciplined shape — so a new supplier means one new Repository / Interface pair, not a rewrite of the booking flow.
- RouteValidates input
- ControllerResolves supplier
- RepositoryMaps fields, reads/writes DB
- SDK clientSingleton per supplier
- Supplier APIREST · SOAP · NDC
Live telemetry hook
A shared observable emits a supplier.call event per outbound call — one place to monitor all supplier traffic.
Audit timeline
Centralised activity logging classifies every request, giving operations one timeline across every supplier.
Inside each vertical
Five booking journeys. Zero supplier chaos.
Bus
REST / JSON1 supplier · Distribusion
Full booking lifecycle behind one facade — search to ticket, with parallel multi-route search.
- Parallel curl_multi fan-out merges several route combinations as one call
- Passenger-type mapping + reservation confirm split per route
- Async ReservationConfirmJob polls until ticketed, then writes Dossier + segments
Ferry
REST / JSON1 supplier · Distribusion Ferry
Richer two-phase Booking + Reservation model for holding inventory before ticketing.
- Hold / confirm / cancel separated from the ticketed Booking record
- Redis-cached port autocomplete; live API reserved for booking-critical calls
- Same async confirm-and-poll pattern as bus, writing FerrySegments
Rail
REST + SOAP3 suppliers · one API
Distribusion, NTV/Italo and PICO/Trenitalia presented as a single search-and-book experience.
- ResponseMerger + same-day filter unify three protocols into one ranked list
- Idempotent hold replay (NTV) and resume-from-hold booking (PICO)
- Live DossierUpdated events push status to the traveller in real time
Flights
REST + SOAP + NDC4 paths · Sabre + Turkish NDC
NDC and ATPCO fares in one Sabre call, plus Turkish NDC — searched concurrently.
- BargainFinderMax with NDC + ATPCO sources in a single request
- Octane concurrent search across Sabre and Turkish; unified ranked list
- REST order + SOAP terminal remark enrichment for a complete PNR picture
Hotels
REST + SOAP4 suppliers · one ranked list
CDS, RateHawk, Ospita and Sabre Hotel merged with price / distance filters in one pass.
- Prebook-before-create guarantees a fresh rate key (RateHawk)
- PCI-aware tokenized card flow keeps raw PAN out of booking calls
- 24-hr content cache + KeyDB batch-fetch for catalog-scale performance
Supplier directory
13 integrations. One contract.
Privately maintained SDKs, each with its own auth and data shape — all normalised before your team or your customer ever sees them.
| Vertical | Provider | Protocol | Auth |
|---|---|---|---|
| Bus | Distribusion Retailer API | REST / JSON | API-key header |
| Ferry | Distribusion Ferry (2-phase) | REST / JSON | API-key header |
| Rail | Distribusion Rail | REST / JSON | API-key header |
| Rail | NTV / Italo | SOAP / XML | Username + password |
| Rail | PICO / Trenitalia | SOAP / XML | Channel ID + version |
| Flights | Sabre Shopping (NDC + ATPCO) | REST / JSON | OAuth2 |
| Flights | Sabre Classic / PCC | SOAP / XML | PCC session |
| Flights | Sabre ATPCO Orders | REST / JSON | OAuth2 |
| Flights | Turkish Airlines NDC | NDC XML / JSON | OAuth2 client-credentials |
| Hotels | CDS | REST / JSON | Bearer token |
| Hotels | ETG / RateHawk | REST / JSON | HTTP Basic |
| Hotels | Ospita | SOAP / WSDL | Per-call credential block |
| Hotels | Sabre Hotel | REST / JSON | OAuth2 |
Supplier names identify integration endpoints engineered for TravelMatic. No official partnership or accreditation is implied.
Engineering that compounds
Decisions that keep paying off after launch.
Protocol-agnostic contracts
REST, SOAP/WSDL and NDC all conform to one Repository / Interface shape. Controllers never care which protocol answered.
Registry, not branching
A SupplierType registry maps an ID to the right repository. New suppliers slot into existing endpoints — no new routes.
Concurrency where it pays
curl_multi fan-out for bus / ferry / rail and Octane concurrency for flight search. Direct, measurable search-latency wins.
Async confirm, poll-until-ready
Supplier acceptance is separated from “fully ticketed”. Queued jobs poll, then write the definitive Dossier record.
Cache by change-rate
Near-permanent Redis for stations/ports, 6-hr filesystem cache for PICO catalog, KeyDB batch-fetch for hotel content.
One domain record
Every booking lands as Dossier + Travellers + segments — invoicing, reporting and CMS work identically, any supplier.
In production
The interface your team operates.
Booking and management surfaces from the live TravelMatic build — the visible end of the integration work above.
What this proves — and what it doesn’t.
This is evidence of a delivered multi-supplier platform: unified search, async ticketing, and one operational record across 13 integrations. It is not a promise of universal autonomous ticketing or support for every GDS on day one.
- Which part changed: supplier connectivity + booking operations.
- What stayed human: approvals, exceptions, commercial decisions.
- What to validate next: your suppliers, access, and servicing scope.