Version 1 Release Notes

Release notes highlight improvement across the Tripadvisor Terra platform. Releases typically are made to all versions unless explicitly mentioned.

June 2026

New: locale query parameter for factual endpoints

All factual-content endpoints now accept an optional locale query parameter, giving you explicit control over which locale translations are returned for names, descriptions, addresses, and other display-layer content.

• Default value: en-US when no locale parameter is supplied, US English translations are returned.
• Supported values: Any valid locale code from the supported locales list (e.g. en-US, es-MX, fr-FR, pt-BR, ja-JP, zh-TW, etc.).
• Multiple locales: Pass the parameter multiple times to request content in several locales simultaneously (e.g. ?locale=es-MX&locale=fr-FR). The response includes translations for each requested locale where available.
• Fallback chain: When content is not available for a requested locale, the system walks a fallback chain based on locale relationships (e.g. es-AR falls back to es-MX, then es, then en-US). The language field on each translation object indicates which locale was actually resolved.
• Validation: Invalid or unsupported locale codes return 400 Bad Request with a response body listing all supported locale codes.

📘

The default locale for API responses is now en-US for all partners. If you previously received non-English factual content by default, pass the locale parameter to continue receiving content in your preferred locale. Feed delivery languages are unaffected.

Affected endpoints:

What the locale parameter affects:

The locale parameter controls two types of translated content:

For a full explanation of the locale system including the fallback chain, supported codes, and how locale differs between API and feeds, see the Locales guide.

May 2026

New: language query parameter for Reviews endpoint

The GET /locations/{id}/reviews endpoint now accepts an optional language query parameter, giving you explicit control over which language translations are returned in review content (titles, texts).

Key details:

• Default value: en — when no language parameter is supplied, English translations are returned.
• Supported values: Any valid language code (en, es, fr, pt, ja, zh-CN, zh-TW, etc.) — see Supported Languages for the full list.
• Special keyword primary: Pass language=primary to receive reviews in their originally-authored language only (no machine translations). This is useful for NLP, sentiment analysis, or displaying reviews exactly as the traveler wrote them.
• Validation: Invalid language codes return 400 Bad Request.

📘

The default language for API responses is now en for all partners. If you previously received non-English reviews by default, pass the language parameter to continue receiving reviews in your preferred language. Feed delivery languages are unaffected.

Improvement: Review pool consistency

The reviews endpoint now uses a review pool, a fixed base set of your most recent reviews for a location. Filters you apply (language, rating_atleast, trip_type) narrow results from this pool, but never change which reviews are in it.

What changed:

Previously, filters could influence which reviews were considered in the first place, meaning the same location could return very different results depending on which filters were applied. This made responses harder to predict.

Now, the review pool is always consistent: your most recent reviews for a location, regardless of filters, giving you a stable foundation to filter against. All filters apply after the pool is formed, so combined filters may yield fewer results than your review limit per location.

Why: This change improves predictability. You always draw from the same base set of reviews, with filters narrowing results consistently and transparently.

📘

This behavior applies consistently across both API responses and feed delivery.

February 2026

New Catalog Search endpoints

• GET /catalog/locations/search – Search the location catalog by name or address (with optional filters like country, geo, postal code, category). Returns a limited catalog payload (id, names, addresses, coordinates, rating, URLs).
• GET /catalog/locations/nearby – Get locations in a geographic area: by radius around a location or lat/lon, or by bounding box. Same catalog-style response; supports category filter, min rating, and sort (e.g. by distance or rating).

How is this different that the Locations Search and Locations Nearby endpoints?

Both catalog endpoints are not limited by allowlists or geofencing, so you can discover and browse locations before committing to an allowlist. Our catalog endpoints are meant to be used for discovery and research into Tripadvisor's locations. A deeper explanation can be found in our guides section here.

Optimizations under the hood

We've also shipped internal optimizations for search across our endpoints. You should see faster, more consistent response behaviors; no changes on calling or interacting with these endpoints.

December 2025

We are excited to release a set of new features for Terra as we close the year.

New Locations Search endpoint

New endpoint to find locations by name or address within specific geographic boundaries. Designed as a discovery function for Tripadvisor's locations. With over 8 million POIs on Tripadvisor, this endpoint can help you validate or check for existing locations, or to help you manage your list of allowed locations (for endusers that are location-bounded)

Key features:

• Find locations by name or address
• Geographic filtering (country code, geo name, postal code)
• Category filtering (restaurants, attractions, hotels)
• Text search with matched value highlighting
• Pagination (max 20 per page)

Locations Search is currently optimized for non-Asian languages in this initial release. Support for Chinese, Japanese, and Korean will be addressed in a later release with specific demand from our endusers. For more information please visit the API reference page.

New Locations Nearby endpoint

Locations Nearby is an endpoint to find locations within a geographic area using radius-based or bounding box search. Designed for mapping and nearby discovery use cases.

Key features:

• Radius-based search (given coordinates or location ID as a centroid parameter)
• Bounding box search for rectangular areas
• Distance and bearing calculations
• Optional photo inclusion for display purposes
• Rating and category filtering
• Flexible sorting (distance, rating)
• Pagination (max 20 per page)

📘

It's worth noting that we will continue to optimize the performance of /locations/search/ and /locations/nearby in the coming months. Notable performance improvements will be made aware to endusers in our release notes and in email communications.

Enhanced Location Reviews request parameters

The reviews endpoint now supports additional filtering and sorting parameters.

New Filtering Parameters:

Sorting Parameters:

Pagination Parameters:

November 2025

Multi-GET Endpoints for Locations and Geos

We've introduced multi-GET endpoints for Locations and Geos, allowing you to fetch multiple resources in a single API request. This reduces the number of API calls needed when retrieving multiple locations or geos, improving efficiency and reducing latency.

Locations Multi-GET

GET /locations?version=1&id={id},{id}

Geos Multi-GET

GET /geos?version=1&id={id},{id}

Please note

• Multi-GET endpoint response schemas encapsulates multiple locations in a data object, which the single GET endpoints do not.
• If a requested ID doesn't exist or isn't accessible, it will be omitted from the response array. The response may contain fewer items than requested IDs.

October 2025

New Endpoint: List Feed Files

GET /files/list?version=BETA — Lists available feed files for your account.

Request Parameters

Response Schema

{
  "content": [
    {
      "filename": "locations_2025-10-30.gz",
      "filesize": 1048576
    }
  ],
  "metadata": {
    "page": 0,
    "size": 20,
    "total_elements": 45,
    "total_pages": 3
  }
}

FeedFileInfo Object

Response Cleanup

Empty objects and null fields are omitted in responses across all endpoints (smaller payloads, clearer data). If a field is absent, no data is available for it.

Photos

Photo results are ranked for better relevance and consistency across endpoints.