Get aggregate email statistics

The preceding window these comparison figures cover, the equal-length window ending immediately before the requested start (the prior day for day windows, the prior hour for hour windows). For a request covering 2026-05-01 to 2026-05-31, this is 2026-03-31 to 2026-04-30, both inclusive.

Distinct email messages accepted in the preceding period, counted at the message level.

Delivery counts and rates for the scope of the containing row (a time bucket, a breakdown dimension, or the whole period). Lifecycle counts identify distinct recipients that reached the named stage in scope; oob_bounces counts distinct failure events. Period summaries count each identity once per metric across the whole window, so adding time-bucket distinct counts can overstate the summary. Event time determines attribution; send time does not. A recipient delivered on Monday counts in Monday's row. A recipient who bounced and then succeeded on a retry can appear in both bounced and delivered. Very large counts are close estimates rather than exact tallies.

These counts are successive lifecycle stages, so a recipient can appear in more than one:

• rejected: Happens before any send attempt, from suppression, policy, or a generation failure.
• deferred: A temporary in-flight delay that is still being retried.
• bounced: A delivery failure, with its own hard, soft, admin, block, and undetermined sub-types.
• complained: Post-delivery spam feedback.

Each rate is a fraction in the range 0 to 1 and is null when its denominator is zero. accepted is reported only where it can be attributed (time buckets and the period summary). Breakdown rows omit it.

Engagement counts and rates for the scope of the containing row (a time bucket, a breakdown dimension, or the whole period). opens, opens_non_prefetched and clicks count distinct engagement events (deduplicated occurrences). The unique_* fields count distinct recipients. unsubscribes counts distinct unsubscribe events. An event counts in the time bucket when it occurs, even if the message was sent in an earlier bucket. Counts are deduplicated with a scalable approximate counting method, so very large counts are close estimates rather than exact tallies. Each rate divides the counts in this scope and is null when its denominator is zero.

Latency percentiles (p50, p95, p99) in milliseconds for the bucket. On the summary endpoint these are computed across the whole period rather than per bucket. Three families are reported:

• processing: Time from accepting the send to handing the message off for delivery. Measured per processed recipient; null when no recipient in the bucket has reached the processed stage.
• delivery: Time from handoff to the receiving mail server accepting the message, dominated by recipient-side delivery behavior. Measured per delivered recipient; null when no deliveries occurred in the bucket.
• total: End-to-end time from accepting the send to delivery, and the number most worth watching against your own delivery targets. Measured per delivered recipient; null when no deliveries occurred in the bucket.

Each family is reported independently. A family is omitted when no qualifying event contributed a latency measurement in the bucket. This also applies when the workspace has not recorded latency for that stage yet. The processing family can therefore be present while delivery and total are absent. A client must handle a missing family, and a null p50/p95/p99 within a present family, by rendering a placeholder rather than assuming a number.

The change in each headline metric from the preceding period to the requested one. A *_pct_change field is a signed relative change in a count, computed as (current - previous) / previous, so 0.5 means 50% higher and -0.2 means 20% lower. It is null when the previous period's count was zero because a relative change cannot be computed. A *_rate_pp field is the signed difference between the two periods' rate values. Each value is expressed as a fraction. A value of 0.012 means the rate rose by 1.2 percentage points. A value of -0.003 means it fell by 0.3 points. The field is null when either period's rate is undefined, because its denominator was zero. delivery_rate_pp and bounce_rate_pp range from -1 to 1, because the rates behind them cannot exceed 1. The engagement deltas have no fixed bound, because events are counted when they arrive rather than when the message was sent, which can push their rate above 1.