Product email for SaaS teams.
Send password resets, receipts, and plan-change notifications through one typed API, then watch delivery status update as signed events land in your own systems instead of a dashboard you have to check by hand.
One call out, a signed event back.
A typed send call returns a message id right away. When the recipient's provider confirms delivery, Samva calls your webhook with a signed event, so your product database updates itself instead of a background job polling for status.
POST https://api.samva.app/v1/messages
{ to: [{ email: "ada@example.com" }],
channel: "email",
email: { subject: "Your plan changed",
templateId: "plan-changed" } }
← { id: "msg_01hv8kq2", status: "pending" }POST /webhooks/samva
X-Webhook-Signature: sha256=9f2ab1c4...
{ event: "message.delivered",
messageId: "msg_01hv8kq2",
data: { channel: "email", status: "delivered" } }Product email is a stack nobody signed up to own.
A send call, a template engine, and a thread tracker, glued together.
Password resets go through one library, receipts through another, and you're the one reconciling what "delivered" means across both.
Product email is scattered across services.
Every service that sends mail keeps its own copy of the same HTML and its own retry logic, so a subject line change means hunting through several repos.
Deliverability is a chore nobody scheduled.
SPF, DKIM, and DMARC records need attention as domains change, and a stale record shows up as a support ticket instead of a warning.
One call, a version, a signed event.
One call replaces the stack.
Call one typed endpoint with a recipient and either inline content or a templateId. Samva returns a message id and status before your request finishes.
const { data } = await samva.email.send({
to: "ada@example.com",
subject: "Your plan changed",
templateId: "plan-changed",
});
← msg_01hv8kq2 · pendingContent lives in one place, versioned.
Move the HTML into a template once. Publish a version, and every send that references the templateId renders whatever version is pinned, with rollback if a bad one ships.
template plan-changed
v4 draft edited 2h ago
v3 published pinned
v2 archived
v1 archived
send { templateId: "plan-changed", templateData: { plan: "Growth" } }
# the pinned version is the version that sendsDelivery becomes an event in your system.
Register a webhook for message.delivered and message.failed. Every request is signed with HMAC-SHA256, so you verify it before your product database updates.
POST /webhooks/samva
X-Webhook-Signature: sha256=9f2ab1c4...
{ event: "message.delivered",
messageId: "msg_01hv8kq2" }
verify: timingSafeEqual(signature, hmacSha256(secret, body))See the pieces up close.
Questions from engineering leads.
Migrating from Resend or SendGrid?
Migration is scoped to email. Point your integration at a Samva API key, and the send call takes the same shape: a recipient, a subject, and either inline HTML or a templateId. Versioned templates and signed webhooks replace whatever you built or bolted on to get equivalent behavior out of your previous provider.
How does threading change the data model?
A reply doesn't need a table you maintain. Every inbound message carries a conversationId that ties it to the outbound send it answers, and you fetch the full thread from the conversations API instead of stitching a thread_id together yourself.
What about EU GDPR?
Transactional email like a password reset runs on a different legal basis than marketing, performance of a contract, so it needs no consent checkbox. When you send marketing from the same account, unsubscribes and complaints feed the same automatic suppression list Samva already runs for bounces, so consent stays enforced without a separate tool.
How does volume pricing work?
Each plan ships a fixed monthly allowance and the full email surface at every tier, so upgrading changes your volume, not your capability. Send past your allowance and the extra messages settle on your invoice as itemized overage instead of a hard cutoff dropping a send.
Send your next product email in minutes.
Create a key and send a typed call instead of maintaining a stack.