# 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](/demand/docs/open-api/demand-api/accommodations/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](/demand/docs/open-api/demand-api/accommodations/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:**

| Step | Action |
|  --- | --- |
| 1. 
 | Call /accommodations/details/changes with a 24 hour `last_change` timestamp. |
| 1. 
 | Identify accommodation IDs that have:* Changed
* Opened
* Closed (temporarily, permanently and due to fraud in v3.2)

 |
| 1. 
 | Re-fetch full details for the relevant IDs using /accommodations/details. |
| 1. 
 | Store the next timestamp from the response. |
| 1. 
 | Repeat the process using the new timestamp. |


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.

> ![genius-bulb](/assets/genius-bulb.3e13976eeeabd0526f1d76bfb7de5967932211a5ef4afe526a3b0a71a7b02fb0.5e2a7131.png) 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](/demand/docs/open-api/demand-api/accommodations/accommodations/details/changes) endpoint using different countries (See [Country codes conventions](/demand/docs/development-guide/code-conventions#country-codes))

Example with The Netherlands, Spain and Italy:


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

Note that a list of max 100 countries or cities is supported.

## 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

| Field | Description |
|  --- | --- |
| `changes.changed` | Accommodation IDs with updated content. This indicates that some of the static details returned by /accommodations/details have been updated (e.g. address/info, description, facilities, photos, payment types, rooms, etc.). You should re-fetch its full details using the /accommodations/details endpoint to ensure your local data is up to date. |
| `changes.opened` | Newly opened accommodations. |
| `changes.closed.temporarily` (v3.2) | Temporarily closed accommodations. |
| `changes.closed.permanently` (v3.2) | Permanently closed accommodations. |
| `changes.closed.fraud` (v3.2) | Accommodations closed due to fraud. |
| `from` | Timestamp used for this request. |
| `next` | Timestamp to use for the next request. |
| `total_changes` | Total number of changed accommodation IDs returned. |


### Example

Changes v3.1 response

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

v3.2 response
In version 3.2 the response distinguishes between temporarily, permanently and fraud closure.


```json
{
  "request_id": "01kctwxa9kbgzadnbd093x7g0g",
  "data": {
    "changes": {
      "changed": [
        13267557,
        12622430,
        13729720,
        3439708,
        12564369,
        // ... (continued)
      ],
      "closed": {
        "fraud": [
          123456789,
          222352525,
          333652582,
          552536254,
          // ... (continued)
        ],
        "permanently": [
          14100826,
          14148096,
          7326491,
          // ... (continued)
        ],
        "temporarily": [
          13641323,
          575469,
          15380013,
          // ... (continued)
        ]
      },
      "opened": [
        15478156,
        15475846,
        15478285,
        1984590,
        7651038,
        // ... (continued)
   
      ]
    },
    "from": "2025-12-18T17:00:00+00:00",
    "next": "2025-12-19T00:56:46+00:00",
    "total_changes": 5000
  }
}
```

## 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.


Do not reuse the same `last_change` value repeatedly, and do not attempt to query beyond the 24-hour window, as this may result in errors or incomplete data.

## 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.

Curious to know more?
* Learn how to refresh full property data after detecting changes in [Retrieve accommodation details guide](/demand/docs/accommodations/look-accommodation-details).
* For information on legal disclosure requirements for EEA travellers, see the [DSA compliance guide](/demand/docs/compliance/dsa-compliance).