Skip to content
Stampwing
Early access is on the way

Email for your
websites and apps

We’re building a transactional email API for developers. Send password resets, receipts, and notifications, with templates and delivery tracking in one workspace.

Stampwing atlasIllustrative preview

atlas

Sample · Last 24 hours
Accepted
13.4k
Queued
330
Bounce rate
0.18%
Queue latency
339 ms
Example project Domain verified
API requestsProject-scoped API keys
Email queueAWS us-east-1
Worker 01us-east-1
Worker 02us-east-1
Worker 03us-east-1
Worker 04us-east-1
Send latency p50 · 180 ms
Explore a sample project. Sample data · No emails sent

Your projects, organized.

Give each app its own project, with domains, API keys, and message history together.

Build the whole flow.

Create email templates and choose when your app sends them.

Know what happened.

See which messages are queued, accepted by the receiving server, or need attention.

THE EVERYDAY ESSENTIALS

Transactional email for everyday app events.

Help people verify an account, recover access, or keep a receipt. Start with free HTML and plain-text templates you can adapt to your app.

UNDER THE HOOD

An email API for your backend.

An HTTP API for your backend, a durable queue for your messages, and delivery events you can follow back to your app.

Architecture preview
Live API coming soon
  1. 01
    Your backendHTTP + JSON
  2. 02
    Stampwing APIValidate and queue
  3. 03
    PostgreSQL outboxStore before sending
  4. 04
    Worker + AWS SESSubmit for delivery

202 Accepted means the message is queued. Delivery status comes later; acceptance by a receiving server doesn’t confirm inbox placement.

REST API and TypeScript SDK.

Send with POST /api/v1/emails from any server language, or use the server-side TypeScript SDK. Reuse an Idempotency-Key with the same payload to retry a request without creating another message.

Project keys and Test/Live separation.

Bearer API keys belong to a project and a Test or Live environment, with separate send and read permissions. Keep them on your server. Test sends are simulated and never reach real recipients.

A durable PostgreSQL queue.

PostgreSQL stores the message and queued event together. Workers check domain verification, sending limits, and suppressions before calling SES. An uncertain submission is flagged for review.

Signed delivery webhooks.

Look up a message by ID or receive signed webhooks with delivery updates. SES feedback flows through SNS and SQS; permanent bounces and complaints add recipients to suppression lists.

Versioned templates and workflows.

Preview HTML and plain-text email, validate workflow drafts, and simulate flows without sending. Published versions are immutable; existing runs keep their pinned workflow and template versions.

Encryption and domain authentication.

Stored message bodies use AES-256-GCM encryption. Verify domain ownership and configure SPF, DKIM, and DMARC. Rate limits, sending allowances, and recipient suppressions also apply.

SECURITY IN THE APPLICATION

Clear boundaries around your email.

These controls are implemented in the application architecture. Customer accounts, live sending, and hosted MCP access are still being prepared for launch.

Encrypted message storage
Stored message bodies use AES-256-GCM with a fresh nonce and authentication tag. This protects stored content; it isn’t end-to-end email encryption.
Scoped, revocable API keys
API keys are stored as hashes, scoped to a project and environment, and checked for permissions, expiry, and revocation.
Authenticated webhooks
HMAC-SHA256 signatures cover the event ID, timestamp, and original body. HTTPS destinations are checked against private network addresses.
Controls before a live send
Domain verification, sending limits, recipient suppressions, and abuse suspensions gate delivery. Live mode requires authentication, encryption, a database, and SES configuration.
THE STACK
  • Next.js
  • TypeScript
  • PostgreSQL
  • AWS SES

The live service is in development. Try the local demo below today.

Try the request flow locally

Download the local API fixture and run node email-mock-server.mjs with Node.js 22+. Then send the request below. The fixture keeps data in memory, needs no API key, and sends no email.

Local demo · no email sentshell
curl http://127.0.0.1:3027/api/v1/emails \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: receipt-42" \
  -d '{"to":"reader@example.test","subject":"Your receipt","text":"A simulated receipt"}'
A FEW THINGS TO KNOW

Transactional email, explained.

What is a transactional email API?

It lets your backend request an email when something happens in your app, such as a signup, password reset, or payment. Your app sends the message details over HTTP and uses a message ID to follow its progress. How a transactional email API works →

Can I use Stampwing’s live API today?

Not yet. The live service and customer accounts are still in development, and we haven’t announced a launch date. You can use the free templates, guides, header analyzer, and simulated local API example now. Explore the free developer resources →

Will Stampwing connect to Claude, ChatGPT, and Codex through MCP?

Yes—that’s part of the integration we’re building. MCP lets an assistant work with the tools and data you authorize. Stampwing’s connector includes template previews, workflow drafts, and run inspection, with separate permissions for reading, editing, and publishing. The hosted connection is coming soon. Explore the MCP integration preview →

How do I send email from a Next.js app?

Call the email API from your server, keep API keys out of browser code, and save the returned message ID. Our Next.js guide walks through this request flow with a local fixture that sends no real email. Try the Next.js email example →

How do I prevent duplicate emails on a retry?

Give each logical send an idempotency key and reuse it with the same payload when retrying. A timeout doesn’t prove that a request failed. Reconcile the original message before creating a new one. Learn about email retries and idempotency →

What do SPF, DKIM, and DMARC do?

SPF identifies authorized sending servers, DKIM adds a verifiable signature, and DMARC checks alignment with the visible From domain and publishes a handling policy. They help authenticate email; they don’t guarantee an inbox placement. Understand sending-domain authentication →

Does “accepted” mean an email reached the inbox?

No. Stampwing uses “accepted” for receiving-server acceptance. The recipient’s mail system may still filter or quarantine the message. Follow the delivery events and inspect the recipient-side evidence before sending again. Troubleshoot a missing transactional email →

USEFUL BEFORE YOU EVEN SIGN UP

Email guides, tools, and templates.

Practical answers for the email behind your app.

Explore the resources
DELIVERABILITY

Delivered, but not in the inbox?

Trace a missing message and find the next useful step.

Read the guide
YOUR NEXT APP

One email setup. Several projects.

A repeatable checklist for domains, keys, and environments.

Get the checklist
FREE TO MAKE YOUR OWN

Good emails. A head start included.

Four everyday templates, in HTML and plain text.

Browse templates
A clearer home for your app’s email

Better email days ahead.

Join the waitlist. We’ll let you know when you can get started.

Join the waitlist