Skip to content
Skip to main content
OnArrival

Any feed in. One canonical hotel.

The mapping engine behind our Hotels product, sold as an independent API. Send any supplier’s hotel and room feed; get back one canonical property and room identity with confidence scores attached. Book through us, or through anyone else entirely.

Illustration: a specialist in a blue cardigan at a bright desk merges two stacks of hotel record cards into one tidy tray, a wall of small labelled drawers behind and a warm desk lamp glowing
properties, mapped & deduplicated
2M+
duplicate rate, room-level mapped
<0.1%
of records resolve, no human touch
~97%
Inventory

Four kinds of feed. One identity.

The same property arrives from bedbanks, chains and channel managers under different names, IDs, room types and rate descriptions. Whatever the source, it leaves as one canonical record.

BEDBANK

Bedbanks & wholesalers

HotelBeds, WebBeds, TBO and RateHawk-class pools: high-volume feeds where the same independent hotel hides behind a dozen supplier codes and creative spellings.

Batch + streaming ingest
CHAIN

Chains & direct

Marriott, Accor, Hilton and IHG feeds carry the cleanest content in the graph. Chain-direct fields win the merge when sources disagree.

Authoritative content
CHANNEL

Channel managers & PMS

Room-type and rate-plan codes straight from the property’s own systems: the ground truth that anchors room mapping across the long tail of independents.

Property-level truth
YOURS

Your own supply

Direct contracts, extranet loads and static rate files run through the same pipeline as everything else, resolved against the same canonical graph and flagged as yours.

Same pipeline, your data
How it works

Resolve a feed in one call.

Post a supplier’s property and room payload; the response carries the canonical property ID, the mapped room type and rate plan, and a confidence score per match. High-confidence records resolve inline; the uncertain tail routes to a human-review queue and returns by webhook. Nothing about the call requires a booking, ever.

POST /v1/mapping/resolve
{ "supplier": "hotelbeds",
  "property": { "code": "HB-88121",
    "name": "Grand Hyatt - Dubai DXB" },
  "room": { "code": "DBL-GV-1",
    "name": "Garden Facing Standard" } }

200 OK
{ "property_id": "prop_9f2c81",
  "room_id": "room_51b7",
  "confidence": 0.98,
  "status": "resolved" }
In depth

Matching is easy. Being right is hard.

Fuzzy string matching gets you to 80% and a support queue full of wrong-room complaints. The last mile is signals, scores and a human tail, and that is the product.

01

Property matching

Every listing is reconciled to a canonical property ID using geo, address, phone and content signals. Three suppliers send "Grand Hyatt Dubai", "Hyatt Grand, Dubai" and "Grand Hyatt - Dubai DXB"; the API returns one ID for all three. Two million properties, continuously re-verified: under 0.1% ever surface twice.

Match
02

Room-type mapping

"Garden View Double", "Garden Facing Standard" and "Garden Twin" are the same physical room from three suppliers. We map at room level, parsing bedding, view, occupancy and size, so a booking made on one feed lands the room described on another.

Rooms
03

Rate-plan mapping

Board basis, refundability, payment timing and inclusions normalise into one plan schema, so "RO-FLEX-NET" and "Room Only, free cancellation" stop looking like different products and start competing on price.

Rates
04

Content merge

Descriptions, photos and amenities merge from the most authoritative source per field, onto a 300+ amenity taxonomy in 14 languages. Chain-direct descriptions beat bedbank stubs; high-res photos dedupe against thumbnails.

Content
05

Confidence scores, not guesses

Every match carries a score and the evidence behind it. You set the threshold per use case: auto-merge high for display, hold for review on anything that touches a booking. Nothing merges silently below your line.

Trust
06

A human queue for the tail

The roughly 3% the model cannot settle goes to a review queue worked by our supply team, with an SLA and a webhook when each record resolves. Every decision feeds the matcher, so the tail keeps shrinking.

Ops
Capabilities

The Mapping surface

Matching
  • Canonical property IDs
  • Geo + address + phone signals
  • Alias & rebrand tracking
  • Continuous re-verification
  • Dedupe across 30+ suppliers
Rooms & rates
  • Room-type mapping
  • Rate-plan normalisation
  • Board basis + occupancy
  • Bed configuration parsing
  • Cancellation policy normaliser
Content
  • 300+ amenity taxonomy
  • Multilingual descriptions
  • Photo dedupe + ranking
  • Most-authoritative field merge
  • Accessibility data
Integrate
  • Real-time lookup API
  • Batch file ingest
  • Per-field confidence thresholds
  • Review-queue webhooks
  • No booking dependency
The standalone case

This is the engine under our own hotels product, unbundled. Send us any feed, book through anyone you like, and the same hotel never shows up twice.

— the same graph that powers Hotels, sold on its own
Properties mapped2M+
Suppliers merged30+
Duplicate rate<0.1%
Who it's for

Where Mapping earns its keep.

OTA

Multi-supplier sellers

You aggregate bedbanks yourself and keep your own booking path. We settle which listings are the same hotel and which rooms are the same room, so your results page stops fighting itself.

"Double listings disappeared on the first sync."
Wholesale

Bedbanks & aggregators

Clean the catalog before your buyers see it: dedupe incoming hotel supply, normalise rooms and rate plans, and stop refunding stays that were mapped to the wrong room.

"Wrong-room refunds stopped being a line item."
Corporate

Booking tools & TMCs

Content from one system, negotiated rates from another, market rates from a third: resolve all of it to one property card so travellers compare rates, not spellings.

"One Hyatt per search, every rate beneath it."
Questions

Before you integrate Mapping.

Something we haven’t covered? Talk to the team. A real engineer answers, never a bot.

Illustration: a hotel concierge and a traveller study one clear floor plan together at a bright counter, a single room key resting beside it
Do I have to book through OnArrival to use this?

No. Mapping is a standalone service with its own API and contract. Send feeds, get canonical identities back, and book through any supplier, bedbank or switch you like. The API resolves identity; it never touches the booking.

How is this different from the mapping inside your Hotels product?

Same engine, different door. Hotels applies it invisibly to every search response. Mapping exposes it directly: your feeds in, canonical property and room identities out, whether or not you ever call our booking APIs.

How accurate is the matching, honestly?

Around 97% of records resolve automatically, every match carries a confidence score, and across the 2M+ property graph under 0.1% of listings ever surface twice. Below your chosen threshold nothing merges silently; it holds for review instead.

What happens to records the engine cannot settle?

They route to a human-review queue worked by our supply team. Each decision returns by webhook and feeds the matcher, so the same ambiguity does not come back next quarter.

How do I send you a supplier feed?

Two paths: batch ingest for full catalog files (CSV, JSON or the supplier’s native export) and a real-time lookup API for resolving records at search or import time. New suppliers onboard as configuration, not code.

Can I map my own direct contracts and private supply?

Yes. Direct contracts, extranet loads and static rate files run through the same pipeline, resolve against the same canonical graph and stay flagged as yours in every response.

Pairs well with

One product is rarely enough. Compose them.

Related reading

All field notes →
Start building
Wire Hotel & Room Mapping into your stack with a sandbox key.