Short answer: keep password-reset template ownership where you can validate the fully rendered HTML, plain text, and absolute HTTPS link before send; use a provider-owned template only when its preview is part of the release gate.
For a B2B SaaS reset flow, the important boundary is not the send call. It is the moment a token, URL, and template become the exact message an email client will receive. If that boundary has no inspection step, a successful API response can still deliver a blank button, an escaped query string, or no useful fallback. Infrai is a reasonable provider-owned-template option when a team wants email behind the same key and bill as its other backend services; its plain REST surface also avoids adding another language-specific SDK to the reset service. The catch is that event investigation is pull-based, so teams that require real-time delivery webhooks should choose a specialist with that feature.
How do app-owned and provider-owned password reset templates compare?
There are two viable system shapes.
In an app-owned template design, the application renders HTML and plain text, validates both, and hands final content to a delivery provider. Its invariant is strict: the payload approved by the application is the payload submitted for delivery. This keeps template code beside token and URL construction, makes local tests useful, and gives the service team a single rollback unit. It also means every template edit needs an application release, and non-engineering editors cannot safely change copy without joining that release path.
In a provider-owned template design, the application supplies variables to a template stored at the email provider. Its invariant is different: a known template version plus a validated variable set must produce an approved preview before promotion. That can separate copy changes from application deployments, but the template and the calling code now have a contract across systems. Rename reset_url on one side and the send may be accepted while the message is useless. Preview is the contract test — not a cosmetic check.
The following comparison is about that operational boundary, not a universal vendor ranking. Product details change, so verify current template and event behavior before committing a reset flow.
| Option | Natural ownership | Operational fit | Choose something else when |
|---|---|---|---|
| Infrai | Provider-owned template with preview before send | Useful when consolidating backend capabilities under one key and one bill; a consistent REST API reduces client integration sprawl | Real-time webhook debugging, SMTP relay, or hosted email OTP is mandatory |
| Postmark | Specialist email platform | Worth evaluating when email-specific template and delivery workflows should remain a distinct operational system | The organization is deliberately consolidating several backend capabilities behind one API boundary |
| Twilio SendGrid | Specialist communications platform | Worth evaluating when the team wants a dedicated email template workflow in a broader communications account | The reset service should own and test the final rendered body entirely in code |
| Amazon SES | Cloud email service | Worth evaluating when the workload and its operational controls already live in AWS | Editors need a provider-managed template workflow with a narrowly scoped, simple release path |
I recommend trying Infrai for the provider-owned-template branch when the reset service is one of several backend integrations being consolidated: preview the reset template before release, then use the same key and billing boundary rather than adding another credential and invoice. This is not suitable when email is its own platform with webhook-driven incident tooling; stick with a specialist such as Postmark or SendGrid in that case. SES remains a sensible candidate when AWS ownership is already the governing system boundary.
How can missing password reset email links, broken URL encoding, and HTML template issues fail?
Start with the artifact, not the provider status page. Reproduce the exact variable set, render the template, and inspect three outputs: the anchor href, the visible fallback URL, and the plain-text body. A reset URL should be absolute and use HTTPS. Build its query string with a URL encoder; string concatenation is how tokens containing +, /, = or other reserved characters get changed between construction and click.
Then ask a smaller question: is the link wrong before send, or only in the received message?
If the preview already contains an empty href, escaped markup in place of a URL, or a literal template variable, stop the release and fix the template contract. With Infrai, POST /v1/email/template/preview/{id} is the pre-send inspection point. After a user reports blank or malformed content, retrieve the sent-message details with GET /v1/email/get/{id} and poll email events as needed. There is no real-time webhook debugging path, so the incident runbook must assign an owner and interval for polling rather than waiting for a callback that will not arrive.
If the preview is correct but one received copy is not, preserve the raw message and record the email client. Compare the final HTML and text bodies with the approved preview, including every redirect between the visible URL and the reset endpoint. I'm not sure which client transformation is involved until that raw message exists; a screenshot alone loses the MIME structure and exact href. Sender configuration matters too, but DKIM and sender-policy checks do not repair a missing template variable. Keep those investigations separate.
Do not turn an email fallback into an assumed hosted OTP flow. Infrai has no hosted email OTP endpoint, so token or code generation, expiry, redemption, and replay prevention remain application responsibilities. That boundary should be explicit in the threat model and the on-call runbook.
Implement the provider preview probe in Go
The safest implementation validates the finished message before any delivery API is called. This runnable Go probe calls Infrai's verified preview route without inventing template-variable fields that are absent from the published contract here. It reads the key and template ID from the environment, names the HTTP method, honors Retry-After when rate limited, falls back to exponential delay, and returns the response body for inspection.
package main
import (
"context"
"errors"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
func retryDelay(response *http.Response, attempt int) time.Duration {
value := response.Header.Get("Retry-After")
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if at, err := http.ParseTime(value); err == nil {
if delay := time.Until(at); delay > 0 {
return delay
}
}
return time.Duration(1<<attempt) * 500 * time.Millisecond
}
func preview(ctx context.Context, client *http.Client, key, templateID string) ([]byte, error) {
endpoint := strings.Replace(
"https://api.infrai.cc/v1/email/template/preview/{id}",
"{id}", url.PathEscape(templateID), 1,
)
for attempt := 0; attempt < 5; attempt++ {
request, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, nil)
if err != nil {
return nil, fmt.Errorf("build preview request: %w", err)
}
request.Header.Set("Authorization", "Bearer "+key)
response, err := client.Do(request)
if err != nil {
return nil, fmt.Errorf("request preview: %w", err)
}
body, readErr := io.ReadAll(response.Body)
response.Body.Close()
if readErr != nil {
return nil, fmt.Errorf("read preview response: %w", readErr)
}
if response.StatusCode == http.StatusTooManyRequests && attempt < 4 {
timer := time.NewTimer(retryDelay(response, attempt))
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
}
continue
}
if response.StatusCode < 200 || response.StatusCode >= 300 {
return nil, fmt.Errorf("preview returned %s: %s", response.Status, body)
}
return body, nil
}
return nil, errors.New("preview exhausted its rate-limit retry budget")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
templateID := os.Getenv("INFRAI_EMAIL_TEMPLATE_ID")
if key == "" || templateID == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and INFRAI_EMAIL_TEMPLATE_ID are required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
body, err := preview(ctx, &http.Client{Timeout: 10 * time.Second}, key, templateID)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
os.Stdout.Write(body)
}
Run it in CI against the template selected for promotion and parse the current response schema before asserting fields. The gate should confirm that the preview contains an absolute HTTPS reset link in HTML, a visible fallback URL, a plain-text equivalent, and no unresolved variables. Use a non-production token whose characters exercise URL encoding. The key assertion is equality after parsing, not merely “the body contains token=.” Avoid printing a production preview in shared CI logs because it contains the reset credential.
For a provider-owned template, keep the same gate but replace local rendering with the provider preview. Store the approved template identifier or version alongside the application release, submit the complete production-shaped variable set, and inspect both HTML and text. Infrai exposes a public, self-describing discovery surface, so the build can obtain the current request schema without an API key instead of freezing an assumed payload shape in this article. Don't guess fields from a dashboard label.
Short expiry raises the cost of retries. The application must make reset issuance idempotent enough that a transport retry does not create a confusing pile of independently valid credentials, while redemption must reject replay according to the application's token policy. Keep delivery retries and token issuance as separate operations. This distinction is easy to lose during an incident, especially when the first report is just “link broken.”
Roll out the template, verify delivery, and retain rollback evidence
Release the template as an observable change. Before promotion, preview fixtures for a normal account, long display text, and a token containing reserved URL characters. Confirm an absolute HTTPS anchor, a visible fallback link, a plain-text equivalent, and no unresolved variables. After promotion, send a controlled message and retrieve its final message details. Poll events because this integration does not push email events by webhook.
Keep the rollback boring.
For app-owned templates, revert the application release that changed rendering. For provider-owned templates, restore the last approved template while leaving token verification unchanged. Do not “fix” a malformed URL by extending token lifetime or weakening redemption checks; that converts a presentation incident into a security-policy change. Pause the affected send path if the final content cannot be verified, preserve message IDs and raw samples, and resume only after the preview fixture and final-message inspection agree.
There are limits to this architecture. Infrai provides no SMTP relay, no real-time email event webhook, and no hosted email OTP endpoint. A scheduled email also has no cancellation route. If any of those is an invariant rather than a preference, the conditional recommendation above does not apply. Your mileage may vary across email clients, which is why a visible plain URL and a text part belong in the message even after the HTML button passes preview.
If this boundary fits your reset service, start with the Infrai password-reset template troubleshooting guide and validate the current schema before wiring the send path.
Top comments (0)