TripAdvisor Photos Scraper

What does TripAdvisor Photos Scraper do?

TripAdvisor Photos Scraper takes one or more TripAdvisor listing ids (hotel, restaurant, or attraction) and pushes the full photo gallery for each — real image URLs at multiple sizes, captions, upload dates, and uploader attribution — one dataset row per listing.

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. This is the photo-gallery slice of TripAdvisor All-in-One API, split out as its own focused Actor.

Why use TripAdvisor Photos Scraper?

• Genuinely paginates the full gallery, not a first-page cap — confirmed live: paging by offset returns real, non-overlapping photo windows all the way through a 1000+ photo hotel gallery
• One vertical, one code path — hotels, restaurants, and attractions are all identified the same way (a plain content id), so the same endpoint serves every listing type
• Multiple real sizes per photo — every item carries both a sizes array (thumbnail through large) and a dynamic urlTemplate you can request any width/height from
• No account needed — every request works fully anonymously
• Use cases: listing enrichment, image datasets for ML, photo-freshness monitoring, travel content aggregation

Input

Field	Type	Description
listingIds	string[]	Required. Plain numeric TripAdvisor content ids (hotel, restaurant, or attraction) — e.g. from tripadvisor-all-in-one-api or a TripAdvisor URL.
currency	string	ISO code, default GBP. Doesn't affect photos, only kept for API-call consistency with the parent.
maxPhotos	integer	Stop once this many photos have been collected for a listing. Leave empty to fetch the whole gallery.
pageSize	integer, default 50	Not sent to the API — TripAdvisor's gallery endpoint always returns up to 50 items per call regardless of any client-requested size (confirmed live). Used only to detect the last page: a response with fewer items than this means the gallery is exhausted.

Example:

{
    "listingIds": ["25246100"],
    "maxPhotos": 20
}

Output

One dataset row per listing id:

{
    "listingId": "25246100",
    "photos": [
        {
            "id": 667714552,
            "caption": "",
            "publishedDateTime": "2023-01-12T12:40:45.522Z",
            "uploadDateTime": "2023-01-12T12:40:45.522Z",
            "thumbsUpVotes": 34,
            "attribution": "Photo provided by management",
            "urlTemplate": "https://dynamic-media-cdn.tripadvisor.com/media/photo-o/27/cc/83/f8/villa-deva-resort-and.jpg?w={width}&h={height}&s=1",
            "maxWidth": 1999,
            "maxHeight": 1333,
            "sizes": [
                {
                    "width": 50,
                    "height": 50,
                    "url": "https://media-cdn.tripadvisor.com/media/photo-t/27/cc/83/f8/villa-deva-resort-and.jpg"
                },
                {
                    "width": 1280,
                    "height": 854,
                    "url": "https://media-cdn.tripadvisor.com/media/photo-m/1280/27/cc/83/f8/villa-deva-resort-and.jpg"
                }
            ]
        }
    ]
}

urlTemplate accepts arbitrary {width}/{height} values (e.g. ?w=1600&h=1200&s=1) for a size not already covered by sizes.

Data notes

Confirmed live against a real hotel gallery (id 25246100, 1188 total photos):

• The raw MediaGalleryQuery response's sections array is a mix of UI blocks: an AppPresentation_AlbumsSection (album/category chrome — "All photos", "Traveller", "Hotel & Amenities", etc. with per-album counts), the actual AppPresentation_MediaPageSection (the flat, unfiltered photo stream this Actor extracts from its mediaList), and an AppPresentation_SecondaryButton ("see all" link). Only the middle one carries discrete photo items.
• offset is a literal start index, not a page number. A call with offset=30 returns items starting at position 30 of the same underlying stream a call with offset=0 would return — confirmed by an exact 20-item overlap between an offset=0/50-item response and an offset=30 response (items 30-49 of the first call equal items 0-19 of the second).
• The response window is fixed at 50 items per call, with no way to request a different size — there's no size/limit parameter on the endpoint, only offset. This Actor pages by incrementing offset by however many items the previous call actually returned, and stops when a call returns fewer than 50 (or zero).
• Every item observed was a photo (AppPresentation_MediaPageItemPhoto / Media_PhotoResult) — no video items appeared in the sampled gallery, but the extractor only picks items from the photo-shaped mediaList, so a video-only item (if TripAdvisor ever serves one there) is silently skipped rather than crashing the run.

Known limitations

• No album/category filtering. This Actor pulls the flat "all photos" stream only — per-album breakdowns (e.g. just "Pool & Beach") aren't wrapped; that data is visible in AppPresentation_AlbumsSection but not currently exposed by this Actor.
• This is an unofficial, reverse-engineered integration, not affiliated with or endorsed by Tripadvisor LLC. Behavior may change if TripAdvisor changes its API.

Pricing

Pay per event: $0.001 per photo — charged once for each photo returned in a listing's gallery (Free plan price; lower on paid Apify plans). See the Actor's Pricing tab for current tiered rates.