Transactional email for your apps

Let one of your deployed applications send transactional email (sign-up confirmations, password resets, receipts) through the platform — no SMTP account and no vendor API key. You bind email to an app much like a database: bind, and the env vars appear in the app.

Mail is sent from your app's own domain once that domain is verified; until then it falls back to the platform's own sender, so nothing is blocked while DNS propagates.

How to bind

In the application's environment, use Create Service → Transactional Email, then:

1. Pick the application that sends mail.
2. Env var prefix — e.g. MY_APP. We inject the keys your app reads:
   • MY_APP_EMAIL_HUB_URL — the send endpoint (a platform proxy URL, not a vendor's).
   • MY_APP_EMAIL_HUB_TOKEN — a token scoped to this app alone.
   • MY_APP_EMAIL_PROVIDER — optional transport selector (see below).
3. From name — what recipients see next to the address (defaults to the app's name; editable later without a redeploy).

Confirm, and the app redeploys to pick up the new variables.

The transport selector (…_EMAIL_PROVIDER)

If your app picks its mail transport from an environment variable, the dialog lets you say so and choose the value it is set to. See Application Email → The transport selector.

Managing a binding

From the app's Transactional Email service card:

• Rotate — mints a new token, invalidates the old one immediately, and redeploys. Use it if a token leaks.
• Change the From name — takes effect on the next send, no redeploy.
• Unbind — revokes the token and removes the env vars.

Branded sending

Mail is branded from your app's domain once the domain is verified (the platform publishes/uses the right DNS for signing). Until then, sends use the platform's fallback sender so your app keeps working. Verifying a domain is covered in the domain guide.

Your token is a bearer credential scoped to this one app — it is masked in the UI behind a reveal, and rotating it is the way to revoke a leak.