> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cryptoquant.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Latency

> How fresh each metric is — append /latency to any v1 endpoint to see block and process delay.

Every v1 data endpoint exposes a **`/latency`** sibling that reports how long after a block the
metric's data becomes available. Append `/latency` to **any** v1 endpoint path — keep the
`<asset>/<category>/<endpoint>` path you're already calling and add `/latency`:

```bash theme={null}
# Pattern — works for every v1 data endpoint
curl "https://api.cryptoquant.com/v1/<asset>/<category>/<endpoint>/latency" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Example: /btc/exchange-flows/reserve → add /latency
curl "https://api.cryptoquant.com/v1/btc/exchange-flows/reserve/latency" \
  -H "Authorization: Bearer YOUR_API_KEY"
```

The [Data Catalog](/catalog/btc) shows these values under each section's **Data latency** panel —
expand it and switch resolution tabs to see the block and process delay per window.
[`catalog.json`](/catalog/catalog.json) carries the full breakdown for every metric.

## What the numbers mean

The response reports two delays, per resolution (`day`, `hour`, `min`, and `block` where supported)
and averaging window:

| Field     | Meaning                                                                                                                                                              |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `block`   | The delay within the blockchain network — consensus time, block creation time, and related factors.                                                                  |
| `process` | Delay from data processing within the platform. CryptoQuant avoids using the latest block to prevent block-data reorganization, ensuring data consistency over time. |
| `mutable` | Whether values that were already served may still be revised later.                                                                                                  |

Each resolution reports the delay averaged over two windows (e.g. `7day` / `30day` for `day`,
`10min` / `60min` for `block`). Durations are returned in ISO-8601 form, e.g. `P0DT0H16M23.5S`
means 16 minutes 23.5 seconds.

## Try it live

The playground below targets `reserve/latency` as an example — the response shape is identical for
every endpoint, so swap in any path to check another metric.

[**Reserve Latency** in the API Reference →](/api-reference/latency/reserve-latency)

## How to read the response

```json theme={null}
{
  "status": { "code": 200, "message": "success" },
  "result": {
    "data": [
      {
        "all_parameters": true,
        "day": [
          {
            "block":   { "7day": "P0DT0H13M56.7S", "30day": "P0DT0H10M39.8S" },
            "process": { "7day": "P0DT0H26M15.2S", "30day": "P0DT0H29M7.8S" },
            "mutable": true
          }
        ]
      }
    ]
  }
}
```

In this example, for the `day` resolution averaged over the last 7 days, the network (`block`) delay
is about 14 minutes and the platform processing (`process`) delay about 26 minutes.