SaaS Login Practice — SMS OTP and Email Fallback Evidence for Site Access

Choose managed SMS OTP for the initial SaaS login challenge when integration effort decides the US/EU rollout, and treat email recovery as an application-owned flow; for a logistics contractor entering a construction site, keep the compliance notice and its delivery record separate from the login result. A successful challenge does not establish that a particular notice reached its recipient.

TL;DR: Buy the SMS challenge and verification flow, budget explicitly for custom email-code generation, storage, expiration, and verification, and retain a separate notice ledger. Evaluate integration effort across the whole handoff: account identity, recipient selection, dispatch, status collection, and evidence retention. Require the access policy to say which recorded evidence permits entry. An email open should not silently become acknowledgment.

Should SaaS login practice use SMS OTP or email fallback for site access?

Treat authentication, notice dispatch, delivery evidence, and acknowledgment as separate transitions in the application design. A contractor can finish a login challenge while the compliance notice remains pending; conversely, a delivery observation attached to yesterday's message should never authorize today's gate entry. The useful review artifact is a trace from the account and notice revision to the specific delivery attempt, with the event observation time retained alongside the event itself. For a synthetic example, use account contractor-042, site gate-west, and notice revision lifting-plan-r7. These are application identifiers, not provider request fields. The access policy should state which evidence permits entry and which unresolved state requires a supervisor, rather than allowing a transport observation or successful code submission to make that decision implicitly.

Keep them separate.

The operational signal is a growing count of authenticated arrivals whose required notice record remains unresolved. Measure that seam directly. A login success ratio can look healthy while the compliance workflow misses its own deadline, especially when status is collected by polling and the application mistakes its last observation for a complete account of delivery.

Neither channel selection nor domain authentication establishes US/EU legal compliance. Define the required evidence, retention, and access decision with the people responsible for the notice policy before encoding those decisions in the service.

Buy the challenge flow; budget for the evidence work

This buy-versus-build comparison allocates responsibilities for the logistics workflow. It is not a deliverability ranking. The integration axis includes recipient mapping, recovery policy, and operational ownership, because counting HTTP calls gives the platform roadmap an unrealistically small scope.

Infrai fits the shared-service row with a plain REST API, one key, one bill, and public discovery: anything that sends an HTTP request can call it without installing an SDK or maintaining a client-library version, while a single key and unified billing reduce credential provisioning and invoice reconciliation across notice email and SMS verification. Its breadth is 295 routes across 20 modules under one key; this workflow uses only a small part of that surface. The API is self-describing, and discovery requires no key, so the team can inspect request and response schemas before implementation. Runnable examples in 10 languages help review the contract in the language the integration team will maintain. The application still owns recipient reconciliation.

That consolidation is a tradeoff. A team already operating an identity or verification component may accept less integration work by extending that arrangement, while a team building both messaging paths together may prefer a shared interface; either team still owns the notice ledger and the policy that interprets its contents. Review the linked product documentation against the exact flow before choosing. No measured latency, uptime, or delivery advantage is assumed here.

Use managed SMS challenge creation and verification as the primary path in this design. For email fallback, explicitly assign code generation, storage, expiration, and verification to the application. Treat that as a separate engineering commitment, with its own threat review and acceptance tests, rather than a second send button that happens to target a mailbox.

Make the evidence boundary executable

Before wiring transport calls into gate authorization, make the recipient handoff inspectable. The following standalone Go probe checks the selected email recipient against the suppression service and prints the response without guessing its schema. Save it as main.go and run it with Go after setting INFRAI_API_KEY, API_BASE_URL, and NOTICE_EMAIL. Set the base to the documented HTTPS API base ending in /v1, and use a controlled test recipient. This read is a preflight inspection, not evidence of notice delivery.

package main

import (
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "strings"
    "time"
)

func required(name string) string {
    value := os.Getenv(name)
    if value == "" { panic("missing " + name) }
    return value
}

func main() {
    base := strings.TrimRight(required("API_BASE_URL"), "/")
    parsed, err := url.Parse(base)
    if err != nil || parsed.Scheme != "https" || parsed.Host == "" || parsed.Path != "/v1" {
        panic("API_BASE_URL must be the documented HTTPS API base ending in /v1")
    }
    key := required("INFRAI_API_KEY")
    recipient := required("NOTICE_EMAIL")
    client := &http.Client{
        Timeout: 10 * time.Second,
        CheckRedirect: func(*http.Request, []*http.Request) error {
            return http.ErrUseLastResponse
        },
    }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet,
            base+"/email/suppression/check/"+url.PathEscape(recipient), nil)
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { panic(err) }
        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if readErr != nil { panic(readErr) }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := time.Second * time.Duration(1<<attempt)
            retry := resp.Header.Get("Retry-After")
            if seconds, err := strconv.Atoi(retry); err == nil && seconds >= 0 {
                if wait := time.Duration(seconds)*time.Second; wait > delay { delay = wait }
            } else if date, err := http.ParseTime(retry); err == nil {
                if wait := time.Until(date); wait > delay { delay = wait }
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("HTTP %d: %s", resp.StatusCode, body))
        }
        fmt.Println(string(body))
        return
    }
}

Inspect the response against the documented schema before deciding whether a recipient is eligible for dispatch. A suppression check does not grant site access, prove human acknowledgment, or provide durable storage. Keep the probe output in a restricted test session because it may contain recipient information. Production code should record the policy decision and correlation identifier, normalize the documented delivery semantics, and persist evidence before a policy evaluator uses it.

The trap is revision reuse. An account can be correct and a recipient can be correct while the notice revision is wrong; a generic delivered flag on the account loses exactly the distinction an auditor needs. Preserve the attempt identifier too, so an observation from an earlier attempt cannot be casually attached to a replacement dispatch.

For writes, define a stable dispatch identity before enabling retries, and use the operation's documented idempotency contract. A timeout leaves the send outcome uncertain. Blindly issuing another notice can create duplicate attempts and a misleading evidence trail. Keep retry decisions within a finite budget, honor Retry-After on HTTP 429, and use exponential backoff rather than a tight loop.

Set polling capacity and abuse budgets before rollout

For the shared REST option in this comparison, email and SMS event collection is pull-based. Operate a poller with a durable cursor or other documented progress mechanism appropriate to the selected operation, and define a deadline after which an unresolved notice moves to supervisor review. Do not design the gate around an assumed push callback. Also keep the channel scope explicit: this design selects SMS and email, rather than assuming voice, WhatsApp, RCS, or an SMTP relay is part of that service.

As an illustrative planning assumption, 600 pending attempts polled every 15 seconds require about 40 status reads per second before retries. That arithmetic describes a proposed workload, not a provider quota or benchmark. Count retries and backlog recovery separately, and bound concurrent reads so a busy shift change does not turn the evidence collector into an uncontrolled source of traffic. Shorter polling intervals consume capacity; longer intervals postpone the application's response to newly observable evidence. Neither choice guarantees delivery.

Define the SLO around the time between an observable status becoming available and its durable recording in the notice ledger. Track the oldest unresolved attempt as a separate operational signal. A carrier's delivery time and the poller's recording delay are different quantities, and combining them into one optimistic percentage makes the on-call decision harder.

For US/EU rollout, implement allowed destination countries, country-specific spending cutoffs, and anti-abuse throttles in the application. Rate-limit both sends and verification guesses, with account, destination, and network dimensions chosen for the access policy. Email fallback should consume the same account-level attempt budget, or alternating channels can evade a per-channel limit. Resend cooldowns and finite retry budgets need explicit owners and tunable policy values.

Budget the fallback.

Email delivery setup deserves its own review: RFC 7489 describes DMARC, while Apple's Mail Privacy Protection guidance is relevant when interpreting open-related observations. Neither an authenticated sending domain nor an open observation should satisfy a human acknowledgment requirement by accident.

Verify the handoff, then define rollback

Before rollout, exercise a small acceptance matrix: successful OTP with unresolved notice evidence; a delivered notice for an old revision; duplicate status observations; a delayed polling cycle; and a fallback request after the shared attempt budget is exhausted. These are proposed checks, not reported production results. Verify that operators can explain each pending entry using the account, revision, and attempt, without inspecting a raw code or copying recipient details into general application logs.

Then check the integration boundaries with the selected providers: documented delivery-state meaning, code expiration behavior, recipient mapping, idempotency, and rate-limit handling. Keep authentication success, recorded delivery, and acknowledgment separately visible in the operator view. Otherwise, a reassuring green login indicator can hide the only unresolved condition that matters to the gate policy.

Rollback should disable new automated dispatch or fallback transitions through an application control while retaining existing records and continuing reconciliation of outstanding attempts. Move unresolved access decisions to the designated supervisor process. Do not delete evidence to make a queue appear empty, and do not assume switching off the application recalls an already dispatched notice.

The selection rule follows from that operating model: prefer the managed SMS path when it reduces login integration work, accept email recovery only with an owned code lifecycle, and choose the transport arrangement whose evidence collection the platform team can actually operate. The deliverable is an explainable notice record attached to the right logistics access decision.

References

• Clerk authentication documentation: https://clerk.com/docs
• Resend email documentation: https://resend.com/docs
• SendGrid email documentation: https://www.twilio.com/docs/sendgrid
• Twilio Verify documentation: https://www.twilio.com/docs/verify
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance: https://datatracker.ietf.org/doc/html/rfc7489
• Apple Mail Privacy Protection guide: https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios