TripAdvisor API: Pull Hotels, Ratings and Reviews for a Whole City

Get TripAdvisor hotels, ratings and reviews for a whole city in one prompt. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to pull the first three pages of hotels in Kyoto from TripAdvisor, drop anything that is not accommodation, sort by rating, and give me a table with name, rating, review count and link.

One prompt pulls a whole city. 1 min setup · 30-60 hrs saved.

You want hotels, ratings and reviews for a city, or a dozen cities, in one table: for a travel product, a pricing study, or a client shortlist. This guide shows the quickest way to get TripAdvisor data into your agent or your spreadsheet, what each record contains (we tested it live on 2026-10-16), and two traps we hit: a result order that is not the rating, and an attraction inside a hotel search. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to get TripAdvisor hotel data through an API?

Monid. Install it once, add a key, and your agent calls TripAdvisor search, place details and reviews with no portal, no plan and no vendor account to set up.

• Pay per call. Each call is billed on its own, at $0.00015 for the TripAdvisor search, place and reviews endpoints (Verified 2026-10-16 on the local data tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and the same balance call TripAdvisor and every other tool on Monid. No new account for Yelp, Google or Zillow when you need them next. Building and wiring those yourself is the 30 to 60 hours this page claims to save.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tools are there whenever your agent needs them, on demand, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

At that price the hotel list for a whole city, 67 calls, costs about $0.01 (Verified 2026-10-16).

How do you get the hotels of a whole city at once?

Run one search per page and follow the next call the response hands you, then loop it over your cities. Relying on one source per city is the trap why one Google Maps scraper is not enough describes for maps data, and the same logic applies here.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Search with the type pinned

monid run -p litescrape -e /tripadvisor/search \
  --query '{"q":"hotels in Kyoto","locale":"en-US","place_type":"accommodation"}'

Pinning the type up front is cheaper than filtering afterwards, because you are billed per call and a call full of attractions is a wasted one.

Read the counts before you loop

const { total_results, results_on_page } = res.search_information;
const pages = Math.ceil(total_results / results_on_page);  // 67 for Kyoto

Decide whether you want all 67 before you start. For most jobs the first two pages answer the question.

Follow the supplied next call

The response hands you a ready-made pagination.next with the endpoint and parameters filled in. Send it rather than building your own offset, which is one fewer thing to get wrong when the page size changes.

Loop it over your cities

Put one city per line in cities.txt, then run (the same sweep-by-city pattern is in automating Google Maps business listings):

mkdir -p out
while read -r city; do
  monid run -p litescrape -e /tripadvisor/search \
    --query "{\"q\":\"hotels in $city\",\"locale\":\"en-US\",\"place_type\":\"accommodation\"}" > "out/$(echo "$city" | tr ' ' '_').json"
done < cities.txt

Each city writes one file with its first page. Follow pagination.next in each file only for the cities where the first page is not enough.

Or hand the whole job to an agent

Can you scrape TripAdvisor yourself with Python?

Yes, people do it with BeautifulSoup, Selenium or Playwright, and it works until the page changes. A scraper you write is yours to keep alive: when the markup or the blocking changes, your job breaks, and your list of cities is only as fresh as your last successful run.

There is a rules side too: read Tripadvisor's terms before you build anything, because what you may do depends on where you operate and how you use the data.

Doing it in Python means a proxy or browser setup, parsing code, retries and paging logic, and a repair every time the page changes. Setting that up takes hours before the first useful row. A call costs $0.00015 (Verified 2026-10-16). Set against hours of your own time, the choice is easy: pick Monid for anything you will run more than once. The collection is maintained for you, the output is typed JSON instead of HTML you parse, and a city is about $0.01. If you want to see the DIY route first, Python web scraping without a scraper shows where it stops being worth it. A downloadable dataset is quicker for a one-off look, but it is a snapshot of one date for the places its author chose.

What can you pull from TripAdvisor, and what does each record contain?

Three kinds of record, chained by place_id: the search row, the place, and its reviews. We ran all three on 2026-10-16 against the Four Seasons Hotel Kyoto, so the fields below are what came back, not what a spec promises.

The search row

Search returns a typed row per property. The fields we saw, trimmed:

{ "position": 1,
  "place_id": "10532611",
  "title": "Four Seasons Hotel Kyoto",
  "location": "Kyoto, Kyoto Prefecture, Japan",
  "type": "ACCOMMODATION",
  "detail_type": "Hotel",
  "rating": 4.5,
  "max_rating": 5,
  "reviews": 1065,
  "snippet": "…",
  "mention_count": 302,
  "link": "…",
  "place_api_link": { "endpoint": "/tripadvisor/place", "queryParams": { "place_id": "10532611" } },
  "reviews_api_link": { "endpoint": "/tripadvisor/reviews", "queryParams": { "place_id": "10532611" } } }

type and detail_type are the typed classification. place_id is the key you carry forward. reviews is the review count behind the rating, and the row even includes the ready-made next calls for the place and its reviews.

The query takes q (free text up to 500 characters, the only required field), locale, tripadvisor_domain, geo_id to stay inside one geography, lat plus lon to search around a point, place_type, and num (1 to 30) and start to page.

The place

One call per property returns the profile: rating, review count, the geography id, GPS coordinates and the long description. Prices are requested in the currency you choose, and the endpoint lists amenities, ranking and contacts as things it can return. For the Four Seasons Kyoto it returned the profile and coordinates but no amenities or prices, so check the properties you care about before you build on those fields.

The reviews

The reviews endpoint returns the text, not just the score. Each review had a title, text, rating, publish date, language, the reviewer's country and contribution count, trip type (couples, solo and so on), helpful votes, photos with captions, and the hotel's owner response when there was one. You can sort by recent or relevance, translate into your locale, and take up to 50 per call. The total matched the hotel's review count, 1,065, so a full export of that hotel is 22 calls.

What you can build with it

• A hotel shortlist sorted by what you mean. Rating and review count are on every row, so a client shortlist is one sort away.
• A competitor set for each city. Pull the same search every month and compare ratings and positions over time.
• A sentiment read on a property. Pull its reviews, group by trip type and country, and read what couples say against what solo travellers say.

What goes wrong when you pull TripAdvisor data at scale?

Four things hide until you run more than one city. The first two came out of our Kyoto search on 2026-10-02.

Why is the default order not the ranking you want?

Almost certainly it is not, and the ratings make it obvious.

rank  rating  hotel
  1    4.5    Four Seasons Hotel Kyoto
  2    4.4    Hotel Granvia Kyoto
  3    4.4    Hotel Okura Kyoto
  4    4.2    Kyoto Century Hotel
  5    4.6    Hotel Kanra Kyoto
  8    4.7    The Ritz-Carlton, Kyoto

The highest-rated hotel in the top eight is at rank 8. The fourth-ranked has the lowest rating on the page. The order is TripAdvisor's own relevance and popularity blend, and the endpoint passes it through without re-sorting. If you present the first ten rows as "the best hotels in Kyoto", you have published TripAdvisor's relevance ranking under your own name and called it quality.

Sort client-side on the field you mean. Rating was present on every row, so this costs nothing:

rows.sort((a, b) => b.rating - a.rating);

Why did a hotel search return an attraction?

Because free text is a search, not a filter. In our thirty rows:

29   ACCOMMODATION / Hotel
 1   ATTRACTION / Attraction

We asked for "hotels in Kyoto" and got one attraction. This is the good failure mode: the row says type: "ATTRACTION" and you drop it in one line, or you set place_type to accommodation on the way in, which stops you being billed for rows you throw away. The three rows we pulled with that filter on 2026-10-16 were all ACCOMMODATION.

const hotels = rows.filter(r => r.type === "ACCOMMODATION");

A typed field in the response is worth more than a better query string.

Why does a rating alone mislead?

A 5.0 from three guests and a 4.5 from 1,065 are not comparable. The row carries the count in reviews, so use it: drop properties under a minimum, or weight the rating by the count, before you rank. On 2026-10-16 the Four Seasons showed 4.5 on 1,065 reviews and the Granvia 4.4 on 3,840, which is a different story from the two ratings side by side.

How many calls is a whole city?

67, for 2,000 results at 30 a page, before any follow-up. Ten cities is 670 calls for the listings alone, about $0.10 at $0.00015 a call (Verified 2026-10-16). Narrow by geo_id or by coordinates, or accept the first two pages, which is usually what the question deserves.

Which endpoint should I use for which job?

The TripAdvisor rows were inspected on 2026-10-16 and the latency is the endpoint's typical (median) run time; the other rows were verified with monid inspect on 2026-10-02. Billing shape is given here, and the current figure is on monid.ai/tools.

For the Yelp row, how the Yelp business search works has the full input and output. The TripAdvisor and Yelp rows cover overlapping ground and answer different questions. TripAdvisor knows travel entities as a traveller sees them, with the ratings of people who travelled there. Yelp knows local businesses as a resident sees them. For a hotel, use the first. For the coffee shop next to it, use the second. place_id from one will not match the other, so keep them in separate columns.

When is another route a better fit?

You need live prices or availability. This is a discovery surface. Rates, dates and inventory come from a booking system, and the rows will not tell you whether a room is free tonight.

You are sweeping many cities. 67 calls for one city's hotels, before any follow-up. If you only need a shortlist per city, take the first page; if you need every property, budget the calls first.

You need amenities or contacts for every property. The place endpoint lists them as fields it can return, but they were absent for the property we tested, so sample your own set first.

You are republishing the ratings as your own. A rating is TripAdvisor's aggregate of their users' writing. Using it internally to rank candidates is ordinary. Presenting it on your own site as your score, or stripping the attribution, is a different act and one their terms have opinions about.

And the disclosure: we resell these endpoints. The most useful thing in this post is that you should re-sort and weight the results yourself, which costs nothing and is a one-line fix whoever you buy the data from.

Conclusion

The quickest way to get TripAdvisor hotels, ratings and reviews for a whole city is one search call per page through Monid: $0.00015 a call (Verified 2026-10-16), one key for TripAdvisor and everything else, about a minute to set up and ready inside your agent whenever you need it, and a city's hotel list for about $0.01. Scraping it yourself works until the page changes, and costs hours of setup; Monid keeps the collection maintained.

Two traps cost us time. The list came back in TripAdvisor's relevance order, not by rating: the highest-rated property in the top eight sat at rank 8, so sort on the field you mean and weight by the reviews count. And a hotel search returned one attraction among 29 hotels: filter on type, or set place_type on the way in.

How we estimated the time saved: building and running your own TripAdvisor hotel scraper is roughly 10 to 20 hours each for getting past blocking, parsing typed rows with paging, and the first month of upkeep. That is 30 to 60 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p litescrape -e /tripadvisor/search, make one call, and print type, rating and reviews next to the position. The mismatches show up immediately. Start at monid.ai.

FAQ

Published October 2026.