Bolt prompt to add email notifications
Email in a Bolt project has to go through an HTTP API, since the WebContainer is no place for an SMTP connection, and the provider key has to stay server-side. This prompt sets both rules in code and adds a simulated mode that prints rendered emails to the terminal, so signup flows keep working before any key exists.
Last updated
Add transactional email notifications to this Bolt project. Use {{addon}} as the provider, called through its HTTP API from the server only, because outbound SMTP from a WebContainer is unreliable and the key must never reach the client bundle.
Structure:
- server/email/client.ts: one send(to, template, data) function, key read from EMAIL_API_KEY in .env, throwing a typed EmailError on any non-2xx response.
- server/email/templates/: welcome.ts, password-reset.ts, weekly-digest.ts, each exporting a subject and an HTML body built from plain template strings, no templating library. Inline all CSS, use tables for layout, and include a plain-text alternative per template.
Triggers: hook welcome into the existing signup flow, password-reset into the reset request, and expose POST /api/notifications/test that sends any template to my own address so I can proof designs from the preview.
Reliability:
- Sends are fire-and-forget from the request path, pushed onto an in-process queue with three retries and exponential backoff, so a provider outage never blocks signup.
- Log every attempt with status sent, retried, or failed.
- If EMAIL_API_KEY is unset, print the fully rendered email to the terminal tagged SIMULATED instead of failing, so dev flows still complete.
Edge cases: strip newlines from user-supplied names to block header injection, lowercase recipient addresses, and refuse obviously invalid addresses before calling the API.
Acceptance: hit the test endpoint with no key and read the SIMULATED render in Bolt's terminal, then add a real key and receive the welcome email in an actual inbox.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Add transactional email notifications to this Bolt project. Use input validation as the provider, called through its HTTP API from the server only, because outbound SMTP from a WebContainer is unreliable and the key must never reach the client bundle. Structure: - server/email/client.ts: one send(to, template, data) function, key read from EMAIL_API_KEY in .env, throwing a typed EmailError on any non-2xx response. - server/email/templates/: welcome.ts, password-reset.ts, weekly-digest.ts, each exporting a subject and an HTML body built from plain template strings, no templating library. Inline all CSS, use tables for layout, and include a plain-text alternative per template. Triggers: hook welcome into the existing signup flow, password-reset into the reset request, and expose POST /api/notifications/test that sends any template to my own address so I can proof designs from the preview. Reliability: - Sends are fire-and-forget from the request path, pushed onto an in-process queue with three retries and exponential backoff, so a provider outage never blocks signup. - Log every attempt with status sent, retried, or failed. - If EMAIL_API_KEY is unset, print the fully rendered email to the terminal tagged SIMULATED instead of failing, so dev flows still complete. Edge cases: strip newlines from user-supplied names to block header injection, lowercase recipient addresses, and refuse obviously invalid addresses before calling the API. Acceptance: hit the test endpoint with no key and read the SIMULATED render in Bolt's terminal, then add a real key and receive the welcome email in an actual inbox.
Same task in other tools
Questions about this prompt
What does simulated mode actually do?
When EMAIL_API_KEY is missing from .env, the send function renders the full template and writes it to Bolt's terminal tagged SIMULATED instead of calling the provider. You can develop the entire signup and reset flow, read every email in the terminal, and add the real key only at deploy time.
How do I add a new template, say an invoice receipt?
Copy the shape of welcome.ts into server/email/templates, export a subject and an HTML body built from template strings, and register it in the template map. Then hit POST /api/notifications/test with the new name to proof it. Keep CSS inline and ship the plain-text version, some providers penalize its absence.
Emails send fine, but signups feel slow. What is wrong?
The send is probably awaited inside the request handler instead of queued, so signup waits on the provider's round trip. The prompt specifies fire-and-forget with retries for exactly this reason. Check that the route pushes to the queue and returns immediately, with failures landing in the log rather than the response.