Hotel mapping: giving one hotel one ID across supplier feeds

Travelexe edge91 — Sat, 31 Oct 2026 11:28:47 +0000

Disclosure: written by the TraveleXe team. We build Syncro, the hotel and room mapping system mentioned below.

If you sell hotels from more than one supplier, you've seen this: the same hotel appears four times in your search results, with four slightly different names, two addresses and coordinates 80 metres apart. Your "cheapest price" sort is now comparing a hotel against itself.

That's the hotel mapping problem. Here is how it's usually solved, and what we learned building it.

The problem in one table

Supplier	Name	Address	Lat, Lng
A	Grand Palm Resort & Spa	12 Beach Rd	25.1180, 55.1350
B	The Grand Palm Resort	Beach Road 12	25.1186, 55.1342
C	GRAND PALM RESORT AND SPA DUBAI	Jumeirah Beach Rd, 12	25.1179, 55.1351

A human sees one hotel. A database sees three.

Step 1: one canonical ID

The core design decision is a canonical record per physical property, with every supplier's hotel code linked to it. In Syncro this is a permanent global Mapping ID per hotel, and every supplier hotel ID points to it. Everything downstream (search, price comparison, reporting) uses the canonical ID.

Step 2: don't compare everything with everything

Comparing every new hotel against every known hotel is O(n²) and slow. The standard technique is blocking: only compare candidates that are near each other.

# Illustrative only: geo blocking with a coarse grid
def block_key(lat, lng, cell=0.01):   # ~1 km cells
    return (round(lat / cell), round(lng / cell))

def candidates(hotel, index):
    k = block_key(hotel.lat, hotel.lng)
    for dx in (-1, 0, 1):
        for dy in (-1, 0, 1):
            yield from index.get((k[0] + dx, k[1] + dy), [])

Step 3: score, don't guess

For each candidate pair, combine several weak signals into one score: normalised name similarity, address similarity, distance, star rating, chain or brand, postcode.

# Illustrative only: a weighted match score
def normalise(name):
    stop = {"the", "hotel", "resort", "and", "&", "spa"}
    return " ".join(w for w in name.lower().replace(",", " ").split() if w not in stop)

def score(a, b):
    s_name = similarity(normalise(a.name), normalise(b.name))   # e.g. token-set ratio
    s_addr = similarity(a.address_norm, b.address_norm)
    s_geo  = max(0.0, 1 - haversine_m(a, b) / 250)              # 0 beyond 250 m
    return 0.5 * s_name + 0.2 * s_addr + 0.3 * s_geo

Syncro's page describes the same family of signals: fuzzy logic, geospatial intelligence and attribute comparison, with AI used to detect and merge duplicates and to keep learning as feeds change.

Step 4: confidence bands and a human queue

A single threshold is a mistake. Use three bands:

High confidence: link automatically.
Middle band: send to a review queue.
Low: treat as a new property.

The middle band is where the quality of a mapping system shows. Syncro attaches an AI confidence score to each mapping and supports manual override and approval workflows where needed, which is the same pattern.

Step 5: rooms are the harder half

Matching hotels fixes duplicates in the list. It doesn't fix price comparison. "Deluxe King Sea View", "DLX KG SV" and "Superior Double, Sea Facing" may or may not be the same room. Room mapping normalises names, amenities, occupancy and bed types into master room types. Syncro does this as a separate Room Mapping API alongside the Hotel Mapping API.

Without room mapping, the cheapest result is often just the most loosely described room.

Step 6: mapping is a process, not a project

Suppliers add hotels daily and rename room types without notice. A mapping system needs to auto-map new hotels as they arrive, continuously re-validate existing mappings and detect room category changes. Syncro's page lists all three. A one-off cleanup decays within months.

Build or buy?

Build it if you have data engineers, few suppliers and a reason to own the matching logic. Buy it if mapping isn't your product. Options include GIATA, Vervotech, Gimmonix and Syncro, usually delivered by API. In any evaluation, map your own two or three supplier feeds in the trial: accuracy on someone else's data tells you little.

We wrote up a fuller comparison of hotel mapping options and the tests to run in a demo here: https://www.travelexe.com/best-hotel-mapping-software/

One hotel API vs ten supplier integrations: what we learned

Travelexe edge91 — Sat, 31 Oct 2026 07:34:47 +0000

From the TraveleXe engineering team. We build APINex, a unified travel API — this post is about the trade-offs, including when you shouldn't use one.

If you're building a travel booking product, you'll hit the supplier question early: integrate each hotel supplier directly, or put one aggregation layer in front of all of them?

Direct integrations give you full control of each supplier's features and no middle layer. The cost: every supplier has its own schema, auth, error codes, rate-limit behaviour and certification process. Ten suppliers is ten of everything, and they all change on their own schedules.

A unified API gives you one schema, one auth model and normalised responses. The costs are real too: you depend on the aggregator's uptime and its mapping quality, and supplier-specific features may arrive later.

What mattered most for us:

Normalisation is the product. Converting ten XML dialects into one JSON response is the easy part. Knowing that two responses describe the same hotel and the same room (mapping) is the hard part.
Caching is a correctness problem, not just speed. Cached availability that goes stale turns into failed bookings. Cache search, re-check price at pre-book, never cache the final confirmation.
Timeouts per supplier. One slow supplier shouldn't hold the whole search. We return what's ready and stream late results.
Bring-your-own-credentials keeps your negotiated rates yours.

When should you integrate directly? If you only need one or two suppliers, or a supplier's special feature is core to your product.

Longer write-up with a decision table:
https://www.travelexe.com/one-hotel-api-vs-multiple-supplier-integrations/

DEV Community: Travelexe edge91