Ask two travel-tech engineers whether an inventory feed should be XML or JSON and you will get a thirty-minute debate. The honest answer: for tour and transfer inventory, both work, and the format is rarely what makes an integration succeed or fail. What matters far more is the contract - the schema, the stability, and how change is handled. Still, the choice has real trade-offs worth understanding.
Where XML still earns its place
- Schemas and validation. XSD lets you validate a feed against a formal schema before processing - valuable for catalogue data with strict rules.
- Industry precedent. Much of travel distribution (OTA/NDC-style messaging) is historically XML, so tooling and expectations exist.
- Attributes and namespaces. For richly-structured records, attributes can keep documents compact and self-describing.
<product code="hagia-sophia-grand-bazaar" type="tour"> <title>Hagia Sophia & Grand Bazaar Tour</title> <duration>PT8H</duration> <net currency="EUR">149.50</net> </product>
Where JSON wins
- Developer ergonomics. It maps directly onto native objects in almost every language - less ceremony, faster to parse.
- Payload size. Less markup overhead, which matters for large or frequently-pulled feeds.
- Tooling for the modern web. If your stack is JavaScript/TypeScript or a JSON-first API gateway, JSON removes a translation step.
{ "code": "hagia-sophia-grand-bazaar", "type": "tour",
"title": "Hagia Sophia & Grand Bazaar Tour",
"duration": "PT8H", "net": 149.50, "currency": "EUR" }
Choose the format your stack already speaks fluently. The cost of fighting your tooling outweighs any abstract elegance.
The things that actually matter
Whichever format you pick, insist on these:
- A documented, versioned schema. You should be able to validate a payload and know when a breaking change is coming.
- Stable identifiers. Product codes must not change when a title is edited.
- Explicit units. Durations as ISO 8601 (
PT8H), money with an explicit currency, times with a timezone. - A clear "removed" signal. So a missing product means "retired," not "truncated file."
A pragmatic recommendation
If you are greenfield and JSON-native, take JSON. If you already run XML-based distribution or need formal schema validation, XML is perfectly sound. Better still, work with a supplier that can serve the catalogue in the format you prefer and keep the same product identifiers across both - so the format becomes an implementation detail, not a lock-in. That is how Connect exposes Istanbul tour and transfer inventory: one stable contract, the representation that suits your team.