TripAdvisor Attractions, Hotels, and Restaurants: One API for Travel Research

Most listing sources give you one endpoint per platform. TripAdvisor doesn't — attractions, hotels, and restaurants are three separate endpoints with three separate field sets, because a restaurant's cuisines and a hotel's hotelClass don't mean anything on the other record type. Pull only one and you get a partial picture of a destination; a museum, a boutique hotel, and a tasting-menu restaurant each live in a different endpoint entirely.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What does each category endpoint actually return?

All three share the same input shape — a query (location or keyword) or a startUrls list — and the same $0.002-per-record price. What differs is the field set, because each category has fields the others don't:

• Attractions (24 fields) is the only one with bookingUrl, lowestTicketPrice, and ticketOffers — direct Viator booking links and prices, not just a listing.
• Hotels (28 fields) is the only one with hotelClass, rooms, priceRange, amenities, and hotelOffers — and the only one that takes checkInDate/checkOutDate as inputs to get live room pricing rather than a static listing.
• Restaurants (34 fields) is the richest of the three: cuisines, popularDishes, mealTypes, dietaryRestrictions, openingHours, menuUrl, orderOnline, and a closed flag none of the other two have.

All three also return rank and rankOutOf — a place's position within its own category in that destination, not a global score. A restaurant ranked 12 out of 800 in Rome and a hotel ranked 12 out of 300 in Rome are both real signals, but they're not comparable to each other.

How do you pull all three categories for one destination?

Say you're building a destination guide for Kyoto — attractions, hotels, and restaurants in one pass. It's three calls, same query, different endpoint:

curl -X POST "https://api.mindcase.co/v1/data/tripadvisor/attractions/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "query": "Kyoto",
    "maxResults": 20
  }
}'

# $0.002 per attraction

How do you get hotels for the same destination?

Same query, same shape, tripadvisor/hotels instead — add checkInDate/checkOutDate if you want live room pricing and offers rather than a static listing:

curl -X POST "https://api.mindcase.co/v1/data/tripadvisor/hotels/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "query": "Kyoto",
    "maxResults": 20,
    "checkInDate": "2026-12-20",
    "checkOutDate": "2026-12-23"
  }
}'

# $0.002 per hotel

How do you get restaurants for the same destination?

Same shape again, tripadvisor/restaurants — the richest of the three endpoints, with cuisines, popularDishes, and dietaryRestrictions that don't exist on the other two:

curl -X POST "https://api.mindcase.co/v1/data/tripadvisor/restaurants/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "query": "Kyoto",
    "maxResults": 20
  }
}'

# $0.002 per restaurant

Three calls, 60 records, $0.12 total — a destination guide covering things to do, where to stay, and where to eat, each with its own category-specific fields intact.

How do you use rank without it being misleading?

rank/rankOutOf is a within-category position, so the useful move is comparing it against the field that actually explains it, not quoting it alone. A restaurant ranked 4th out of 900 with a priceLevel of $$$$ and a hotel ranked 4th out of 300 with a hotelClass of 3 are both real top-tier results in their own category — pairing rank with cuisines, hotelClass, or attractionTypes before presenting it keeps a raw number from reading as more comparable than it is.

What can't you get from Mindcase?

Two cases.

Live room availability isn't guaranteed. checkInDate/checkOutDate on the hotels endpoint return hotelOffers and pricing TripAdvisor is showing at request time — a snapshot, not a live booking hold. A property can sell out between your call and a traveler trying to book it.

Search coverage depends on query matching a real TripAdvisor destination. A city name typically resolves cleanly; an ambiguous or very small locality might return a narrower result set than a broader regional search would, since the endpoint is matching against TripAdvisor's own destination index, not doing geographic inference.

Which endpoint should you use for which job?

FAQ