Announcements from your own domain.
Send product updates and announcements through the same API and the same verified domain as your transactional mail, with templates, suppression, and one-click unsubscribe handled on every send.
A send, and the compliance headers with it.
Associate the send with an unsubscribe group and the message goes out carrying the one-click unsubscribe headers Gmail and Yahoo check for on bulk senders, from the domain you already verified for your product email.
POST https://api.samva.app/v1/messages
{ to: [{ email: "ada@example.com" }],
channel: "email",
email: { templateId: "product-update",
unsubscribeGroupId: "unsub_announcements" } }
← { id: "msg_01hv8kq2", status: "pending" }List-Unsubscribe: <https://mail.example.com/unsubscribe/…>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
# RFC 8058, checked by Gmail and Yahoo on bulk sendersOne send a month shouldn't need its own stack.
A second vendor for one send a month.
A whole marketing platform, with its own domain setup and its own template editor, exists to send one product update.
Unsubscribe and compliance overhead.
Building List-Unsubscribe headers, a suppression endpoint, and DMARC alignment from scratch is a project of its own for mail you send once a month.
Newsletter reputation bleeds into product email.
Share a sending identity between announcements and password resets, and a rough sending week can drag your account-critical mail down with it.
Same API, versioned content, compliance per send.
The same API, the same domain.
An announcement goes out through the same POST /v1/messages call and the same verified domain as your password resets and receipts. No second sending identity to authenticate.
POST /v1/messages
# password reset -> { email: { templateId: "password-reset" } }
# announcement -> { email: { templateId: "product-update" } }
# one endpoint, one verified domainThe announcement is a versioned template.
Write the release notes or the update once, publish it, and send by referencing the templateId. Pass templateData for the parts that change between releases.
template product-update
v4 draft edited 2h ago
v3 published pinned
v2 archived
v1 archived
send { templateId: "product-update", templateData: { release: "2026.7" } }Suppression and unsubscribe, handled per send.
Pass an unsubscribeGroupId on the send. A recipient who already opted out is skipped, and the message carries the List-Unsubscribe headers RFC 8058 requires.
send { unsubscribeGroupId: "unsub_announcements" }
← skipped: already unsubscribed
# List-Unsubscribe headers attached to every send in the groupUnderstand the split before you send.
Questions about sending announcements.
How is RFC 8058 handled?
Pass an unsubscribeGroupId on the send call, the same field documented in the SDK reference. The message carries the List-Unsubscribe and List-Unsubscribe-Post headers RFC 8058 requires, the one-click flow Gmail and Yahoo check for on bulk senders.
What does suppression do?
Bounces and complaints suppress automatically on every send, the same behavior your transactional mail already relies on. Associate a send with an unsubscribe group and a recipient who already opted out of that group is skipped rather than sent to again.
Should newsletters send from a subdomain?
It's a reasonable default. Mailbox providers track reputation per sending domain, so a subdomain like news.example.com keeps a rough announcement week from touching the reputation your password resets and receipts depend on. You verify it the same way as any other domain.
How do templates take data?
Reference the template by templateId on the send and pass templateData with the values specific to that release: a version number, a feature name, whatever the template expects. The published version renders with your data filled in.
Send the next update from your own domain.
Create a key and send a templated announcement in minutes.