Deduplication is the hard part of travel supply

Connecting a new supplier is a week of work. Making that supplier's inventory usable alongside everyone else's is the part nobody warns you about.

Here is the problem in one line: four suppliers send you the same hotel, and none of them agree on its name, address, or identifier.

Source	Name	Code
DMC — Iberia	Hotel Marés de Palma	HTL-88213
GIATA	Hotel Mares de Palma	1234567
Bedbank	Mares Palma Hotel & Spa	45821
DMC — Balearics	H. Marés Palma	MP-0042

If you pass all four through to your search results, you show the same property four times at four prices. Your conversion rate drops, your users lose trust, and your support team starts fielding questions you cannot answer.

Why string matching fails

The obvious first attempt is fuzzy name matching. It breaks quickly:

• Diacritics and transliteration. Marés, Mares, Marés — the last one is a different Unicode composition of the same word.
• Marketing suffixes. "& Spa", "Resort", "by the Sea" appear inconsistently.
• Genuinely similar neighbours. Two different Hilton properties four streets apart will score higher against each other than one property against its own misspelling.

Geocoding helps until you meet a resort complex where three legitimately distinct properties share one entrance and one set of coordinates.

What actually works

Deduplication has to be a pipeline, not a function. ApiXV runs sophisticated AI processing across the full set of supplier signals rather than comparing strings:

1. Normalise — Unicode composition, casing, punctuation, known suffix vocabulary.
2. Block — narrow candidates by geography before comparing anything expensive.
3. Score — AI processing weighs name, address tokens, geographic distance, content and room-inventory signals together, rather than trusting any one of them.
4. Resolve identifiers — where a supplier gives a GIATA or Bedbank code, that is a far stronger signal than any string comparison.
5. Ground externally — match the result against Google CID legal-entity business identifiers, so the decision is anchored to a real business rather than to our own opinion. ApiXV grounds 98.8% of the network this way.

Step five is the one that gets skipped, and it is the one that determines whether the output is trustworthy. Matching against your own catalogue only proves you are self-consistent.

The mapping network

The output of that pipeline is what we call the mapping network: one identity per real property, with every supplier record that describes it attached to it.

What you get is a single identifier.

{
  "hotel_uid": "AXH-qCzrQmMQvRPa",
  "name": "Hotel Marés de Palma"
}

One property, whichever supplier it arrived from. The supplier is resolved from the UID, so you never hold a mapping table and never send a supplier code you had to look up yourself.

Every property in the mapping network is also fully geocoded — country, area, state, city, coordinates and a Google Plus Code. Geography is not just an output; it is one of the strongest signals the matching uses to separate two genuinely different hotels that happen to share a name.

The distinction matters: a mapping table records what someone decided. A mapping network is grounded against something outside itself, so it can be checked.

Treat hotel_uid values as temporary identifiers. They are not intended for long-term storage or external caching — resolve them against the API rather than persisting them.

That constraint surprises people, but it is deliberate: it means we can improve the underlying matching without stranding you on identifiers we no longer believe in.