Change Log

The GET /v1/outgoing list endpoint is more forgiving about its filter parameters:

• environment and template accept either the document id or the slug (for example ?environment=live)
• An unknown environment or template answers with a 400 instead of a server error
• Single-value query parameters on all list endpoints may also be passed in the bracketed form some HTTP clients emit, e.g. ?environment[]=live

Base64 encoded images in a template (for example a data:image/png;base64,… logo) are no longer sent inside the email body:

• Each image is stored once as a separate MIME part and referenced by content id from the html and watch html parts
• The plain text part references the same attachment by content id instead of carrying the base64 payload
• An image that is used multiple times in a template is only attached once

MJML templates can now pull in a snippet with MJML's own include syntax:

• <mj-include path="partials/theme.mjml" /> resolves to the same snippet as @@partials/theme@@ — the path without its .mjml extension is the snippet slug
• Both spellings behave identically, including the rule that an unknown snippet is replaced with an empty string
• <mj-include> is only resolved for MJML templates

You can now receive email as well as send it — incoming messages are parsed and delivered to your app via webhooks:

• Bind a domain to an incoming config to start receiving mail; messages are parsed into subject, from/to, headers, text, and HTML
• Attachments are extracted and stored, with download URLs for the raw message and each attachment
• An incoming.email.received webhook is delivered for each message, carrying the full parsed payload
• View received emails in the dashboard, including a raw message download, text body, and full header inspection

Template variables can now be marked as protected to keep sensitive values out of the dashboard and API:

• Tick the protected checkbox next to a variable in the template editor
• Protected values are masked as *** — both in a sent email's parameters and anywhere they appear in the rendered subject, HTML, or text
• The real value is only ever used to render the delivered email; it is never returned by the dashboard or the /v1/outgoing API
• Protected variables stay visible for sandbox sends, so you can still debug them while testing

API keys can now be restricted to specific permissions, so a key only grants the access it needs:

• Send — send email via POST /v1/send and read delivery status
• Templates — manage templates over the /v1/templates API
• Outgoing — read sent-email content and status via GET /v1/outgoing
• Pick permissions when creating or editing a key; existing keys keep full access until you restrict them

You can now browse and inspect sent emails over HTTP with your API key (requires the outgoing permission):

• GET /v1/outgoing lists sent emails newest-first with cursor pagination and optional environment, status, template, templateSlug, and recipient filters
• GET /v1/outgoing/{id} returns a single email's rendered content — subject, HTML, text, parameters, and attachments
• GET /v1/outgoing/{id}/status returns its delivery status (the earlier /v1/outgoing/status/{id} path keeps working)
• All routes are documented in the OpenAPI reference at /docs

Templates can now be managed entirely over HTTP with your API key — no dashboard required:

• GET /v1/templates lists your templates with cursor pagination and optional slug, group, and snippet filters
• POST /v1/templates creates a template; GET /v1/templates/{id} fetches a single one
• PATCH /v1/templates/{id} updates metadata, and providing any content field publishes a new version
• DELETE /v1/templates/{id} removes a template
• All routes are documented in the OpenAPI reference at /docs

You can now group your email sending into projects, with billing handled separately by billing accounts:

• Projects are separate workspaces — each with its own templates, sending, and members — so you can keep teams, brands, or clients apart
• A billing account can own one or more projects, letting a single payer group several workspaces under one subscription
• Invite teammates to an project by email, with admin or readonly roles

Templates can now be cloned directly from the template list:

• Click the copy icon on any template to create a new template pre-filled with all settings from the original
• The clone copies name, slug, content, variables schema, discriminator rules, and group assignment
• The cloned template name is suffixed with (Copy) to distinguish it from the original

Templates can now be marked as Snippets — reusable content blocks that can be embedded in other templates:

• Include a snippet in any template by writing @@slug@@ where slug is the snippet's slug
• The snippet and the template it is used in must share the same type (e.g. both MJML, both React Email)
• If no matching snippet is found the placeholder is silently removed, so @@slug@@ will never appear in a delivered email
• Snippets cannot be sent directly via the API

The send API now supports file attachments:

• Pass attachments in the POST /v1/send request body
• Each attachment requires a filename and base64-encoded content
• Optional fields: disposition and content_id for inline attachments

New HTTP endpoint to check the delivery status of a sent email:

• GET /v1/outgoing/status/{ID} returns the current status and whether the email was opened

New Template processor for React Email Version 5

• All Components from https://react.email/docs/components are available
• Parameters are passed to template for react rendering
• Tailwind enabled by default

Several improvements have been made to template management:

• Introduced final identifier for discriminator selection
• Added enabled flag for templates

We are now rendering a preview for emails, showing different device categories with the ability to zoom. Previews are availabe for:

• Templates
• Outgoing Emails
• Incoming Emails

Any Environment can now configure SES to deliver emails by providing

• Region
• Access Key ID
• Secret Access Key