Keep it running
Sending email from your app — without owning a mail provider
A confirmation, a receipt, a password reset. Sending mail properly usually means an account somewhere, a domain to verify and a key to keep safe. Here it is one command and a POST.
Add it
Your app restarts with EMAIL_API_URL and EMAIL_API_KEY in its environment. That key is yours alone and is minted per app.
Send one
POST to that URL with the key in the header and a small JSON body — to, subject, and html or text. Any HTTP client in any language; there is nothing to install.
What your app never holds is the provider's own credential. Mail goes out through the platform, which means a key stolen from your code can send email on your allowance and cannot touch anybody else's — and swapping the provider underneath is not a change you have to make.
The allowance
Plan | Messages a month |
|---|---|
Free | no email add-on |
Hobby | 500 |
Pro | 2,000 |
Max | 5,000 |
Per month and per account, not per app. Over it, the send is refused with a 429 rather than being silently dropped — a mail that does not arrive and a mail that was never accepted are very different things to debug.
The two limits worth knowing
Fifty recipients per message, counting to, cc and bcc together. Providers disagree about how to count those; the total is enforced because it is the only reading that is true of both, and your app must not start failing on the day the provider underneath changes.
Ten attachments, 7 MB decoded. The limit is on the real bytes rather than the encoded ones, because base64 inflates a message by about a third and the provider's ceiling applies after that.
What it is not for
A newsletter. This is transactional mail — something a person did causes one message. Bulk sending needs list management, unsubscribe handling and a reputation you own, none of which is here, and running a campaign through a transactional path is how a shared sending reputation gets spent.