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.

Connect over HTTP or SMTP. Send with your server language, receive email in your app, and follow each message from the queue to its delivery events.

Implementation preview
Hosted service coming soon
  1. 01
    Your backendHTTP, SDK, or SMTP
  2. 02
    StampwingAuthenticate and validate
  3. 03
    PostgreSQL outboxStore before sending
  4. 04
    Worker + AWS SESSubmit for delivery

An HTTP 202 Accepted response confirms queue acceptance. Delivery status comes later; acceptance by a receiving server doesn’t confirm inbox placement.

REST API and native SDKs.

Send HTML, plain text, and attachments through POST /api/v1/emails. Reuse the same payload and Idempotency-Key when retrying. Explore the OpenAPI reference and SDK source packages for nine languages.

SMTP with separate Test and Live keys.

Connect your existing mail library with mandatory STARTTLS and a project key with smtp:send permission. HTTP and SMTP Test sends are simulated and never reach real recipients.

Batch sending and scheduling.

Submit up to 100 emails in a batch or schedule an email up to 30 days ahead. Reschedule before processing starts, or cancel recipients still awaiting submission. These features require sending rollout to be enabled.

A durable PostgreSQL queue.

Messages and their queued events are stored together before a worker submits to AWS SES. Workers recheck sending permissions, limits, and suppressions. Uncertain submissions are held for review instead of automatically resent.

Signed delivery webhooks.

Follow a message by ID or receive HMAC-SHA256 signed events. Failed webhook deliveries retry for up to 24 hours. Rotate signing secrets and replay an event without resending the email.

Incoming email for your app.

Receive on a verified subdomain with its own MX record, keeping your existing mailbox records intact. Read messages and download attachments through a project-scoped API, with sanitized previews and quarantine for unsafe content.

Versioned templates and workflows.

Preview HTML and plain text, validate drafts, and simulate flows without sending. Published versions are immutable, and existing runs keep their pinned versions. Live workflow execution has a separate rollout control.

Domain checks and sending safeguards.

Check ownership, SPF, DKIM, and DMARC during setup. Supported DNS providers offer guided connection, with manual records always available. Permanent bounces and complaints suppress recipients; quotas, rate limits, and abuse suspensions gate sending.

SECURITY IN THE APPLICATION

Security for your email and your workspace.

Keep access scoped, stored content encrypted, and sensitive changes traceable. These controls are implemented in the application; hosted verification and independent security review are still pending.

Encrypted content at rest
Stored message bodies and saved drafts use AES-256-GCM with versioned encryption keys for rotation. This protects stored content; it isn’t end-to-end email encryption.
TLS for app and database connections
Live setup requires HTTPS. Webhooks and public database connections require TLS 1.2 or newer and verify certificates and hostnames. Explicitly configured private-network database connections may be unencrypted.
TLS for email transport
SMTP requires STARTTLS with TLS 1.2 or newer before authentication. Receiving rules require TLS. Live sending needs proof, less than a minute old, that its SES route requires TLS. Freshness is checked again just before submission. Failed or expired checks keep your email queued with its original expiry.
Workspace and project isolation
Workspace membership, project scope, and credential permissions are checked on requests. PostgreSQL row-level security adds database boundaries between customer workspaces. Test and Live credentials stay separate.
Keys you can replace and revoke
API keys are shown once and stored as hashes. Replace a key without expanding its permissions, check application use, then revoke the original. Immediate revocation is available for a compromised key.
Signed webhooks over HTTPS
HMAC-SHA256 signatures cover the event ID, timestamp, and original body. Delivery checks and pins public destination addresses, blocks private networks, and refuses redirects. Signing secrets support rotation.
Screened incoming content
Incoming attachments must pass screening before download or forwarding. Unsafe messages are quarantined, and HTML previews are sanitized and sandboxed to keep email content separate from your workspace.
Browser protections
A Content Security Policy restricts scripts and framing, with enforcement enabled by default. Browser changes require a matching request origin. Message previews run in restricted frames.
Traceable security changes
Review recent credential, access, and signing-secret changes with actor details, timestamps, and request IDs when available. Successful local changes and their audit records are saved in the same transaction.
Checks before live sending
Live mode requires authentication, encryption, a database, and SES configuration. Domain verification, screening, quotas, suppressions, and abuse suspensions gate sending. Uncertain submissions wait for reconciliation.
SERVER-SIDE SDKS
  • TypeScript / JavaScript
  • Python
  • Go
  • PHP
  • Ruby
  • Java
  • .NET
  • Rust
  • Elixir

Source packages today. Registry publication is still pending.

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