---
title: "Get ICM timeseries metrics"
method: GET
path: "/v2/icm/timeseries"
tags: ["Chain Metrics"]
---

# Get ICM timeseries metrics

`GET /v2/icm/timeseries`

Get historical ICM message counts with flexible grouping.

Use filters (`srcBlockchainId`, `destBlockchainId`, `network`)  to select data, and the `groupBy` parameter for aggregation level.

### Examples:

  - **Specific pair**:   `?srcBlockchainId=...&destBlockchainId=...`

  - **From one source (aggregated)**: `?srcBlockchainId=...`

  - **From one source (by destination)**:   `?srcBlockchainId=...&groupBy=destBlockchainId`

  - **To one destination (aggregated)**: `?destBlockchainId=...`

  - **To one destination (by source)**:   `?destBlockchainId=...&groupBy=srcBlockchainId`

  - **Network total**: `?network=mainnet`

  - **Network breakdown**:   `?network=mainnet&groupBy=srcBlockchainId,destBlockchainId`.

## Query parameters

- `startTimestamp` integer
- `endTimestamp` integer
- `srcBlockchainId` string
- `destBlockchainId` string
- `timeInterval` 'hour' | 'day' | 'week' | 'month'
- `pageToken` string
- `pageSize` integer
- `groupBy` 'srcBlockchainId' | 'destBlockchainId' | 'srcBlockchainId,destBlockchainId'
- `network` 'mainnet' | 'fuji' | 'testnet'

## Response `200`

Successful response

- ICMMetricsApiResponse
  - `nextPageToken` string — A token, which can be sent as `pageToken` to retrieve the next page. If this field is omitted or empty, there are no subsequent pages.
  - `results` ICMMetricsValue[], required — Array of current ICM metrics values.
    - `value` number, required — Aggregated value for the current metrics.
    - `timestamp` number, required — Unix Epoch timestamp for which metrics are aggregated. Depending on the interval of the metric this can be at the start of the relevant hour, day, month, year, etc.
    - `srcBlockchainId` string, required — Source blockchainId.
    - `destBlockchainId` string, required — Destination blockchainId.

## Other responses

- `400` — Bad requests generally mean the client has passed invalid or malformed parameters. Error messages in the response could help in evaluating the error.
- `401` — When a client attempts to access resources that require authorization credentials but the client lacks proper authentication in the request, the server responds with 401.
- `403` — When a client attempts to access resources with valid credentials but doesn't have the privilege to perform that action, the server responds with 403.
- `404` — The error is mostly returned when the client requests with either mistyped URL, or the passed resource is moved or deleted, or the resource doesn't exist.
- `429` — This error is returned when the client has sent too many, and has hit the rate limit.
- `500` — The error is a generic server side error that is returned for any uncaught and unexpected issues on the server side. This should be very rare, and you may reach out to us if the problem persists for a longer duration.
- `502` — This is an internal error indicating invalid response received by the client-facing proxy or gateway from the upstream server.
- `503` — The error is returned for certain routes on a particular Subnet. This indicates an internal problem with our Subnet node, and may not necessarily mean the Subnet is down or affected.

---

[API](https://skmtc.net/avax/apis/metrics-api.md) · [All operations](https://skmtc.net/avax/apis/metrics-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/avax/metrics-api/versions/e699a9ddcb70/schema)