Transactional Email

MIOSA uses transactional email for platform notifications and for per-project end-user auth flows such as password reset and email confirmation.

This page separates three different email patterns:

Pattern	Who owns it	Examples
MIOSA-managed auth email	MIOSA/operator	Password reset, email confirmation, security notices
App-owned transactional email	The generated app/customer	Receipts, booking confirmations, workflow notices
Enterprise/private sender setup	MIOSA + customer/operator	White-label sender domains, private SMTP, compliance-bound delivery

What email covers

Flow	Uses this config?	Notes
Project Auth password reset	Yes	Sends a reset link for an end user of a generated app.
Project Auth email confirmation	Yes	Sends a confirmation link after signup when email verification is enabled.
Platform admin/user notifications	Yes	Uses the same Resend API key, with platform mailer settings.
Customer application transactional email	No	Wire the app to its own provider integration or runtime secret.
Customer marketing/campaign email	No	Usually belongs in the customer app or marketing stack, not MIOSA auth.
White-label custom sender domains	Not yet self-service	Requires enterprise/operator work until per-project sender domains are productized.

MIOSA-managed auth email

Set these on the compute service environment, then restart or roll the compute API service so runtime config is reloaded:

RESEND_API_KEY=re_xxxxxxxxxxxx
RESEND_FROM_APP_AUTH="Your App <noreply@yourdomain.com>"

RESEND_API_KEY is required for delivery.

RESEND_FROM_APP_AUTH controls the From address for per-project auth email (password reset and email confirmation). If it is not set, app-auth email defaults to noreply@notifications.miosa.ai.

If Resend is not configured, auth still generates and stores reset or confirmation tokens, but no email is sent. The endpoint returns success and the backend logs email_not_configured instead of crashing the auth flow.

Other provider options

For application-level email, the generated app can use whichever provider the customer chooses. Common patterns:

Provider model	Good for	How it should be wired
Resend	Developer-friendly transactional email	Store the app’s `RESEND_API_KEY` as a project/runtime secret and call Resend from app code.
Postmark	High-deliverability transactional email	Store a server token as a secret; app owns templates and sender verification.
SendGrid	Larger enterprise email programs	Store API key as a secret or enterprise integration; app owns templates/categories.
Mailgun	Domain-heavy transactional email	Store API key/domain as secrets; app owns routing and logs.
SMTP relay	Enterprise/private mail infrastructure	Store SMTP host/user/password as secrets or configure a private deployment path.
Customer-owned service	Regulated or on-prem environments	Scope network path, credentials, audit, and data handling in the enterprise deployment.

The important rule: app-owned providers are not the same as MIOSA’s built-in auth mailer. App email belongs to the application runtime; MIOSA auth email belongs to the platform control plane.

Platform mailer and notifications

The platform mailer also reads the shared RESEND_API_KEY. Platform notifications can have their own From behavior in backend configuration, but for launch verification the key point is simple:

no RESEND_API_KEY -> tokens are generated, email send is skipped
RESEND_API_KEY set -> Resend delivery path is active

Do not treat a successful password-reset API response as proof an email was sent. Check provider configuration, logs, and the provider event dashboard.

Verification checklist

After configuring the env vars:

Enable Project Auth for a fresh project or sandbox.
Create a test end user through {AUTH_URL}/signup.
Call {AUTH_URL}/password-reset for that email.
Confirm the backend does not log email_not_configured.
Confirm the configured provider accepts the message.
Confirm the reset link reaches the inbox and {AUTH_URL}/password-reset/confirm accepts the token.

White-label and enterprise senders

Today the built-in auth mailer is platform-operated. For a white-label or enterprise customer that needs mail from its own domain, scope these items explicitly:

sender domain and DNS records;
SPF, DKIM, DMARC, bounce, and complaint handling;
whether MIOSA sends through a managed provider or the customer’s private SMTP;
per-tenant branding and template ownership;
audit logs and delivery visibility;
whether the setup is cloud, private-network, or on-prem.

Until per-project sender domains are productized, do not promise a dashboard toggle that lets each project configure its own auth sender.

App-owned email

Generated apps can still send their own email by storing provider credentials as project/runtime secrets and calling the provider directly from app code. That is the right path for product emails such as receipts, invites, booking confirmations, reports, or customer-specific notifications.

Enable per-project signup, login, JWTs, password reset, and email confirmation.

Connect app-level services such as Stripe, Resend, Twilio, and webhooks.

Managed databases, storage, Redis, Qdrant, Auth, Volumes, and Fractal.