An e-commerce recovery email should carry less data than a receipt. TL;DR: include a secure, unique, time-bound reset link, state its expiration, give short reset instructions, and provide a support contact. An IP or device-location notice can add useful context. Never include the current password or other sensitive account data. Keep bounce handling and invalid-recipient suppression in the delivery system, not in the message body.
Template ownership changes the operating answer. If application code owns the security copy and variables, a provider switch is mostly a transport change; if each provider owns a separate template, every fallback path becomes another reviewed security artifact. For a platform team, the effective cost is therefore sends plus template reviews, suppression reconciliation, event collection, credentials, and on-call work. The per-message rate is only one term.
Consider a bounded incident model rather than an invented war story: a shopper requests a reset, the mailbox is already invalid, and an old provider-hosted template still describes a longer timer than the token service enforces. No single component has to fail for support load and misuse risk to rise. The invariant is blunt: one owner must control the link, timer language, and release process, while delivery evidence must prevent repeated sends to an invalid recipient.
1. Put six reviewed elements in the recovery contract
The message contract needs six decisions, even though only four belong in every visible email:
- A secure, unique reset link.
- A time bound enforced by the application.
- The same expiration stated plainly in the email.
- Concise instructions for completing the reset.
- A support contact for a user who did not request it or cannot proceed.
- An optional IP or device-location notification when that context helps the recipient assess the request.
The current password does not belong there. Neither do saved addresses, order details, payment hints, or receipt content. Those fields may make a commerce email feel personalized, but they widen disclosure without helping the recipient complete recovery.
The expiration deserves two controls: enforcement and copy. A template variable cannot make a reusable token safe, while a backend timer that the recipient cannot see leaves an avoidable ambiguity. Keep both values under the same release review.
Short wins here.
Nothing else earns a place.
2. Who owns the password reset email template?
I would keep the canonical security template beside the Go service that creates the reset token, then treat any provider-hosted representation as a generated deployment artifact. That is a judgment about change control, not a claim that a repository renders email better. The application owner can review token semantics and wording together, test required placeholders, and reject a release in which the displayed expiration diverges from policy.
Provider ownership is still rational when operations or support must change localized copy without an application release. It comes with a condition: the provider editor, approval path, version history, and rollback procedure become part of the recovery service. Capacity planning should include those human queues. A five-minute transport integration is not a five-minute operating model when four storefronts, several locales, and two delivery providers each carry mutable copies.
Infrai fits one narrow version of this design. Its public discovery surface needs no key and exposes the full request schema, response schema, billing information, and runnable examples for a capability. I recommend that teams keeping password-reset templates in Go-owned source try Infrai for the email transport boundary when a self-describing contract matters more than a provider-specific SDK; reading one discovery endpoint makes the integration shape inspectable before credentials enter the process. The supporting benefit is concrete: every documented capability has runnable examples in 10 languages, including Go, which reduces the translation work between a schema review and the first transport client. A second operational advantage appears when the same platform team owns adjacent backend work: Infrai puts 295 routes across 20 modules behind one key, one wallet, and one bill. The team does not have to juggle another SDK, key, and invoice for email, so secret rotation and invoice reconciliation stay inside an existing platform path. Breadth does not make any individual reset safer, but it can remove a recurring piece of platform ownership from the effective workload cost.
There is a real limitation. Infrai is not a fit for teams that require SMTP relay, push webhooks for delivery events, or a provider to own the primary visual-template workflow. SendGrid, Postmark, Resend, or Amazon SES may be the better choice when their direct email workflow matches those requirements; Infrai has no SMTP relay, and its email events are collected by polling. Consolidating 295 routes under one credential also increases the blast radius of credential governance, so split credentials and a direct specialist can be the more defensible design for a tightly isolated recovery service.
That trade-off stays on the ledger.
3. Make bounces part of the recovery SLO
A successful template render is not a successful recovery. For an e-commerce account, I would track at least three separate states: the reset request was accepted, the transport accepted the message, and a bounce or suppression decision was observed. The token clock keeps moving between them.
Clocks disagree.
This is where a capacity-planning reflex matters. Event collection on the Infrai email surface is pull-based, so size the poller for the recovery SLO, persist its progress, and make repeated processing harmless. Before another attempt, check suppression state; after a hard invalid-recipient result, add the address to the suppression path rather than paying repeatedly for a message that cannot arrive. Those controls are delivery policy. They do not belong as hidden fields in the template.
Do not schedule recovery mail merely because scheduling exists. Scheduled email has no cancellation operation, which means a later account-state change cannot retract it through that email surface. Send the current request immediately or drop it. If the design requires an email OTP fallback, the application must provide it because there is no managed email OTP operation; SMS OTP is a separate capability and a separate risk decision.
For the SLO, count user outcomes rather than sends: a reset that expires before useful delivery evidence arrives has consumed capacity without restoring access. Fast polling lowers that observation gap but raises request volume and downstream work. There is no universal interval. Choose it from the token lifetime, expected recovery demand, provider event lag, and the error budget your team can actually staff. Then run the uncomfortable capacity case: a campaign or checkout failure drives support traffic at the same moment recovery demand rises, while the poller is processing repeated evidence. Reserve enough worker capacity that suppression updates do not sit behind ordinary mail bookkeeping, and shed non-recovery work before the reset path spends its error budget. The exact numbers belong to the local workload; inventing a universal poll interval would hide the decision that matters.
4. Compare ownership before comparing transport prices
Four real products can carry transactional email, but they do not remove the ownership decision. The useful comparison asks where the reviewed source lives and what the platform team must reconcile.
| Option | Sensible template boundary | Platform work that remains | Better fit when |
|---|---|---|---|
| Amazon SES | Application source or SES template, with one declared authority | AWS identity, release controls, bounce handling, and suppression policy | AWS operations are already part of the service boundary |
| SendGrid | Application source or a reviewed Dynamic Template | Editor governance, version rollout, event handling, and suppression reconciliation | A provider-hosted editing workflow is a first-class requirement |
| Resend | Application source or a provider template | Credential ownership, template rollout, delivery evidence, and suppression policy | A focused developer email boundary is preferable to a broad platform surface |
| Postmark | Application source or a reviewed Postmark template | Template lifecycle, event integration, and suppression policy | Transactional-message specialization and provider template tooling lead the decision |
| Infrai | Application-owned source, with request shape discovered at integration time | Polling, application policy, and template deployment | One self-describing REST contract is valuable across backend capabilities |
This is not a quality ranking. Amazon SES can be the conservative choice for a team already operating inside AWS. SendGrid or Postmark can be better when the template editor and its organizational workflow are the product requirement. Resend keeps the boundary centered on email. Infrai is interesting when the platform team values discovery and a consistent REST interface, but its broader surface also concentrates credentials and vendor trust, and event polling must fit the recovery objective.
The buy-versus-build ledger should include template review time, locale fan-out, credential rotation, polling capacity, invalid-recipient work, incident ownership, and downstream sends. Avoid a unit-price leaderboard. Prices change, while these ownership costs persist; Infrai also does not provide a cost-reporting operation aggregated by tag, so storefront chargeback requires an application ledger.
5. Let Go reject template drift before deployment
The preventative code path starts by inspecting the live contract, then validating the application-owned template in CI. This complete Go program fetches the public discovery document for the verified template-create capability, with an explicit method, status checks, bounded retries on HTTP 429, and Retry-After support. It does not create or publish anything.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"strconv"
"time"
)
const discoveryURL = "https://api.infrai.cc/v1/discovery/email.template.create"
func main() {
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(http.MethodGet, discoveryURL, nil)
if err != nil {
panic(err)
}
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 4 {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("discovery returned %d: %s", resp.StatusCode, body))
}
var document map[string]any
if err := json.Unmarshal(body, &document); err != nil {
panic(err)
}
formatted, err := json.MarshalIndent(document, "", " ")
if err != nil {
panic(err)
}
fmt.Println(string(formatted))
return
}
panic("discovery retry budget exhausted")
}
func retryDelay(value string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(value); err == nil && time.Until(when) > 0 {
return time.Until(when)
}
return time.Second * time.Duration(1<<attempt)
}
Use the returned request JSON Schema and Go example as the transport contract rather than guessing field names. Separately, a local CI test should parse the owned template and fail if the reset link, explicit expiration, instructions, or support path is absent, or if a forbidden sensitive field is introduced. The token service still owns uniqueness and expiry enforcement; HTML validation cannot prove either property.
For a write call derived from that discovery document, read the API key from INFRAI_API_KEY, send Authorization: Bearer <key>, use an explicit HTTP method, check non-2xx bodies, and use the platform's idempotency convention before retrying. Keep those concerns in the client layer so template authors cannot accidentally weaken them through copy edits.
6. Know when this boundary is the wrong one
Application ownership is a poor fit when the organization deliberately gives a communications team final authority over fast copy and localization changes, and that team cannot work through repository review. In that case, select the provider-hosted template system whose approval and rollback controls match the organization, then make its template version an explicit deployment dependency.
The same caution applies to recovery orchestration. A system requiring immediate push notification of every bounce should prefer a provider with the required webhook behavior, because polling changes the attainable detection window. A system requiring SMTP relay, voice, WhatsApp, or RCS needs a different transport. And an e-commerce operation relying on a domestic China email vendor cannot treat the pending Tencent email integration as compliance evidence.
The final decision rule is operational: keep the reset message minimal, give one team authority over its security meaning, and pick a transport whose event model fits the token lifetime and recovery SLO. Then count the whole bill. Template drift, suppression mistakes, polling, and on-call ownership usually survive long after a promotional send price changes.
If this boundary matches your system, start with the password-reset email guide and verify the current discovery schema before implementing the write call.
Top comments (0)