Show HN: I built an email API because of limited domains and flaky inbound

Show HN: I built an email API because of limited domains and flaky inbound(simpleemailapi.dev)

1 points by hamzaawan 125 days ago | 1 comment

I’m an indie hacker. Like many of you, I usually have 3 or 4 projects running at once. My biggest frustration with existing email APIs (the Resends and Postmarks of the world) is how they handle domains.

Most platforms restrict you to a single domain on the free tier, and even the initial paid tiers are surprisingly stingy. Whenever I started a new experiment, I had to "kill" the email for a previous project just to reuse the domain slot. If a user tried to sign up or reset a password on an older project, it was effectively dead.

I built Simple Email API to stop this cycle. I wanted an email API that doesn't punish you for experimenting.

Two things I focused on:

1. Multi-domain by default You can add unlimited domains without being forced into a $20/month plan immediately. I’ve optimized the infrastructure to keep costs low so I can provide affordable pricing. You can keep your old projects alive while you build your next one.

2. Native Inbound (not an afterthought) Most APIs are built for outbound, and inbound feels like a complex add-on. Here, every email is "reply-ready" out of the box.

For Production: We have standard webhooks.

For Prototyping: We have a simplified onReceive callback. If you're building an AI agent or a quick script, you don't want to deal with webhook endpoints and secrets. You can get up and running with just an API key.

The goal is to be the simplest possible way to send and receive emails. I’m looking for brutally honest feedback.

hamzaawan 125 days ago |

I wanted to keep the latency as low as possible, ideally much faster than the typical "enterprise" email APIs. To do that, I built the backend in Go using gRPC and ConnectRPC (Buf).

Because it's built on gRPC instead of just standard REST, you get much better performance and fully typed SDKs. Right now, I have a TypeScript SDK live, and a Go SDK is in the works. But since I’m using Buf, you can basically generate a fully typed client for any language they support.

On Performance & Modes: I’ve implemented two ways to send:

Async (p50 ~34ms): This is for when you just want to fire and forget. You get an instant response, and our infrastructure handles the retries, queuing, and delivery in the background.

Sync: This is for when you need the Message-ID immediately (useful for threading replies or specific logging). You wait for the full handoff, but you get all the data you need for complex inbound flows.

The Plumbing: I’m using Amazon SES for the actual mail delivery to ensure high deliverability from day one. On top of that, I’ve built the logic to automatically handle reputation management, bounces, and complaints. You just add a domain, drop in two lines of code, and you’re done.

I really tried to strip away the "over-engineered" parts of email. No complex CRM-style contact syncing—just a high-performance pipe to send and receive mail.

Happy to answer any questions about the setup!