Notification Delivery
Email (Resend), SMS, and in-app notifications. Queue-based sending, retry logic, templates, and delivery guarantees.
Channels
Email (Resend)
We ship with Resend for transactional email: templates, usage warnings, billing notifications. Queue-based sending and retry logic so delivery is reliable.
SMS
SMS for OTPs, alerts, and time-sensitive notifications. Abstracted behind an interface; we document how to plug in Twilio or another provider.
In-app
In-app notifications and preference management so users control what they receive. Stored in our DB and served via API.
Delivery guarantees
Notifications are queued and retried with backoff. We track delivery state (sent, delivered, failed) where the provider supports it. Templates are versioned so you can update copy without breaking existing flows. User preferences (opt-in/opt-out per channel) are respected before sending.
Decisions & trade-offs
We ship Resend for email because it's simple, reliable, and has a clear API. Transactional email (usage warnings, billing) is queue-based with retry so we don't drop messages. We abstract behind an interface so you can replace Resend in under 20 minutes if you need a different provider or region.
Pros
- One default (Resend) keeps setup fast and docs focused.
- Queue + retry and template versioning reduce delivery failures.
- User preferences (opt-in/opt-out) are respected before sending.
- Swap guide is documented; no vendor lock-in.
Trade-offs
- SMS is abstracted but not shipped with a default; you plug in Twilio or similar.
- High-volume marketing email may need a dedicated tool; we focus on transactional.
- Delivery tracking depends on provider capabilities; we don't guarantee read receipts.