// use case · transactional

Transactional email that just arrives.

Password resets, one-time codes, receipts, alerts — the mail your product can't afford to drop. One REST call (or SMTP, or a typed SDK), signed webhooks back on every state change, and automatic suppressions so a hard bounce is never mailed twice.

Free sandbox to integrate · Production from $3/month

Pixel-art scene: a cream winged envelope-plane lifting off a labelled pixel express runway with a one-time code glowing on its face, a dotted pixel flight arc curving to a pixel mailbox while a signed receipt drops back down — a faint bulk queue held to one side, over a pale-blue pixel sky with pixel clouds.
// the job

The email your users are waiting for — sent, tracked, never double-sent.

Transactional mail is the email that has to work: the code that logs someone in, the receipt that confirms a charge. It rides its own lane on Drin, kept clear of bulk so a marketing blast can never slow a password reset.

You send it however you write — REST, SMTP, or the Node/Python SDKs — and Drin tells you what happened on a signed webhook: sent, delivered, bounced, complained. Hard bounces and complaints land on your suppression list automatically, so the next send already knows.

REST · SMTP · SDKsSigned webhooksAuto-suppressionsFrom $3/mo
#01 — How it works

One call. Then you know what happened.

POST an email and get an id back synchronously; the delivery outcome arrives moments later on your webhook, HMAC-signed and ordered. The same feed shows in the dashboard — no polling, no guessing.

Read the docs
send · POST /v1/emails
curl -X POST https://api.drin.run/v1/emails \
  -H "Authorization: Bearer drin_k_…" \
  -d '{
    "from":    "you@yourapp.com",
    "to":      "sarah@gmail.com",
    "subject": "Your sign-in code",
    "html":    "<b>482910</b>"
  }'

# → 200 · id: em_8f2… · then webhook: email.delivered
#02 — What you get

The three that make it work.

DRIN · TRANSACTIONAL EMAIL — WHAT YOU GETSHEET OF 3
01.1Every state, signed

sent, delivered, bounced, complained — each transition posts to your endpoint HMAC-signed, so you verify it came from Drin before acting.

01.2Suppressions that stick

Hard bounces and complaints suppress automatically. You never mail a dead address twice, and your reputation stays clean.

01.3Templates, versioned

Author once with merge fields, send by id from API, CLI or an agent — the content team edits copy without a deploy.

#03 — Built from

The surfaces that power it.

Not a bolt-on — this job runs on the same platform as everything else you send and receive. One account, one bill.

#04 — Questions

Asked about transactional email.

How do I know an email was delivered?+

Every send fires webhook events — sent, delivered, bounced, complained — signed with an HMAC so you can trust the source. The same timeline shows in the dashboard activity feed.

Do I have to use the API?+

No. Anything that speaks SMTP speaks Drin — point your framework's mailer (Nodemailer, ActionMailer, Django, Laravel) at our relay and every send lands in the same feed with the same webhooks and suppressions.

Will marketing sends hurt my transactional reputation?+

No. Transactional and marketing ride separate lanes on Drin, so bulk behavior never touches the mail your users are waiting on.

What does it cost?+

Volume-only pricing from $3/mo. You pay for the email you send — no per-seat fee, no per-message overage games.

Every job Drin is hired for