Track accommodation content changes

Understand the accommodations/details/changes endpoint, the required fields for each request, best practices and use cases.

→ Use the /accommodations/details/changes endpoint to keep your local accommodation data up to date by identifying properties that have opened, closed, or had content changes since a specified timestamp within the last 24 hours.

This endpoint does not return full accommodation details. Instead, it tells you what has changed (opened, closed, or updated) so you can selectively refresh those properties using /accommodations/details.

Use /accommodations/details/changes if you:

✓ Maintain a local data storage of accommodation content.
✓ Need to detect incremental updates instead of reloading all properties.
✓ Want to track openings, closures, and content changes efficiently.

Typical use cases include:

• Nightly or hourly content synchronisation jobs.
• Reducing unnecessary calls to /accommodations/details.
• Keeping search, availability, and display data accurate.

This endpoint is designed to be used together with /accommodations/details.

This approach ensures your local data stays current without reloading unchanged properties.

Provide the timestamp from which you want to track accommodation changes using last_change.

The last_change timestamp:

• Must use ISO 8601 format: YYYY-MM-DDTHH:mm:ss+00:00.
• Must use the UTC time zone (+00:00).
• Is inclusive, meaning changes occurring at the specified timestamp are included.
• Must be within the last 24 hours.

You can optionally narrow the results to accommodations in specific countries or cities using the filters object.

You can only retrieve accommodation changes that occurred within the last 24 hours.

If the last_change timestamp is older than 24 hours from the current time, the API returns an error.

Run this endpoint regularly and persist the latest next timestamp to avoid gaps in your data synchronisation.

Use the countries or cities filter to restrict the response to accommodation changes in specific locations.

Only one of these filters can be specified in a request: use either countries or cities, but not both.

The following request retrieves accommodation changes for the Netherlands, Spain, and Italy:

{
  "last_change": "2025-12-18T17:00:00+00:00",
  "filters": {
    "countries": [
      "nl",
      "es",
      "it"
    ]
  }
}

A successful response returns accommodation IDs with changes since the specified last_change timestamp, grouped by change type.

When changes are returned, the response also provides a next timestamp that you can use to continue retrieving updates.

{
  "request_id": "01jbccaq5a5a0hg59c0w1ee1yy",
  "data": {
    "changes": {
      "changed": [
        9847612,
        8908982,
        12120474,
        12957429,
        10463538
        // ... (continued)
      ],
      "closed": [
        12972627,
        12386101,
        11896813
        // ... (continued)
      ],
      "opened": [
        11271338,
        6439891,
        4434608,
        13013177
        // ... (continued)
      ]
    },
    "from": "2025-12-18T17:00:00+00:00",
    "next": "2025-12-19T00:56:46+00:00",
    "total_changes": 5037
  }
}

• You can only request changes from the last 24 hours. Older last_change timestamps are not supported and result in an error.
• Each request returns up to approximately 5,000 accommodation IDs.
• When changes are returned, use the next timestamp as the last_change value in the subsequent request.
• The next timestamp is one second after the latest change returned by the previous request.
• If no changes are returned, next is not provided. Repeat the request after one minute using the same last_change timestamp.

• Store the next timestamp after each successful response that contains changes and use it as last_change in the subsequent request.
• Reuse last_change when there are no changes. If total_changes is 0, wait one minute and repeat the request using the same timestamp.
• Refresh only affected IDs using /accommodations/details.
• Handle closures explicitly according to their closure type.
• Schedule regular synchronisation jobs at intervals comfortably within the 24-hour lookback window to reduce the risk of gaps.
• Use UTC timestamps only when specifying last_change.

• Using a last_change timestamp older than 24 hours.
• Using a time zone other than UTC for last_change.
• Specifying both countries and cities in the same request.
• Moving last_change forward when no changes have been returned.
• Treating this endpoint as a replacement for /accommodations/details.
• Ignoring the different closure types returned in v3.2.
• Re-fetching all properties instead of only affected accommodation IDs.
• Not persisting the next timestamp between synchronisation runs.

• Retrieve accommodation details: /accommodations/details
• Search for accommodations: /accommodations/search
• Check availability: /accommodations/availability