Developer Email API.
HTTP on top of a stack from 2014.
Developers do not want to configure SMTP servers. They want a clean HTTP API, a sane SDK, and email that lands. unsent.dev is the API we built for that. It rides on the same delivery infrastructure that powers our Outbound SMTP relay and Shell EmailRouter, the SMTP backbone DuoCircle has been operating since 2014. The difference is shape. SMTP for the systems teams who already speak that protocol; HTTP-first for the application developers who would rather not.
New product, mature stack underneath
unsent.dev is part of DuoCircle's broader Deliver group. It is the HTTP-first sibling to Outbound SMTP. Same routing, same reputation management, same throttling and queueing on the way out. The mail goes through the same pipe; only the shape on top changes.
The reason this product exists is the same reason most of our products exist. A customer asked for something the existing options did not quite fit, and we said yes and built it. That makes unsent.dev emerging: pre-revenue, in production, real product, not vaporware. The stack underneath has been running for over a decade. The surface on top is new.
The shape developers actually want
A clean HTTP API for transactional sending, on top of the SMTP backbone we have been running since 2014. No SMTP configuration, no connection pool, no proprietary lock-in. Built and supported by the same team.
HTTP-first interface
A single request, a clean response. No SMTP server configuration, no connection pool tuning, no relay credentials buried in a config file. Application code calls an HTTP endpoint, the message goes out. The shape developers actually want.
Mature delivery infrastructure underneath
unsent.dev rides on the same SMTP backbone DuoCircle has been operating since 2014. Same routing, same reputation management, same throttling and queueing that powers Outbound SMTP and Shell EmailRouter. The product on top is new; the stack underneath is not.
Built for transactional patterns
Password resets, receipts, system notifications, account events. The kind of email that has to land, gets called from application code, and never sees a campaign tool. unsent.dev is shaped for that traffic. Not a marketing platform with an API stapled on.
Sibling to Outbound SMTP, not a replacement
Same delivery stack, different shape on top. SMTP for the systems and operations teams who already speak that protocol; an HTTP API for the application developers who want a cleaner interface. Pick the surface that matches your team. The mail goes out the same pipe either way.
Direct line to the team that built it
The developer who shipped the API endpoint answers the support email when something looks off. No SDR funnel between you and the person who can change the behavior or fix the bug. The relay-side relationship comes with the API.
The audience
- Application developers shipping transactional flows (password resets, receipts, system notifications) who want HTTP, not SMTP, on top
- Teams already using DuoCircle's Outbound SMTP that want a cleaner interface for some workloads while keeping the same delivery infrastructure
- Developers who want the relay-side relationship: engineering support, no SDR funnel, infrastructure-aware help when something goes sideways
- Early adopters who would rather work with the team that runs the underlying mail infrastructure than build on a generic API black box
- Teams whose volume profile makes the established names overpriced for what they actually need
Emerging product, decade-old infrastructure
unsent.dev is earlier in its public arc than the established names in transactional email. We are not pretending otherwise. If you need a battle-hardened API with a long public track record and a giant SDK matrix today, the established names are a more conservative choice. That is honest comparison, not us selling against them.
What unsent.dev offers in exchange is the relay-side relationship. The mail rides on infrastructure that has been in production since 2014, supporting tens of thousands of organizations across the rest of the DuoCircle portfolio. The team that built the API answers the support email. When you ask why a message landed where it did, the answer comes from the people who can actually trace it through the SMTP path.
We are not the right answer if
You need a long, public, audit-ready track record for a transactional email API today. The established names in transactional email have it; unsent.dev is earlier in its public arc. If procurement requires three years of public uptime data and a multi-language SDK matrix on day one, use one of those. Come back when an emerging option is acceptable.
Your traffic is bulk marketing or campaigns. Different primitive, different platform. See Cold Email Outreach for outbound prospecting through your own mailboxes, or a marketing-campaign tool with templates and list management for newsletters. unsent.dev is for transactional traffic.
You want SMTP, not HTTP. Use Outbound SMTP directly. The API and the relay are siblings on the same delivery stack, not replacements. Pick the surface that matches your team. The mail goes out the same pipe.
An expert on the call, not an SDR working from a script
When you contact us about the Developer Email API, you talk to someone who has actually traced messages through the SMTP backbone underneath. We tell you whether unsent.dev fits your use case today, whether SMTP is the better surface for what you are building, and where the established names are a safer choice for your risk profile.
Honest answer or no answer. Become a customer at whatever shape fits and let us help with whatever email problem comes up next.
Talk to an expert about your sending architecture
Same-day response. Real expert on the call. We tell you whether HTTP, SMTP, or one of the established names is the right answer for your traffic.