Get statistics by category
/v1/email/stats/categoriesconst { data } = await bird.email.stats.byCategory({ from: "2026-05-01", to: "2026-05-31" });
for (const row of data) console.log(row.category, row.delivery.delivered);stats = client.email.stats.by_category(from_="2026-05-01", to="2026-05-25")
for row in stats.data:
print(row)stats, err := client.Email.Stats.ByCategory(context.Background(), bird.EmailStatsByCategoryParams{})
if err != nil {
log.Fatal(err)
}
fmt.Println(stats.Data)$stats = $bird->email->stats->byCategory(['from' => '2026-05-01', 'to' => '2026-05-31']);
foreach ($stats->getData() ?? [] as $row) {
echo $row->getCategory(), ' ', $row->getDelivery()?->getDelivered(), "\n";
}bird email stats by-categorycurl -X GET "https://us1.platform.bird.com/v1/email/stats/categories" \
-H "Authorization: Bearer $TOKEN" \
--url-query "sort=processed" \
--url-query "limit=50" \
--url-query "include_trend=false" \
--url-query "trend_grain=daily"{
"period": {
"from": "2026-05-01",
"to": "2026-05-25",
"data_as_of": "2026-05-25T14:03:10Z"
},
"data": [
{
"category": "transactional",
"delivery": {
"accepted": 14820,
"processed": 14810,
"delivered": 14720,
"bounced": 90,
"bounces": {
"hard": 12410,
"soft": 14290,
"admin": 410,
"block": 920,
"undetermined": 80,
"hard_rate": 0.454,
"soft_rate": 0.523,
"admin_rate": 0.015,
"block_rate": 0.0337,
"undetermined_rate": 0.0029
},
"complained": 3,
"deferred": 14,
"rejected": 10,
"oob_bounces": 2,
"effective_delivered": 14718,
"all_bounces": 92,
"oob_rate": 0.00014,
"delivery_rate": 0.9939,
"bounce_rate": 0.0061,
"complaint_rate": 0.0002
},
"engagement": {
"opens": 5420,
"opens_non_prefetched": 3210,
"unique_opens": 3640,
"unique_opens_non_prefetched": 2480,
"clicks": 924,
"unique_clicks": 621,
"unsubscribes": 12,
"open_rate": 0.1683,
"click_rate": 0.0422,
"unsubscribe_rate": 0.0009
},
"latency": {
"processing": {
"p50_ms": 420,
"p95_ms": 1820,
"p99_ms": 4920
},
"delivery": {
"p50_ms": 420,
"p95_ms": 1820,
"p99_ms": 4920
},
"total": {
"p50_ms": 420,
"p95_ms": 1820,
"p99_ms": 4920
}
},
"trend": [
{
"bucket": "2026-05-12"
}
]
}
],
"total": 2,
"next_cursor": "eyJ2IjoxLCJzIjoiXCIyMDI2LTA1LTI1VDE0OjAzOjEwWlwiIiwiaSI6IjAxOTJmM2IxLTRjN2UtN2EyYi05ZDYxLThmM2E1YzJlN2I0MCJ9",
"prev_cursor": null,
"refresh_cursor": "eyJ2IjoxLCJzIjoiXCIyMDI2LTA1LTI1VDE2OjQyOjAxWlwiIiwiaSI6IjAxOTJmM2IxLTllMDQtN2NkMy1iODE3LTJhNmY0ZDFjOGUwOSJ9"
}
Returns delivery and engagement counts for the requested period, grouped by category, so you can compare deliverability and engagement between your transactional and marketing traffic. Rows are ranked by the sort metric, processed by default, and paginated with the requested limit (50 by default, 200 at most).
Rows are computed against event time rather than send time, so engagement received during the period counts even for messages that were sent earlier.
The window can span at most 365 days. Ask for more and you get a 422.
Abfrageparameter
starting_afterstringCursor from the next_cursor field of a previous list response. Returns items immediately after the cursor position in the current sort order.
ending_beforestringCursor from the prev_cursor or refresh_cursor field of a previous list response. Returns items immediately before the cursor position in the current sort order. prev_cursor returns the preceding page. refresh_cursor anchors at the first row of that response, which on a newest-first sort is how to fetch the items that have appeared since.
fromstringStart date (inclusive) in YYYY-MM-DD, interpreted as a calendar day in timezone (a UTC day when timezone is omitted). It defaults to 30 days before to when you leave it out. When include_trend=true and trend_grain=hourly, that default tightens to 29 days before to instead, so the defaulted window still fits inside the 720-hour trend cap.
tostringEnd date (inclusive) in YYYY-MM-DD, interpreted as a calendar day in timezone (a UTC day when timezone is omitted). Defaults to today in that timezone when omitted. Window may not exceed 365 days.
timezonestringIANA timezone identifier used to group statistics, for example Asia/Kathmandu. The default is UTC. Day and hour boundaries, including the default window when from and to are omitted, follow this timezone. When this parameter is set, pass from and to as calendar days or Z instants instead of timestamps with explicit UTC offsets.
sortstringMetric to rank rows by, applied descending. Any count or rate in the response can be used. A row whose rate is undefined because its denominator is zero sorts last. It defaults to processed.
Possible values: processed, delivered, bounced, complained, deferred, rejected, oob_bounces, bounces.hard, bounces.soft, bounces.admin, bounces.block, bounces.undetermined, opens, opens_non_prefetched, unique_opens, unique_opens_non_prefetched, clicks, unique_clicks, unsubscribes, delivery_rate, bounce_rate, complaint_rate, open_rate, click_rate, unsubscribe_rate, bounces.hard_rate, bounces.soft_rate, bounces.admin_rate, bounces.block_rate, bounces.undetermined_rate
limitintegerMaximum number of category rows to return, ranked by the sort field descending.
include_trendbooleanWhen true, each row also gets a trend array: a short per-bucket series showing that category's delivery and engagement rates over the window. This only works when limit is 50 or fewer and the window is at most 90 days for trend_grain=daily or 720 hours for trend_grain=hourly. Ask for more and you get a 422. When you leave from out and use trend_grain=hourly, the default window tightens to 29 days before to (720 hours total), so a request built entirely from defaults always fits inside the cap.
trend_grainstringBucket grain for the trend series. Has no effect unless include_trend=true.
Possible values: daily, hourly
Antwort-Payload
periodThe date range the response covers (echoed back from the request), plus data_as_of, the freshness boundary the data is current to.
dataCategory breakdown rows, ranked by the sort metric (default processed) descending. Empty when no sends occurred in the period.
Untergeordnete Attribute anzeigen
data.categoryThe category this row aggregates, as set at send time. transactional is one-to-one mail triggered by a user action. marketing is bulk sending. New categories may be added over time.
data.deliveryDelivery 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.
Untergeordnete Attribute anzeigen
data.delivery.acceptedDistinct recipients accepted for delivery after suppression filtering. Reported on time buckets and the period summary. Breakdown rows leave it out, because their rollups do not have it.
data.delivery.processedDistinct recipients whose message was processed and handed off for delivery.
data.delivery.deliveredDistinct recipients whose message the receiving mail server accepted.
data.delivery.bouncedDistinct recipients whose delivery failed. This is approximately the sum of the five bounces.* sub-counts (hard, soft, admin, block, undetermined). The two totals are worked out independently, so they can differ slightly.
data.delivery.bouncesBreakdown of bounced by failure type, with each rate as a fraction of bounced. Counts are distinct bounced recipients of that type; the five types approximately partition bounced, so the five rates sum to roughly 1.0 when bounced is non-zero.
data.delivery.complainedDistinct recipients who reported the message as spam via a feedback loop.
data.delivery.deferredDistinct recipients whose delivery the receiving server temporarily delayed and is still being retried.
data.delivery.rejectedDistinct recipients rejected before any delivery attempt. Includes recipients on the workspace suppression list, transmissions that could not be completed, message-generation failures, and recipients refused by sending policy. The per-recipient rejection_reason field on GET /v1/email/messages/{message_id}/recipients surfaces the specific cause.
data.delivery.oob_bouncesOut-of-band bounce events: distinct failure notifications received after the receiving server had initially confirmed delivery. The count represents deduplicated events rather than unique recipients.
data.delivery.effective_deliveredRecipients who remain delivered after all bounce signals resolve, computed as delivered - oob_bounces. Use this as the base for engagement-rate denominators. Clamped to 0 when oob_bounces exceeds delivered.
data.delivery.all_bouncesTotal recipients in this scope who did not receive the message, computed as bounced + oob_bounces.
data.delivery.oob_rateShare of this scope's delivery attempts that resulted in an out-of-band bounce, computed as oob_bounces / (delivered + bounced). Null when there were no attempts.
data.delivery.delivery_rateShare of this scope's delivery attempts that remained delivered after all bounce signals, computed as effective_delivered / (delivered + bounced). Null when there were no attempts.
data.delivery.bounce_rateShare of this scope's delivery attempts that ultimately failed (inband or out-of-band), computed as all_bounces / (delivered + bounced). Because oob_bounces counts events rather than recipients, all_bounces can exceed the attempt count. The rate is clamped to 1. Null when there were no attempts.
data.delivery.complaint_rateSpam complaints in this scope relative to effectively delivered recipients, computed as complained / effective_delivered. Complaints are attributed by event time, so a scope can record more of them than it effectively delivered, pushing the rate above 1. Null when effective_delivered is zero.
data.engagementEngagement 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.
data.latencyLatency 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.
data.trendPer-bucket rate series for this category over the window. Present only when include_trend=true.
totalTotal number of distinct categories with activity in the period, regardless of limit. Pass next_cursor as starting_after to request the next page.
next_cursorCursor for the next page. Pass back as starting_after to advance forward. null when no next page exists.
prev_cursorCursor for the previous page. Pass back as ending_before to step backward. null when no previous page exists.
refresh_cursorRefresh anchor, the first row of this response. Pass back as ending_before to fetch what precedes it in the current sort order. On a newest-first sort those are the items that have appeared since; on any other sort they are the items that sort earlier, so refreshing such a list means re-fetching it instead. Non-null whenever data is non-empty; null only on an empty page. Distinct from prev_cursor.
Verwandte Ressourcen
Weiter mit der Dokumentation, Anleitungen und Beispielen zu diesem Thema.