What changed
On August 27, 2026, Resend released an Email Metrics API at `/emails/metrics`. With no parameters it returns the available metrics for the previous seven days; callers can choose date ranges up to the account’s retained history, request selected metrics, change time granularity and group results by period, domain, broadcast or individual email. Available measures include sent, delivered, delayed and failed messages; permanent, transient and undetermined bounces; complaints, suppressions and unsubscribes; opens and clicks; and corresponding delivery, bounce, complaint, open, click and unsubscribe rates.
Why it matters
Deliverability monitoring is most useful when it can drive action before inbox placement or sender reputation deteriorates. Resend’s metrics were already visible operationally, but a dedicated queryable API makes them infrastructure: teams can put domain-level complaint and bounce trends into their own dashboards, compare them with provider thresholds, create alerts, or let an agent investigate changes without manual exports. The API does not prove why a deliverability metric moved, so builders still need provider-specific signals, DNS/authentication checks and campaign context to diagnose causes.
The endpoint covers both delivery health and engagement
The API exposes message lifecycle counts such as sent, delivered, delayed, failed and suppressed alongside bounce categories, complaints, unsubscribes, opens and clicks. It also provides rate metrics, which makes it possible to monitor sender-health ratios directly rather than recalculating every numerator and denominator from event logs.
Dimensions make sender reputation operationally inspectable
Results can be grouped by time period, sending domain, broadcast or email. That lets a team distinguish an account-wide change from a single domain or campaign and build hourly or longer-term trend views. Resend says the requested start date can extend as far back as the account retains data.
The API is designed for dashboards, reports and alerts
Resend explicitly positions the endpoint for custom deliverability dashboards, campaign reports and alerts when bounce or complaint rates spike. Its launch example also shows an agent using Resend MCP to plot reputation metrics against Gmail/Yahoo thresholds. The useful boundary is that the API supplies measurement; policy decisions about when to stop a campaign or change a sending domain still belong to the application or operator.
Aggregated metrics complement, rather than replace, event processing
Teams that already consume delivery and bounce webhooks still need those events for recipient-level state, suppression handling and application workflows. The metrics endpoint serves a different purpose: aggregated monitoring and analysis. A resilient email system can use webhooks for state transitions and the metrics API as a second operational view that detects rate-level drift or anomalous patterns.