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 which properties have changed in 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.

When to use this endpoint

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.

How it fits in the retrieval flow

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

Recommended flow:

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

Request

Provide the timestamp from which you want to track changes. You can optionally filter by country or city to narrow the scope.

Time window limitation

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.

Make sure you run this endpoint regularly and persist the latest next timestamp to avoid gaps in your data sync.

Example

→ Call the /accommodations/details/changes endpoint using different countries (See Country codes conventions)

Example with The Netherlands, Spain and Italy:

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

Response

A successful response returns the list of accommodation IDs that have been modified in the last 24h, grouped by change type, together with timestamps to continue pagination.

Response fields

Example

{
  "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
  }
}

Pagination and limits

• You can only request changes from the last 24 hours. Older timestamps are not supported and result in an error response.
• Each request returns up to approximately 5,000 accommodation IDs.
• Use the next timestamp to retrieve subsequent updates.
• Continue polling until no further changes are returned.

Best practices

• Store the next timestamp after each successful run and reuse it for the next sync.
• Refresh only affected IDs using /accommodations/details
• Handle closures explicitly by removing or disabling closed properties in your system
• Schedule regular syncs based on your freshness requirements (for example, hourly or daily)

Common pitfalls

• Using a last_change timestamp older than 24 hours, which results in an error.
• Treating this endpoint as a replacement for /accommodations/details
• Ignoring temporarily closed accommodations.
• Re-fetching all properties instead of only the changed ones.
• Not persisting the next timestamp between sync runs.

Related endpoints

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

Use these endpoints together to ensure accurate and up-to-date accommodation content across your integration.