# Resend Headless Dashboard Initiative The Headless Dashboard Initiative is a design rule [[Resend]] announced on September 22, 2026: > "Everything the dashboard can do should also be available programmatically." In practice, it means feature parity across four surfaces: the web dashboard, the [[Resend MCP Server]], the [[Resend CLI]] and the [[Resend API]] (with its SDKs). Humans and [[AI Agents]] get the same access. Resend frames developers as operators of their email setup, whether they click through the dashboard themselves or let an agent do the work. ## Why Resend did it Resend lists four use cases: - Embedding email analytics inside your own application - Building custom broadcast experiences for your own customers - Managing your Resend account through agents - Building custom dashboards and reports Each of these hits a wall as soon as one action exists only in the dashboard. The agent stops and someone has to log in and click. ## The nine APIs that shipped | API | What it does | |---|---| | Email Metrics API | Deliverability and engagement metrics, with filtering and grouping | | Headless Webhook API | List webhook events, get their payloads, manage delivery attempts, replay events, rotate signing secrets | | Cancel Broadcast | Cancel a broadcast | | Share Email | Create an expiring, read-only link to an email (up to 48 hours) | | Duplicate Automation | Copy an automation; the copy starts as a disabled draft | | Update Segment | Rename a segment | | List Clicked Links | The links clicked in a given broadcast | | Update API Key Name | Rename an API key (the token itself doesn't rotate) | | Duplicate Broadcast | Copy an existing broadcast | The CLI got matching commands: ```bash resend emails metrics resend webhooks events list <id> resend broadcasts cancel <id> resend emails share <id> --expires-in "2 hours" ``` Diel Duarte, Gabriel Miranda and Felipe Freitag are credited on the announcement. ## What's next Resend named two areas: finer API key provisioning and scoping, and webhook filtering. ## My take I strongly believe "headless by default" should be a design principle for every tool in the agent era. When an agent works on my behalf, it can only do what the product exposes programmatically. Every dashboard-only feature is a point where the automation breaks and a human has to step in. Resend writes the fix down as a rule: a feature is complete when it's reachable from the API, the CLI and the MCP server, and the dashboard becomes one client among others. The APIs that shipped are small: renaming a segment, duplicating or cancelling a broadcast, renaming an API key. None of it is flashy, but these are the gaps that stop an automated workflow halfway. The same idea shows up in [[Agent-Native Product Decomposition]] (expose primitives, keep contracts stable) and in Cloudflare's [[Cloudflare CLI]], generated from the API schema so nothing gets left out. What I'd watch: parity is a promise that needs maintaining with every new feature, and agents operating the account make scoped API keys much more important. That scoping is on the roadmap, not shipped yet. ## References - Headless Dashboard Initiative (Resend blog, 2026-09-22): https://resend.com/blog/headless-dashboard-initiative - Resend documentation: https://resend.com/docs - Resend CLI documentation: https://resend.com/docs/cli - Resend MCP server documentation: https://resend.com/docs/mcp-server - API reference: https://resend.com/docs/api-reference/introduction ## Related - [[Resend]] - [[Resend API]] - [[Resend CLI]] - [[Resend MCP Server]] - [[Resend Agent Skills]] - [[Agent-Native Product Decomposition]] - [[Cloudflare CLI]] - [[Software as a Service (SaaS)]] - [[AI Agents]]