Use case · Transactional

Event-driven email automation for developers

Receipts, password resets, magic-links, and system alerts - one REST call per event, delivered through your own provider. No marketing UI in the way, no per-email markup, and a free tier that'll cover an MVP for months.

Why FlowingMail

Why transactional email lives on FlowingMail

Transactional email is code infrastructure, not marketing. FlowingMail treats it that way: predictable API, versioned templates, observable sends, and a pricing model that doesn't surprise your CFO.

Event-driven: one POST per transaction (checkout.completed, password.reset.requested, etc.)
Bring your own provider - SES for volume, Resend for modern DX, SendGrid for dedicated IPs
Templates are versioned - roll back a broken template in one click
Every send is logged with full payload - reproduce a bad email in 30 seconds
Idempotency keys prevent duplicate sends on retry
Startup-friendly: free plan covers early traffic, Startup tier at $14/mo handles most seed-stage apps

Capabilities

Transactional patterns, pre-modeled

Drop these into your app, wire up the webhook, done.

Password reset & magic-link

One template with a secure token variable, triggered from your auth layer. Rate-limited per contact so abuse doesn't melt your inbox.

Order / subscription receipts

Forward Stripe / Paddle / Lemon Squeezy webhooks - FlowingMail renders the receipt template and sends via your chosen provider.

System alerts & notifications

'Your backup failed', 'New team member added', 'Export ready'. Low-volume, high-trust sends that need perfect deliverability.

Digest & summary emails

Daily / weekly digests aggregating events from your app - built as a scheduled flow with a template-driven payload.

Security-critical delivery

TLS-verified SMTP, DKIM signing on your domain, bounce/complaint classification - zero dependency on a shared IP pool.

Event webhooks in

Receive Stripe / Clerk / Segment / your-own events. Every event becomes a trigger on the FlowingMail canvas.

How it works

Three steps to live transactional email

Connect a sender

Paste your provider's API key (Resend, SES, SendGrid, Mailgun, or SMTP) and verify your sending domain.

Create a template

HTML + plain-text, with {{ variable }} placeholders. Name it after the event you'll fire.

Call the send API

One POST per event. FlowingMail templates the payload, enqueues the send, and records the result.

Integration

Send a transactional email in one call

The simplest possible integration. For more complex flows (conditional sends, delays, retries) wrap the same template in a workflow.

// Called from your Next.js route handler after Stripe checkout
await fetch('https://api.flowingmail.com/v1/emails', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.FLOWINGMAIL_API_KEY}`,
    'Idempotency-Key': `receipt:${session.id}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    from: '[email protected]',
    to: [session.customer_email],
    subject: 'Your receipt',
    templateId: process.env.RECEIPT_TEMPLATE_ID,   // tmp_xxx
    variables: {
      first_name: session.customer_details?.name ?? '',
      order_id: session.id,
      amount: formatCurrency(session.amount_total, session.currency),
    },
    tags: ['receipt'],
  }),
})

FAQ

Transactional email - FAQ

Yes. Many teams start this way: a single template (password-reset) and one API call. The workflow engine is optional - you can treat FlowingMail purely as a transactional API with better tooling than raw Resend/SendGrid.

Pass an Idempotency-Key header. FlowingMail keys the send on (api_key, key) for 24 hours - repeat calls with the same key return the original send without delivering a duplicate.

FlowingMail enqueues the send and returns in ~50ms (p99). Actual delivery depends on your provider (Resend p50 ~1s, SES p50 ~2s). For strictly synchronous delivery, we expose a ?mode=sync option that waits for the provider's 2xx.

Yes. Every template edit creates a new version. The send API takes an optional template_version param - omit it and you get the latest, or pin to a specific version for safer rollouts.

Yes. Per-contact rate limits prevent sending the same template twice within N seconds (configurable per template). Useful for password-reset abuse and retry storms.

Every send is logged with the full request payload, response, provider message-id, and event timeline (queued → sent → delivered → opened → clicked). Stream logs to Datadog / Axiom / your S3 bucket via the logging API.