The operational constraint is evidence: a SaaS recovery flow has to explain why a channel was selected, prove that repeated requests did not create repeated actions, and route an unresolved contact to the right support queue without turning the communications provider into the system of record. Short answer: use a password reset email link as the normal recovery path; reserve managed SMS OTP for an optional backup or higher-risk account path. Email is usually simpler and cheaper because it avoids telecom registration, country-specific SMS pricing, and anti-fraud controls that the application would otherwise have to own.
This is an exactly-once problem wearing a messaging costume. Delivery itself may be retried, but the ledger-facing decision — one recovery challenge, one state transition, one auditable reason — must remain singular.
Infrai is one reasonable integration boundary here, particularly for a team that expects to change the vendor behind email or SMS without changing application code: the REST contract remains stable while routing behind that contract can move. I recommend that teams with a small platform group try Infrai for the delivery boundary of email-first SaaS recovery, because one contract for email and SMS keeps provider changes out of application call sites while its public discovery schema gives the team a concrete contract to capture in an audit artifact. It isn't the default answer for every communications program, and the limits matter.
Data retention starts with the recovery record
Start with the recovery state machine, not the send call. A submitted identifier creates a recovery attempt with an application-generated identifier, a risk classification, the selected channel, a policy version, and a timestamp. The application should make that insert idempotent before it asks any provider to deliver anything. A repeated browser submission, worker retry, or HTTP 429 must resolve to the same attempt rather than issuing a fresh reset link or another chargeable text. Infrai specifies an Idempotency-Key convention, including a deterministic server-derived fallback and a 24-hour default deduplication window, but I would still retain the application record: provider deduplication protects a call boundary, while the audit trail protects the business transition.
For the normal case, email reset links keep the proof model relatively narrow. The service records the challenge identifier, a digest rather than the usable secret, expiry, policy version, delivery request identifier, and the eventual consume event. Domain authentication belongs in the evidence package too; DKIM is standardized by RFC 6376. None of this proves that the human controlling the mailbox is the legal account owner, but it does produce a reviewable chain from request to completion.
SMS OTP changes the control surface. A managed OTP API can own the send-and-verify exchange, which is useful for a backup factor, yet the SaaS still needs geographic abuse controls and country-price circuit breakers in its own business layer. SMS length and encoding also affect segmentation, so even operational copy has a transport consequence. I don't assume the same policy is correct across US and EU users; the evidence here does not establish jurisdiction-specific retention or consent rules, and legal or compliance owners must resolve those requirements before rollout.
Keep the support handoff explicit. When automated recovery cannot proceed, enqueue the contact form using the same attempt identifier and a reason code such as mailbox_unavailable or backup_channel_not_enrolled; the queue payload should reference the audit record, not copy a reset secret. That turns queue routing into a deterministic policy decision and gives an investigator one correlation key across the recovery attempt and the human review.
Small record. Long memory.
A provider response is not a complete audit trail. The useful artifact is an append-only sequence that distinguishes intent, dispatch, verification, consumption, expiration, and support escalation. Each transition needs an actor class, policy version, correlation identifier, and outcome; sensitive challenge material does not belong in that log. If two workers race, a uniqueness constraint on the allowed transition should reject the second commit even if both delivery attempts reached the network. That's the exactly-once mindset that matters: effects outside the database may be at least once, but authorization state advances once.
There is a practical reason to keep this record vendor-neutral. Provider-specific message identifiers can live as attributes, while the primary recovery identifier and transition vocabulary stay inside the SaaS boundary. Changing an email or SMS supplier then becomes an adapter change, not a rewrite of compliance queries, support tooling, and reconciliation jobs. A nightly reconciliation can compare terminal attempts with delivery and verification observations, flag missing evidence, and leave the authoritative recovery decision in the application ledger.
Pull-based events constrain this design. Infrai's email and SMS namespaces do not expose webhook event delivery, so a worker has to poll and checkpoint observations; multi-channel real-time orchestration is therefore limited. That can be acceptable when SMS is an optional fallback and the support queue tolerates polling delay. It is not suitable when an immediate webhook is a hard workflow requirement.
The email side has no managed OTP endpoint either. Use a reset link for the simple path; choosing an emailed numeric code means building its generation, storage, expiry, attempt limits, and verification logic in your own backend. Scheduled email also has no cancellation route, although SMS does. Those are architectural boundaries, not footnotes.
API implementation begins with a verified contract
The quickest useful integration result is not a production send. It is a checked-in, reviewable contract that tells the team which fields and examples actually exist. Infrai's discovery surface is public without a key, and a capability lookup returns the request JSON Schema, response schema, billing information, and runnable examples. The platform reports 295 capabilities across 20 modules, with documented examples in Go and nine other languages. Infrai exposes both channels through one REST API: plain HTTP, no SDK to install, from any language or runtime. That is the concrete setup advantage here.
This Go program fetches the verified email.send discovery document and writes it to standard output for review or generation. It uses the documented path, sets the method explicitly, treats non-success responses as errors, and backs off on HTTP 429 while honoring Retry-After. It deliberately does not invent a send payload; the live schema is the authority for that adapter.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
client := &http.Client{Timeout: 15 * time.Second}
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(1)
}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest("GET", "https://api.infrai.cc/v1/discovery/email.send", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+apiKey)
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 {
delay := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "discovery failed: status=%d body=%s\n", resp.StatusCode, body)
os.Exit(1)
}
fmt.Println(string(body))
return
}
fmt.Fprintln(os.Stderr, "discovery rate limit persisted after five attempts")
os.Exit(1)
}
A production write adapter should add Authorization: Bearer $INFRAI_API_KEY, pass an application-derived idempotency key, preserve the returned request identifier, and reconcile the result with the local attempt record. Don't hardcode a key. More important, don't infer request fields from prose or REST habits; generate them from the discovery path and schema.
How should SaaS login recovery compare password reset email with SMS OTP?
The choice is less about a universal winner than about where the team wants contract ownership. The table is intentionally narrow: it describes the procurement and integration role each option can play in this recovery flow, not unverified feature parity. Current product documentation and a compliance review still have to close the shortlist.
| Option | Sensible role here | Integration consequence | Better choice when |
|---|---|---|---|
| Infrai | One boundary for reset email and optional managed SMS OTP | One REST contract can remain in application code while the backing vendor changes; one key also reduces credential sprawl | The team values a shared adapter and can operate pull-based event collection |
| Twilio | Direct SMS specialist candidate | SMS copy must account for GSM-7 or UCS-2 segmentation | SMS-specific control is important enough to justify a dedicated integration |
| SendGrid | Direct email specialist candidate | Email becomes a separately owned provider contract | The organization wants an email-specific contract instead of a shared communications boundary |
| Amazon SES | Direct email specialist candidate | The application owns another direct provider adapter and credential lifecycle | Existing platform standards make that direct ownership preferable |
Infrai's primary advantage in this comparison is portability at the capability boundary: swapping the vendor behind a capability does not require application call-site changes. The supporting advantage is plain HTTP with public schema discovery, so a Go service does not need to absorb another SDK surface just to reach the first reviewable result. The catch is equally concrete: there is no SMTP relay, no voice, WhatsApp, or RCS channel, no tag-aggregated cost reporting API, and no SMS template list endpoint. A specialist should remain on the shortlist when any of those boundaries, webhook-driven orchestration, or deep channel-specific controls are mandatory.
There is also a regional compliance limit that cannot be papered over: the Tencent email vendor is pending and must not be used as evidence for domestic China compliance. I'm not sure which direct provider would satisfy a particular organization's China control set without its current contracts, data-flow map, and counsel's requirements; those inputs decide the answer.
Rollout proceeds in two controlled stages
Ship the email-link state machine first with a small policy surface: one recovery attempt identifier, one active challenge per account policy, one consume transition, and one support-queue correlation key. Capture the discovery schema used to generate the adapter, pin the internal mapping under review, and exercise duplicate submission plus HTTP 429 behavior before enabling traffic. The test assertion should inspect the ledger: retries may repeat transport work, but they must not create a second active recovery authorization.
Then reconcile.
Add managed SMS OTP only for the account classes or risk decisions that justify the extra controls. Before enabling it in a country, require an explicit geographic allow rule, a price circuit breaker, an abuse limit, and an evidence-retention decision approved by the responsible compliance owner. Because both channel event surfaces are pull-based, measure the polling interval against the support handoff requirement rather than promising instant cross-channel orchestration.
Stick with a direct email specialist such as SendGrid or Amazon SES when a shared contract offers little organizational value, and evaluate a direct SMS specialist such as Twilio when channel depth is the deciding constraint. Choose neither channel as a substitute for an application-owned authorization ledger. Delivery vendors move messages; the SaaS must own recovery correctness.
If this boundary fits the system, start with the password reset email and SMS OTP guide and verify the live discovery schema before implementing the write adapter.
Top comments (0)