v0 prompt to add email notifications
This prompt adds Resend-backed transactional email to a v0 project with the parts that matter in production: per-user preference switches, an email_log table, and an on-screen dev inbox so the whole flow works in the preview before any API key exists. Templates are React components you can restyle like any other.
Last updated
Add transactional email notifications to an existing app using Resend and React Email templates. Templates: real React components under emails/, welcome.tsx sent on signup and {{resource}}-updated.tsx sent when a watched record changes, each with a plain-text fallback, a preview line under 90 characters, and an unsubscribe footer link. Sending: a lib/send-email.ts helper wraps the Resend client and reads RESEND_API_KEY from env, and every trigger calls it from a server action or route handler, never from client code. Preferences: a notifications section on the settings page with a shadcn/ui Switch per email type, persisted to a notification_prefs table keyed by user id and checked before every send, so an opted-out user is skipped silently. Behaviors: sends happen after the database write commits, not before, so a failed save never emails anyone, and each attempt lands in an email_log table with recipient, template, and status for debugging. Failure handling: if the Resend call throws, the originating action still succeeds, the failure is recorded in email_log with its message, and nothing retries automatically, avoiding duplicate sends. Missing API key: the v0 preview routes sent emails into an on-screen dev inbox at /dev/emails instead of failing, so the whole flow is testable before Resend is connected. Dev inbox empty state: no emails sent yet. Acceptance: switching a preference off suppresses that email type, the dev inbox shows the welcome email after a test signup, and email_log rows match what the inbox displays.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Add transactional email notifications to an existing app using Resend and React Email templates. Templates: real React components under emails/, welcome.tsx sent on signup and users-updated.tsx sent when a watched record changes, each with a plain-text fallback, a preview line under 90 characters, and an unsubscribe footer link. Sending: a lib/send-email.ts helper wraps the Resend client and reads RESEND_API_KEY from env, and every trigger calls it from a server action or route handler, never from client code. Preferences: a notifications section on the settings page with a shadcn/ui Switch per email type, persisted to a notification_prefs table keyed by user id and checked before every send, so an opted-out user is skipped silently. Behaviors: sends happen after the database write commits, not before, so a failed save never emails anyone, and each attempt lands in an email_log table with recipient, template, and status for debugging. Failure handling: if the Resend call throws, the originating action still succeeds, the failure is recorded in email_log with its message, and nothing retries automatically, avoiding duplicate sends. Missing API key: the v0 preview routes sent emails into an on-screen dev inbox at /dev/emails instead of failing, so the whole flow is testable before Resend is connected. Dev inbox empty state: no emails sent yet. Acceptance: switching a preference off suppresses that email type, the dev inbox shows the welcome email after a test signup, and email_log rows match what the inbox displays.
Same task in other tools
Questions about this prompt
Can I test the emails without a Resend account?
Yes, that is what the dev inbox is for. Without RESEND_API_KEY set, sends render into /dev/emails inside the v0 preview, so you can check template layout, preference gating, and email_log rows before adding the key in project settings.
How do I add a third notification type later?
Three touches: a new template component in emails/, a new Switch row wired to notification_prefs, and a call to the send helper after the triggering write commits. The email_log table needs no schema change since it records template by name.
The same email goes out twice for one action. What causes that?
The send call escaped the server action, usually into a component render or an effect that fires on both mount and update. Check email_log timestamps to find the duplicate path, then ask v0 to move the send so it runs exactly once, after the database write.