TripAdvisor All-in-One API

What does TripAdvisor All-in-One API do?

TripAdvisor All-in-One API is a REST endpoint for live TripAdvisor data — destination search, hotels, restaurants, attractions/things-to-do, paginated reviews with rating filters, and photo galleries. All from a single always-on API powered by Apify Standby.

It talks directly to the same internal API the official TripAdvisor Android app uses, reverse-engineered by capturing live traffic from a real device. Unlike many reverse-engineered mobile APIs, TripAdvisor needs no per-request signature at all — just a static API key and self-generated device/session ids, confirmed live and standalone-reproducible. No TripAdvisor account, no API key of your own — call the endpoint, get JSON back.

Why use TripAdvisor All-in-One API?

• One search, three verticals — hotels, restaurants, and attractions are all served by the exact same underlying operations (confirmed live by replaying with each content type and getting real, distinct results) — consistent behavior across every listing type, not three different quirky endpoints
• Real filters that genuinely work — price range, amenities, minimum rating, sort — confirmed live: a price=[150,190] filter returned only hotels priced £157-£179, not an ignored parameter
• The filter schema comes free — every search response's filters.availableFilterGroups field carries the live id+label options for that exact query, no separate schema call needed
• Real paginated reviews, not a 20-item cap — confirmed live end-to-end: page 2 returns 20 genuinely new reviews with zero overlap with page 1, using TripAdvisor's own real (non-trivial) pagination cursor, wrapped so you don't have to reverse-engineer it yourself
• Always-on — Standby mode means no cold start, responds in milliseconds
• No account needed — every endpoint works fully anonymously
• Use cases: travel content aggregation, price/rating monitoring, review analysis, destination research bots

Endpoints

Method	Path	Description
GET	/search	Destination/POI autocomplete
GET	/home	Home tab feed
GET	/hotels	Hotel search for a destination
GET	/hotels/{id}	Full hotel detail
GET	/hotels/{id}/reviews	Paginated hotel reviews
GET	/restaurants	Restaurant search for a destination
GET	/restaurants/{id}	Full restaurant detail
GET	/restaurants/{id}/reviews	Paginated restaurant reviews
GET	/attractions	Attraction/things-to-do search for a destination
GET	/attractions/{id}	Full attraction detail
GET	/attractions/{id}/reviews	Paginated attraction reviews
GET	/listings/{id}/photos	Photo gallery for any listing

How to use TripAdvisor All-in-One API

1. Open this Actor's Standby API URL (shown on the Actor's page, under the API tab).
2. Call any endpoint — for example:

   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/search?query=Bangkok"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/home"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/hotels?geo_id=293916"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/hotels?geo_id=293916&price_min=50&price_max=200&sort=PRICE_LOW_TO_HIGH"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/hotels/25246100"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/hotels/25246100/reviews?min_rating=5"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/restaurants?geo_id=293916"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/attractions?geo_id=293916"
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/listings/25246100/photos"
   # Pagination: pass the previous response's next_page_token back as page_token
   curl "https://romy--tripadvisor-all-in-one-api.apify.actor/hotels/25246100/reviews?page_token=<token from previous response>"
   

   Every call needs your Apify API token, either as Authorization: Bearer <token> or ?token=<token> — the Actor's page API tab has a ready-to-copy version with your token filled in.
3. Read the JSON response — no setup required.

Parameters

GET /search — query required (free-text destination name). currency optional, default GBP.

GET /home — no required parameters. currency optional.

GET /hotels, GET /restaurants, GET /attractions — geo_id required (from /search).

Param	Type	Example	Meaning
geo_id	string	293916	From /search
price_min	int	50	Minimum nightly price — confirmed live to genuinely filter (hotels/restaurants only)
price_max	int	200	Maximum nightly price
amenities	comma-separated string	9176	Amenity tag ids — confirmed live as a real filter (hotels only). Get ids from a prior response's filters.availableFilterGroups
min_rating	string	4	Minimum star rating, confirmed live values "1"-"5"
sort	string	PRICE_LOW_TO_HIGH	Confirmed live values: BEST_VALUE, PRICE_LOW_TO_HIGH
currency	string, default GBP	USD	Confirmed live to change returned prices

GET /hotels/{id}, GET /restaurants/{id}, GET /attractions/{id} — id required (a content id from the matching search endpoint). currency optional.

GET /hotels/{id}/reviews, GET /restaurants/{id}/reviews, GET /attractions/{id}/reviews — id required.

Param	Type	Example	Meaning
min_rating	string	5	Filter to one star rating
page_token	string		next_page_token from a previous response — omit for page 1
currency	string, default GBP	USD

GET /listings/{id}/photos — id required (any hotel/restaurant/attraction content id). offset optional (default 0).

Output

{
    "success": true,
    "hotel": {
        "AppPresentation_queryAppDetailV2": [{
            "container": { "navTitle": "Villa Deva Resort & Hotel Bangkok" }
        }]
    }
}

Reviews responses include a next_page_token alongside the review data:

{
    "success": true,
    "reviews": { "AppPresentation_queryPoiReviews": { "sections": [ "..." ] } },
    "next_page_token": "eyJ1cGRhdGVUb2tlbiI6Ii4uLiIsInBhZ2VlIjoyMH0"
}

Data notes

• No request signing exists at all — confirmed by capturing the real app's traffic and finding just static identity headers (no per-request signature or hash) that aren't validated against any server-side registry (confirmed: a freshly generated device identity works immediately). Verified fully standalone-reproducible — no device or live app session needed at runtime.
• One internal API endpoint, persisted queries. Every request goes to a single internal endpoint, distinguished by an operation name plus a fixed persisted-query hash instead of a full query string — confirmed live that these hashes are reusable across devices/sessions.
• List, detail, and reviews are genuinely generic across hotel/restaurant/attraction — confirmed live by replaying the exact same underlying operation with each content-type value and getting back real, distinct results every time, not guessed.
• Detail is richer than list-screen prefetching. The app's list screens batch-prefetch 4 items at once into a lighter ~100-130KB payload; /hotels/{id} etc. use the single-item call the app's own detail screen makes instead, up to ~265KB for one hotel.
• Review pagination is genuinely non-trivial, and this Actor handles it for you. Confirmed live: a raw page-number/offset parameter alone silently re-returns page 1 — real pagination requires threading an opaque continuation cursor from the previous response back into the next request, alongside an internal page-depth counter. This Actor extracts and re-encodes that state into one opaque next_page_token/page_token pair so callers don't need to reverse-engineer it themselves. Verified end-to-end: page 2 returned 20 genuinely new review ids with zero overlap with page 1.
• currency changes real prices, not just a symbol — the same behavior pattern discovered in this developer's Klook All-in-One API. Not part of any request signature (there isn't one here), so any ISO code is always safe to pass.

Pricing

Pay-per-event, billed on each successful call. See the Actor's Pricing tab for current rates.

Known limitations

• Hotel/restaurant/attraction list pagination beyond the first page isn't fully wrapped yet. The update_token query param on /hotels, /restaurants, /attractions is exposed but requires the caller to already understand TripAdvisor's own opaque list-pagination cursor format — unlike the reviews endpoints, this Actor doesn't yet re-encode it into a clean next_page_token. Noted here rather than silently left half-working; likely a fast follow-up given the reviews endpoint's pagination wrapper already solves the same underlying problem shape.
• This Actor only wraps guest-accessible endpoints. No login flow is implemented or planned — features requiring a real TripAdvisor account (saved trips, writing reviews, booking) are out of scope by design.
• DataDome telemetry is present but doesn't block data — the app calls a device-check telemetry SDK alongside its real requests, but every data endpoint this Actor wraps returns real content regardless (unlike this developer's Klook All-in-One API, where DataDome genuinely blocks several endpoints).
• This is an unofficial, reverse-engineered integration, not affiliated with or endorsed by Tripadvisor LLC. Behavior may change if TripAdvisor changes its API.

Found a bug or have a feature request? Use the Issues tab on this Actor's page.