Hotel Mapping API

Every OTA gives the same hotel a different name and ID.

Map a hotel name to its canonical page on Booking, Agoda, Expedia, TripAdvisor, Priceline, Trip.com and others — discover every link a property has, geocode any place, and turn matched pages into IDs you can pull rates, reviews and photos with.

REQUEST GET
USE CASE Resolve a hotel name to its canonical page on one OTA — here, Booking.com.
curl "https://api.stayapi.com/v1/meta/match" \
  -G \
  -H "x-api-key: $STAYAPI_KEY" \
  -d "name=conrad tokyo" \
  -d "platform=booking"
RESPONSE 200 OK
1.4s
{
  "success": true,
  "query": {
    "name":     "conrad tokyo",
    "platform": "booking"
  },
  "match": {
    "title": "Conrad Tokyo",
    "url":   "https://www.booking.com/hotel/jp/conrad-tokyo.html"
  }
}
6+ OTA match targets ✓ URL → ID converters 50 free requests

Trusted by teams at

The identity problem

Hotel data joins break on identity. We match them back together.

Four names, one building.

Legal names, trade names, rebrands, diacritics, transliterations. "Hôtel Le Grand" on one OTA is "Le Grand Hotel Paris" on the next — and a fuzzy string compare calls them different properties.

IDs never line up.

Booking's 123456 has nothing to do with Expedia's 78901234, and an ID that means one hotel on one OTA can mean a different hotel on another. Without namespacing, collisions are silent.

Bad joins make bad analytics.

Rate comparisons against the wrong property. Review rollups mixing two hotels. Every downstream number inherits the identity error, and nobody notices until a customer does.

Manual reconciliation doesn't scale.

Onboarding a new supplier or portfolio means someone eyeballing spreadsheets, property by property. Fine at 50 hotels. A quarter of lost weekends at 5,000.

The toolkit

Match, discover, geocode — then pull the data.

Match: name → canonical page.

Give /v1/meta/match a hotel name and a platform; get the canonical hotel page back, validated against strict URL patterns and cleaned of SEO noise.

Discover: every link at once.

One /v1/meta/search call fans out across the major OTAs, the big chains — and the property's own official website.

Geocode: text → coordinates.

City, neighborhood or landmark into /v1/meta/coordinates-lookup; name, type, country and lat/lng out — ready for StayAPI's geo-search endpoints.

Convert: URL → native ID.

Booking, Agoda and VRBO converters turn a matched URL into the platform's own ID — the key that unlocks rates, reviews, rooms and photos on every data endpoint.

From mess to matched

Messy names in. Matched links out.

Feed the match endpoints the names you already have — PMS exports, supplier CSVs, CRM records. Back comes the canonical page per OTA, cleaned and validated. No confident match? An explicit no-match, never a guess.

BEFORE — supplier_export.csv
id_204;CONRAD TOKYO HOTEL;;JP
bkg-1199553;Conrad Tokyo;booking;JP
EXP_90482;CONRAD TOKYO (SHIODOME);expedia;
ta_d508158;Conrad Tokyo Hotel;tripadvisor;JP
id_982;Conrad, Tokyo Shiodome;;JP
agd_44720;Conrad Tokyo, Minato;agoda;JP
id_413;コンラッド東京;Minato-ku;JP
id_764;Conrad Tokyo (ex. Shiodome);;JP
AFTER — one property, matched MATCHED
{
  "name": "Conrad Tokyo",
  "links": {
    "booking_com":      "…/hotel/jp/conrad-tokyo.html",
    "expedia":          "…h1199553",
    "tripadvisor":      "…d508158",
    "agoda":            "…/conrad-tokyo/hotel/tokyo-jp.html",
    "official_website": "hilton.com/…conrad-tokyo/"
  }
}
Into your stack

Put it where your team works.

✓ SHEETS  ✓ BI  ✓ CRM

Plain JSON pipes anywhere.

Matched links and IDs are plain JSON — pipe them into Google Sheets, BigQuery, Power BI, Snowflake, Postgres or straight into the property records of your CRM. REST in, any language out.

  • Enrich existing rows instead of rebuilding your property table
  • Stable schema — the same fields on every call
  • Pair with StayAPI data endpoints to fill rates and reviews next to the links
Sheets
BigQuery
Power BI
Snowflake
Postgres
Your CRM

Trusted by teams at

Questions

Things developers ask before signing up.

Don't see your question? Email info@stayapi.com.

Which platforms can you match against?

Name-to-URL matching covers Booking.com, Agoda, TripAdvisor, Expedia, Priceline, Trip.com and others. Link discovery casts a wider net — Hotels.com, Kayak, Marriott, Hilton, IHG, Hyatt and the property's own website.

How does the matching actually work?

We resolve the hotel name against each OTA's public pages, then validate the result against strict per-platform URL patterns — a Booking match must be a real Booking hotel page, not a city landing page or a blog post. Titles are cleaned of SEO noise before they come back to you.

What happens when there's no confident match?

You get an explicit no-match response, not a guess. A wrong mapping silently poisons every downstream join — we'd rather tell you we don't know.

Can I turn a matched URL into rates and reviews?

That's the point. Feed a matched Booking or Agoda URL into the URL-to-ID converters, then use the ID with any StayAPI data endpoint — details, reviews, rooms, photos, prices. One key, one schema, end to end.

Can you map an entire inventory, not one hotel at a time?

The API is self-serve at any volume. For bigger projects — large inventories, custom crosswalks, ongoing feeds — book a call and we'll scope the right setup together.

How does pricing work?

Mapping calls use the same per-request credits as every other StayAPI endpoint. Keys land in your account on signup, with free requests to start. Volume pricing for large inventories is quoted on a call.

Two ways to start.
Both end with your inventory matched.

Pick the path that matches what you're shipping.

01 · For developers

Keys in your account in 30 seconds.

Create an account and your API keys are ready immediately, with free requests to test. Everything else is in the docs.

Sign up, get keys
02 · Bigger project?

Let's talk it through.

Large inventory, custom crosswalks, an ongoing feed — if it's more than a few calls a day, we'll scope the right setup together.