HOTELS
Bookable properties
The 2M+ deduplicated properties from the Hotels catalog, each carrying its canonical ID. A hotel result is not a pin with a phone number: it is the exact entity your booking flow consumes.
2M+ canonical entities
Type three letters. Get the hotel.
Typeahead, geo and landmark search, and entity resolution over 2M+ properties, cities, airports and POIs: travel-native, typo-tolerant, flat-priced. A standalone service that works in front of any booking stack, including one that never touches OnArrival.
Inventory
One index. Four entity types.
A hotel, a neighbourhood, an airport and a landmark are different things to a map. To a traveller they are all "where I want to stay". The index treats them that way.
GEO
Cities, areas, airports
Cities, neighbourhoods and every airport with scheduled service, with the containment geometry to answer "hotels in Shoreditch" differently from "hotels in London".
Neighbourhood-level precision
POI
Landmarks travellers use
"Near the Eiffel Tower", "walking distance from Bandra station": the anchors real hotel queries hang on, indexed with the geometry to rank results around them.
250k+ landmarks indexed
RESOLVE
Entity resolution
Free text, coordinates or a supplier’s own code in; one canonical, typed entity out. The cross-walk that lets a search result, a booking record and an analytics row agree on which hotel they mean.
Real-time + batch
How it works
Suggest, search, resolve.
Three endpoints. Suggest powers the search box with ranked, typo-tolerant completions per keystroke. Search takes a resolved entity or a landmark and returns bookable properties around it. Resolve turns free text, coordinates or foreign codes into one canonical entity. Every response carries the same typed IDs, whatever the query looked like.
GET /v1/places/suggest?q=grnd+hyat+dubay
200 OK
{ "suggestions": [ {
"type": "hotel",
"entity_id": "prop_9f2c81",
"name": "Grand Hyatt Dubai",
"city": "Dubai",
"bookable": true,
"score": 0.97 } ] }In depth
Generic places APIs stop where travel starts.
General-purpose places APIs were built to find restaurants and petrol stations. Travel queries are misspelt hotel names in another alphabet, and the right answer is a bookable entity, not a map pin.
01
Bookable entities, not POIs
Every hotel result carries the canonical property ID from our mapping pipeline, with geo, type and bookability attached. What comes back from the search box is the same entity a booking flow consumes, so there is no fragile name-matching step between search and checkout.
Results
02
One respectful comparison
Google Places is superb at general geography, and plenty of our customers keep it for exactly that. But ask it for "Grand Hyatt Dubai" and you get a point of interest: a pin, an address, a phone number. No canonical ID, no rooms, no notion of bookability. Travel needs search that ends in a booking.
Position
03
Misspelt, multilingual, still found
"Grnd Hyat Dubay" and the same hotel typed in Cyrillic, Arabic or Devanagari resolve to one property. Fuzzy matching and transliteration across 30+ query languages, tuned on real travel search behaviour rather than a generic spell-checker.
Queries
04
Landmark-anchored search
Travellers do not search by latitude. "Hotels near the Blue Mosque" and "close to Churchgate station" are first-class queries: 250k+ landmarks with walking-distance geometry decide what near means, and results rank by it.
Geo
05
Flat pricing, no session mathematics
Per-session billing punishes the exact behaviour a search box exists for: typing. Places Search is priced flat by monthly query volume. No session tokens, no per-keystroke charges, no rate limits that throttle autocomplete at peak.
Pricing
06
Standalone by design
This is an independent service, not a feature of our booking stack. Put it in front of any inventory: the resolution API cross-walks our canonical IDs to your own supplier codes, and nothing obliges you to book a single room through OnArrival.
Standalone
Capabilities
The Places Search surface
Who it's for
Where Places Search earns its keep.
OTA & meta
Travel sellers
Replace the generic places dependency in the box that starts every session: hotel matching that lands on the right property, landmark queries that convert, and a bill that stops scaling with keystrokes.
"The search box finally speaks hotel."
Fintech & super-apps
Embedded travel
A travel tab is only as good as its first input. Ship typeahead that understands travel from day one, without building a places index or negotiating a maps contract.
"Autocomplete shipped before the booking flow did."
AI agents
Agentic booking
LLMs produce place names, not IDs. The resolution endpoint turns "that hotel near the Trevi Fountain" into a canonical bookable entity an agent can act on in one call.
"Entity resolution grounds the whole agent."
Questions
Before you integrate Places Search.
Something we haven’t covered? Talk to the team. A real engineer answers, never a bot.
Is this a standalone product, or do I have to book through OnArrival?
How is this different from a generic places API?
What does the pricing model look like?
Which languages and scripts are supported?
Do the IDs match the rest of the OnArrival platform?
How fast is it, and are there rate limits?
Pairs well with
One product is rarely enough. Compose them.
Related reading
All field notes →Data and supply · 11 min
Pranav Upadhyay→Data and supply · 11 minPranav Upadhyay→
One hotel, five names: why catalogue size lies
Signing another hotel supplier grows the listing count on day one. Whether it grew the catalogue depends entirely on work nobody has scheduled yet: deciding which of those listings are hotels you already had.
Pranav Upadhyay→Data and supply · 11 minHow we solved room mapping
String similarity gets the two cases that matter exactly backwards: it merges the rooms that must never merge and splits the ones that must. This is the pipeline we built instead, stage by stage, including the part everyone tries to automate away.
Pranav Upadhyay→