SMTP

Connection settings

SMTP is a first-class way to send with Email Bump, not a shim. If a tool has a host, port, username and password field, it can send through you — your own application, a framework's mailer, a CMS, a helpdesk, CI, monitoring and alerting, a CRM, or a desktop mail client.

Mail sent this way goes through the same checks and the same log as the API: it appears under Transactional with opens, clicks and bounces attached, counts against the same allowance, and obeys the same sending-domain rules. Nothing is second class about it.

TLS is required. The server does not offer AUTH until the connection is encrypted, so a misconfigured client cannot send your key in the clear.

The From address must use one of your verified sending domains — the same rule the API follows. Before you have verified one, the shared testing domain works so you can try things out; once you verify your own, the shared domain is no longer accepted, because its reputation is pooled across every workspace and mail from it delivers worse than mail from you. Messages may be up to 40 MB, attachments included.

Which project does it send from?

A project key is bound to one project, so there is nothing to choose: leave the username as emailbump. An all-access key is not bound to one, and is resolved in this order:

• If the owner belongs to a single project, that one — nothing to configure.
• Otherwise the From domain decides. A verified domain belongs to exactly one project, so hi@acme.com can only mean the project that verified acme.com.
• If that still doesn't settle it — every project is on the shared testing domain, which is identical everywhere — put the project id in the username:

Username: 111f9258-6b77-4edb-a9f3-14bc66118b14
Password: ebk_your_key

You are only ever asked for the username in that last case, and the error names your projects and their ids so you can copy one across.

Connect your app

The same four settings everywhere. These are the ones people ask for most; anything else with an SMTP box works the same way.

WordPress (WP Mail SMTP)

Mailer:      Other SMTP
SMTP Host:   smtp.emailbump.com
Encryption:  TLS
SMTP Port:   587
Auth:        On
Username:    emailbump
Password:    ebk_your_key

Django

# settings.py
EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.emailbump.com"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "emailbump"
EMAIL_HOST_PASSWORD = os.environ["EMAILBUMP_API_KEY"]
DEFAULT_FROM_EMAIL = "Acme <hi@acme.com>"

Rails

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:              "smtp.emailbump.com",
  port:                 587,
  user_name:            "emailbump",
  password:             ENV["EMAILBUMP_API_KEY"],
  authentication:       :plain,
  enable_starttls_auto: true
}

Node.js (Nodemailer)

const transport = nodemailer.createTransport({
  host: "smtp.emailbump.com",
  port: 587,
  secure: false, // STARTTLS is negotiated on 587
  auth: { user: "emailbump", pass: process.env.EMAILBUMP_API_KEY },
})

Supabase

Supabase is configured through its dashboard rather than code, and has a few specifics of its own — sender address, rate limits and its built-in templates. It has its own guide: Supabase.

Send a template

Normally the message you hand us is the message we send. If you would rather keep the design in Email Bump, send JSON naming a saved template instead of an email body, and we render it:

{
  "template_id": "d3d04286-d773-4d06-acfd-7ee983108f0b",
  "variables": { "first_name": "Kevin", "url": "https://acme.com/confirm/abc" }
}

The template supplies the subject, so the Subject: header is ignored for these. transactionalId and dataVariables are accepted as aliases, so payloads written for Loops work unchanged.

Troubleshooting

Replies say what went wrong rather than a bare code.

Every attempt is recorded, successes and failures alike, so the transactional log is the fastest way to see what a client actually sent.