SendGrid Transactional Email
Send account and product email through SendGrid and keep the delivery feedback.
What it adds
A SendGrid delivery path for account email, with validated template data and recorded bounce and complaint outcomes.
What your agent is told to do
5
What your agent is told to do
5-
1
Route transactional mail through the app's existing mail layer with SendGrid behind it as one adapter. The rest of the codebase must never construct provider-specific payloads directly, or swapping or adding a provider later means touching every send site.
-
2
Enumerate the app's transactional messages — verification, password reset, receipts, alerts — and give each a template with a declared set of variables that is validated before the message is queued.
-
3
Send from the app's background-job system with a stable per-message identifier, and store the provider's message identifier on the record as soon as it is returned so support can trace a specific email later.
-
4
Consume delivery feedback on a verified endpoint and let bounces and complaints update a suppression list that every future send checks. Feedback that is received and then discarded is worse than not collecting it.
-
5
Give non-production environments a mode that either suppresses delivery entirely or redirects every recipient to a fixed internal address, and make that the default outside production.
Edge cases it handles
8
Edge cases it handles
8- Transactional mail and marketing consent are different things. A password reset must still go out to someone who unsubscribed from the newsletter, and a newsletter must never be sent under the transactional path to reach someone who opted out.
- A template rendered with a missing or misnamed variable produces an email with a visible gap or a broken link. Validate the variable set against the template's declared shape before the message is queued, and fail the job rather than sending it.
- Delivery, bounce, block, and complaint callbacks arrive on a public endpoint, can be replayed, and can arrive out of order. Verify their authenticity and process them idempotently so a redelivered event does not double-count or regress a record.
- Provider credentials and full message bodies must be kept out of logs and error reports. A stack trace that includes a reset link or a one-time code is a live credential sitting in log storage.
- A hard bounce or a spam complaint must suppress the address before the next send, not merely be recorded. Continuing to send to a bouncing address damages the sending reputation for every other message.
- A background job retried after a timeout must not send the email twice. Key the send on a stable identifier and reconcile on retry.
- The provider's rate limits and transient errors must be distinguished from permanent rejections. Back off and retry the former, stop immediately on the latter.
- When the provider is unavailable, the user-facing action must still succeed and the app must say the email is on its way, with the job retried, rather than reporting a failure the user cannot act on.
Definition of done
9
Definition of done
9- All transactional email leaves through one mail layer with the provider behind an adapter.
- Every message type has a template with declared variables that are validated before queueing.
- Bounce, block, and complaint events are verified, processed idempotently, and update a suppression list checked on every send.
- Suppressed addresses are never sent to again.
- No log or error report contains provider credentials or full message bodies.
- Non-production environments suppress or redirect delivery by default.
- A retried job never sends the same email twice.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Firebase Cloud Messaging
Firebase Cloud Messaging
Deliver push through Firebase with registration tokens that stay valid as devices change.
What it does
A Firebase-backed push channel with server-side token lifecycle management, consistent payload handling across platforms, and safe handling of the routes a notification opens.
How it works
- 1 Store one record per device registration, tied to the account signed in at the time, the platform it came from, and when it was last confirmed working, and let one account hold many of them.
- 2 Send from the app's existing background-job system with the provider credentials held server-side, and treat every send as a job that can be retried rather than work done inline during a request.
- 3 Decide, per notification type, whether the payload is meant to be displayed by the platform or handled by the app, and keep that decision the same on every platform. The same event behaving as a visible alert on one platform and a silent update on another produces bugs nobody can reproduce.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/firebase-cloud-messaging
OneSignal Push Notifications
OneSignal Push Notifications
Send push notifications to the right devices, with user preferences respected.
What it does
A push delivery path through OneSignal covering subscription registration, audience targeting, per-channel preferences, and delivery outcomes recorded against the app's own records.
How it works
- 1 Find the events the app already notifies on by email or in-app, and treat push as another channel for those same events rather than a separate notification system with its own triggers.
- 2 Record the link between a push subscription and an account on the server, established at sign-in and severed at sign-out, so a device that changes hands does not keep receiving the previous user's notifications.
- 3 Hold the provider credentials server-side and send every message from the app's existing background-job system, so a slow or failing provider never blocks a web request.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/onesignal-push-notifications
Telegram Bot Notifications
Telegram Bot Notifications
Deliver alerts and summaries to a Telegram user, group, or channel through a bot.
What it does
A Telegram delivery channel that sends selected app notifications to a destination each user has proven they control.
How it works
- 1 Add Telegram as a destination on the app's existing notification preferences rather than as a standalone feature, so a user's per-event choices, quiet hours, and unsubscribe controls apply to it unchanged.
- 2 Establish the destination by having the user start a conversation with the bot and present a short-lived code the app issued, then bind whatever chat that arrives from. Never let a user type a raw chat identifier into a form.
- 3 Keep the bot credential encrypted at rest and resolved only on the server at send time. It must not appear in configuration exposed to the browser, in logs, or in error reports.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/telegram-bot-notifications
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.