Email Bump
Start For Free Join With Google
All features

Transactional & SMTP

Product email over an API or plain SMTP

Receipts, password resets, confirmations and alerts — sent over an HTTP API or a real SMTP server, whichever your application already speaks. Both share one log, one set of sending domains and one allowance.

The problem

Product email usually ends up somewhere separate from marketing email: a second vendor, a second domain to authenticate, a second set of deliverability problems, and no single place to answer 'did this customer get their receipt?'.

An API when you're writing code

One POST sends a message. Supply HTML, text or both, or name a saved template and pass variables into it.

curl
curl https://emailbump.com/api/v1/emails \
  -H "Authorization: Bearer ebk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <orders@acme.com>",
    "to": "jamie@example.com",
    "subject": "Your order shipped",
    "html": "<p>On its way.</p>"
  }'

SMTP when you're not

Plenty of software can send email but can't call an API — Supabase Auth, WordPress, Django, Rails, Jira, your CI. Point them at the SMTP server and nothing else has to change.

It accepts ordinary email, so existing templates keep working. Attachments, custom headers and threading pass through untouched.

settings
Host      smtp.emailbump.com
Port      587          # STARTTLS — also 2587, or 465 for implicit TLS
Username  emailbump
Password  ebk_your_key

The same everything, either way

Whichever path a message takes, it lands in the same transactional log with its opens, clicks and bounces attached, counts against the same allowance, and obeys the same verified-domain rules.

Messages that get refused are logged too, with the reason — so 'nothing is arriving' is a question with an answer rather than a support ticket.

What this looks like for you

The events worth sending depend on what you sell. Three shapes of business, the events each one tracks, and the segments those events make possible.

Product email is the mail that has to arrive. Nobody forgives a password reset that took ten minutes, and most of these are sent by code rather than by a marketer.

Messages you'd send

Verify emailSent by your app on signupAPI, or SMTP if your auth library sends it
Password resetTime-sensitive, must arriveAPI
Teammate invitationIncludes a join linkAPI
Receipt / invoiceOften has a PDF attachedSMTP handles attachments untouched
Usage or billing alertTriggered by a thresholdAPI

Why it matters here

Supabase and friends just work

Point their SMTP settings at us

Auth email leaves their shared sender without touching your code

One domain to authenticate

Product and marketing mail share sending domains

You set up SPF, DKIM and DMARC once

Refusals are visible

Rejected messages are logged with the reason

'Customers aren't getting resets' has an answer in the dashboard

What you can build with it

  • One vendor and one authenticated domain for every kind of email
  • Supabase, WordPress or Rails sending through you without code changes
  • A searchable record of every message, including refusals

Try it on your own data

Free while you're under 5,000 contacts, and every feature is on every plan.

Start free