---
title: "Integration delivery statistics"
method: GET
path: "/v1/sites/{site_id}/integrations/{integration_id}/stats"
tags: ["Integrations"]
---

# Integration delivery statistics

`GET /v1/sites/{site_id}/integrations/{integration_id}/stats`

## Request

- Base URL: `https://api.getsitecontrol.com`
- URL: `https://api.getsitecontrol.com/v1/sites/{site_id}/integrations/{integration_id}/stats`
- Auth: HTTP bearer

How the deliveries of one integration went over a period: the deliveries created in it by current status, how many were tried more than once, and the largest groups of failed and unfinished ones by response code and reason. The counts cover every delivery of the period, not one page. Call it to size a problem, then `list_integration_deliveries` for the records behind a count; per day, week or month: `get_integration_stats_timeline`.

The period is whole UTC days, at most 31, with `from` at most 30 days before today. Statuses are the current ones, not the ones at the end of the period. Zero deliveries does not mean the integration works, or that nobody sent the form: a response that never reached this integration leaves nothing here.

## Path parameters

- `site_id` integer, required
- `integration_id` string, required: Integration id from `list_integrations`, such as `webhook:12`

## Query parameters

- `from` string, date, required: First day of the period, UTC, included
- `to` string, date: Last day of the period, UTC, included; today when omitted

## Response `200`

Successful Response

- IntegrationStatsTotal
  - `period` StatsPeriod, required
    - `date_from` string, date, required: First day, UTC, included
    - `date_to` string, date, required: Last day, UTC, included
  - `total` DeliveryMetrics, required: Deliveries split by their current status, not their status back then.
    - `deliveries` integer: All of them; the sum of the statuses
    - `pending` integer
    - `succeeded` integer
    - `failed` integer
    - `cancelled` integer
  - `retried` integer, required: Deliveries tried more than once, by their current attempt counter
  - `errors` IntegrationErrorBucket[], required: Failed and pending deliveries grouped by status, outcome, status code and reason; the 8 largest groups, largest first
    - `status` 'pending' | 'succeeded' | 'failed' | 'cancelled', required: Current status of a delivery. pending: queued, set aside or being sent, not finished, with no promised retry time; succeeded: finished without an error, which does not prove that a request was sent or that the destination kept the data; failed: stopped with an error, which does not prove that nothing arrived; cancelled: dropped by our side before sending, see `reason`; it does not prove that nothing was sent earlier.
    - `outcome` 'accepted_by_destination' | 'accepted_with_redirect' | 'not_sent' | 'finished_unconfirmed' | 'rejected_by_destination' | 'refused_not_retried' | 'failed_no_http_status' | 'failed_other': What a finished delivery record proves. accepted_by_destination: status succeeded with a 2xx `status_code`, the destination accepted that request; it does not prove a contact, a subscription, a confirmed double opt-in or an automation run on the other side. accepted_with_redirect: a finished record with a 302 or 303 `status_code`, whatever its status: the destination accepted the request and answered with a redirect, which is how forms usually answer; redirects are not followed, the attempt's `location` says where it pointed. not_sent: status succeeded with reason `empty_url` or `conditions_failed`, this record sent nothing; it does not say whether an earlier attempt of this record sent anything. finished_unconfirmed: status succeeded without a 2xx code, finished without an error but does not establish that a request was made, as with connected services, which record no HTTP status, and with a contact the service reported as already existing. rejected_by_destination: status failed with an HTTP status other than 2xx, the destination answered with it; it does not prove the destination kept nothing. refused_not_retried: status failed, the data was refused in a way the sender does not retry, such as an empty email field or the service's own refusal quoted in `message`; a new form response after a fix is the way to check again. failed_no_http_status: status failed with no HTTP answer recorded (a timeout, a connection error or our own error, see `reason` and `message`); it does not establish whether a request reached the destination. failed_other: status failed with an answer that has no published meaning.
    - `status_code` integer, nullable: As `status_code` of a delivery: an HTTP status, or null without one
    - `reason` string, nullable: As `reason` of a delivery; null when none is known
    - `count` integer, required: Deliveries in this group

## Other responses

- `400`: Unsupported GSC-Version
- `401`: Missing or invalid API key or access token
- `403`: Access denied
- `404`: `integration_not_found`: no such integration on the site, or its widget is deleted
- `422`: `stats_period_too_long`: more than 31 days. `validation_failed`: a malformed parameter, or `from` more than 30 days before today or after `to`
- `429`: Rate limited
- `503`: `temporarily_unavailable`: the delivery records could not be read in time, or limits cannot be enforced; retry later. The heavy request is spent all the same

---

[API](https://skmtc.dev/getsitecontrol/apis/getsitecontrol-public-api.md) - [All operations](https://skmtc.dev/getsitecontrol/apis/getsitecontrol-public-api/llms.txt) - [OpenAPI document](https://skmtc.dev/getsitecontrol/apis/getsitecontrol-public-api/revisions/084fcad80e75?raw)