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
Slack Channel Alerts
Slack Channel Alerts
Send the events a team actually needs into a Slack channel without flooding it.
What it does
Operator-configured routing of selected app events into Slack channels, with grouping, throttling, and reliable delivery.
How it works
- 1 List the events genuinely worth interrupting a team for — failed payments, high-value signups, error thresholds, approvals waiting — and make each individually selectable per channel. An all-or-nothing firehose gets muted within a week and then nobody sees the one that mattered.
- 2 Run the connection through the provider's authorisation flow, then confirm the workspace and channel at setup by posting a test message the operator has to acknowledge. Store the resulting credential server-side only.
- 3 Write each message so it stands alone: what happened, to whom, when, and a link back into the app. Optional fields that are absent must be omitted cleanly rather than rendering as empty labels.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/slack-channel-alerts
Microsoft Teams Channel Alerts
Microsoft Teams Channel Alerts
Post operational and customer alerts into a chosen Microsoft Teams channel.
What it does
A Teams destination for selected app events, with explicit tenant, team, and channel selection and reliable delivery.
How it works
- 1 Make the destination explicit at setup: the operator picks the tenant, then the team, then the channel, from lists the app fetched under that operator's own authorisation. Do not accept a pasted destination identifier as configuration.
- 2 Confirm the connection by posting a test message the operator acknowledges, and record which account authorised it so anyone can see whose credentials the integration depends on.
- 3 Keep every message inside the provider's payload and card size limits. Truncate long user content at a defined boundary and link back to the full record, rather than letting an oversized post be rejected silently.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/microsoft-teams-channel-alerts
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.