---
title: "Get outbound WhatsApp statistics by country"
method: GET
path: "/v1/whatsapp/stats/countries"
tags: ["whatsapp-stats"]
---

# Get outbound WhatsApp statistics by country

`GET /v1/whatsapp/stats/countries`

## Request

- Base URL: `https://us1.platform.bird.com`
- URL: `https://us1.platform.bird.com/v1/whatsapp/stats/countries`
- Auth: one of:
  - HTTP bearer
  - API key in cookie `bird_session`

Returns delivery counts, read engagement and latency grouped by the recipient's destination
country. Rows use send-time attribution, rank by accepted volume, and are capped by `limit`
(default 50, maximum 200). A recent period under-reports `delivered` while delivery reports
are still arriving. The maximum window is 365 days; a longer range returns `422`.

A country row covers messages addressed to a single recipient. A recipient whose country
cannot be resolved (a number shaped like a phone number that belongs to no country, or a
non-geographic range such as freephone) is counted under `ZZ` rather than dropped,
matching the SMS country breakdown. Group sends are omitted entirely: one spans
up to eight recipients in as many countries, so no single destination country describes
it. These rows therefore sum to the summary less that group volume. A window reaching before this
breakdown shipped falls short by more than that: history was seeded only where the
recipient's country could be recovered from stored data, so a phone-addressed send
accepted before the cutover has no `accepted` leg here. Two cases follow, and they read
differently. Acceptance days more than 14 days before the cutover are a plain shortfall
and never change. In the 14 days immediately before it, a `delivered`, `read` or `failed`
callback arriving after the cutover does carry a country and is attributed to its original
acceptance day, so a row there can report deliveries with `accepted` at zero. Its
`delivery_rate` and `failure_rate` are then null for want of a denominator while
`read_rate` still computes and looks healthy. The 14 days are the status recording window,
after which a callback is dropped. All of this is confined to pre-cutover acceptance days
and gone once the requested window starts after the cutover date.

Latency reports the same three families as the summary: `processing`, `delivery` and
`total`. The delivery family depends on a best-effort handoff timestamp that a fast
delivery callback can beat, so it can be absent for a country whose other two families
are present.

A breakdown is already a single-dimension view and takes no dimension filter; to restrict
statistics to a single template, category, phone number or tag, use the summary, daily or
hourly statistics instead.

## Query parameters

- `from` string, date
- `to` string, date
- `timezone` string
- `limit` integer

## Headers

- `X-Workspace-Id` string
- `X-Organization-Id` string

## Response `200`

Per-country breakdown for the requested period.

- WhatsAppStatsByCountryResponse: Per-country breakdown for the requested period, ranked by accepted volume descending and capped at the requested `limit` (default 50, max 200).
  - `period` WhatsAppStatsSummaryPeriod, required: The window the server actually computed against. The summary serves two window grains: calendar days (bounds are YYYY-MM-DD) and hours (bounds are RFC 3339 instants on the hour). The grain of `from` and `to` mirrors the grain of the request's bounds.
    - `from` string, required: Inclusive start of the window, as a calendar day (`YYYY-MM-DD`) or an RFC 3339 hour boundary.
    - `to` string, required: Inclusive end of the window, as a calendar day (`YYYY-MM-DD`) or an RFC 3339 hour boundary.
    - `data_as_of` string, date-time, nullable: Latest time reflected in the statistics. More recent events might not be included yet. Null when the freshness boundary is unavailable.
  - `data` WhatsAppCountryStatsPoint[], required: Country rows ranked by accepted volume descending. Empty when no eligible activity occurred in the period; rows sum to the summary less group-send volume, and less any pre-cutover phone-addressed sends still inside the window.
    - `country` string, required: ISO 3166-1 alpha-2 country code.
    - `delivery` WhatsAppDeliveryStats, required: WhatsApp lifecycle counts and rates for the requested period, attributed by send time, so a later delivery stays attributed to the period in which its message was accepted, and a recent period under-reports `delivered` while delivery reports are still arriving. The sibling `engagement` block reports read counts and rates. Rates are null when their denominator is zero. Very large counts are close estimates rather than exact tallies.
      - `accepted` integer, required: Distinct messages accepted for sending after admission checks. This is the denominator for `delivery_rate` and `failure_rate`.
      - `sent` integer, required: Distinct messages handed off for delivery.
      - `delivered` integer, required: Distinct messages confirmed delivered to the recipient's device.
      - `failed` integer, required: Distinct messages that failed during sending or delivery.
      - `rejected` integer, required: Distinct messages rejected before any send attempt, because the recipient is on the workspace's suppression list, no reachable recipient was given, the destination has no price, or the wallet could not fund the send. Rejected messages are never charged and are not counted in `accepted`, so the total addressed is `accepted + rejected`. Excluded from `failure_rate`, which covers send failures only.
      - `delivery_rate` number, nullable, required: Share of accepted messages that were delivered, computed as `delivered / accepted`. Null when no messages were accepted in scope.
      - `failure_rate` number, nullable, required: Share of accepted messages that ultimately failed, computed as `failed / accepted`. Null when no messages were accepted in scope.
    - `engagement` WhatsAppEngagementStats, required: WhatsApp engagement counts and the derived read rate for the scope of the containing row (the whole requested period or a breakdown dimension). The `read` field is the number of distinct messages confirmed read by the recipient. Send time determines attribution; the instant the read receipt arrived does not. A read is counted in the period its message was accepted in, alongside that message's own delivery when one arrived. The read rate divides reads by messages delivered in the same scope and is null when its denominator is zero. Very large counts are close estimates rather than exact tallies.
      - `read` integer, required: Distinct messages confirmed read by the recipient.
      - `read_rate` number, nullable, required: Distinct messages read relative to messages delivered in the same scope, computed as `read / delivery.delivered`. Both counts are attributed by send time, so a read is counted alongside its own message's delivery. The rate can exceed 1 where a read receipt arrived for a message whose delivery receipt did not, or, at high volume, because the counts are close estimates. Null when `delivery.delivered` is zero.
    - `latency` WhatsAppLatencyStats, required: Latency percentiles in milliseconds for the requested scope: - `processing`: From acceptance to WhatsApp handoff. - `delivery`: From WhatsApp handoff to delivery confirmation. - `total`: From acceptance to delivery confirmation. Each family is omitted when no qualifying message contributes a measurement. Individual percentiles can also be null. `delivery` is measured on a best-effort basis, so it can be absent for a scope whose `processing` and `total` are present.
      - `processing` WhatsAppLatencyQuantiles: Approximate p50, p95, and p99 latency percentiles in milliseconds for one latency family. All three are null when no qualifying event contributed a measurement.
        - `p50_ms` integer, nullable, required: Median (50th percentile) latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p95_ms` integer, nullable, required: 95th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p99_ms` integer, nullable, required: 99th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
      - `delivery` WhatsAppLatencyQuantiles: Approximate p50, p95, and p99 latency percentiles in milliseconds for one latency family. All three are null when no qualifying event contributed a measurement.
        - `p50_ms` integer, nullable, required: Median (50th percentile) latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p95_ms` integer, nullable, required: 95th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p99_ms` integer, nullable, required: 99th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
      - `total` WhatsAppLatencyQuantiles: Approximate p50, p95, and p99 latency percentiles in milliseconds for one latency family. All three are null when no qualifying event contributed a measurement.
        - `p50_ms` integer, nullable, required: Median (50th percentile) latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p95_ms` integer, nullable, required: 95th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
        - `p99_ms` integer, nullable, required: 99th percentile latency in milliseconds. Null when no qualifying event contributed a measurement.
  - `total` integer, required: Total distinct countries with activity in the period, regardless of `limit`.

## Other responses

- `400`: Bad request
- `401`: Authentication required
- `403`: Insufficient permissions
- `404`: Resource not found
- `422`: The request has invalid field values, violates a business rule, or carries a query parameter the endpoint does not declare. Field validation errors use `type: validation_error` and include the affected fields in `details`. Business-rule errors identify the failed rule in `type`.
- `429`: Rate limit exceeded
- `500`: Internal server error
- `503`: The service is temporarily unavailable. If `Retry-After` is present, wait for that delay before retrying; otherwise, retry with exponential backoff. Reuse the same idempotency key and request when retrying a mutation.

---

[API](https://skmtc.dev/messagebird/apis/bird-api.md) · [All operations](https://skmtc.dev/messagebird/apis/bird-api/llms.txt) · [OpenAPI document](https://skmtc.dev/messagebird/apis/bird-api/revisions/6dfce1179799?raw)