What it is
This module adds transactional email sending to a SpacetimeDB application by connecting it to the Resend email delivery service. It lives inside your database as a submodule, handling outbound email dispatch, delivery tracking, and webhook ingestion so that email state is stored and queryable alongside the rest of your application data.
Where it fits
- User onboarding flows: Send welcome emails when a new account is created and track whether the message was delivered or bounced before triggering follow-up logic.
- Transactional notifications: Dispatch receipts, alerts, or status updates from within a reducer, with delivery status automatically updated as Resend reports back.
- Multi-tenant applications: Tag outbound emails with user or organization identifiers so each tenant can be shown only their own email history through scoped views.
- Audit-sensitive systems: Maintain an append-only log of every delivery event, including delays, bounces, opens, and clicks, for compliance or support investigation.
- Operator-controlled email infrastructure: Run email as a standalone database that other services call into, keeping credentials and raw message content private from end users.
How it works
When your application needs to send an email, it calls into this module from a reducer that enforces your own authorization rules. The module validates the request, queues the message, and forwards it to Resend. A row is written to your database immediately, so the send is part of the same transactional context as the rest of your application logic. Credentials and message content are stored in private tables that are never directly subscribable by clients.
Delivery status is kept current through webhooks. When Resend reports that a message was delivered, delayed, bounced, or interacted with, an HTTP handler receives the event, verifies its authenticity using a shared signing secret, and updates the corresponding record in your database. Events are deduplicated so replaying or retrying a webhook does not produce duplicate state changes. Status can only move forward: an earlier delivery stage cannot overwrite a later one, and terminal states like delivery or bounce are permanent.
Your application controls what clients can see by defining its own views over the underlying email records, filtered by the user or organization identifiers attached to each message as tags. Administrative operations such as sending, canceling, and querying raw delivery logs are restricted to identities you explicitly grant access to, keeping the email infrastructure separate from product-facing features.
