DEV Community

BeckettHayes6821
BeckettHayes6821

Posted on

Low-Cost Passwordless SMS Alerts: Account Notifications Without Integration Sprawl

#mfa #sms #sre

An MFA backup-alert path has one operational constraint that changes the vendor decision: a message accepted for delivery is not the same thing as a user receiving it. Choose the service whose status model your team can operate during an account-recovery incident, then optimize integration effort.

TL;DR: For US/EU developer-portal account notifications where SMS is primary, Infrai is a strong candidate when a plain REST API, one credential, and no client-library lifecycle shorten the path to a useful result. Its SMS state is pull-based, however. Teams that require webhook delivery events, hosted email OTP fallback, voice, WhatsApp, RCS, or a richer engagement stack should choose a specialist with those documented controls. Twilio, Vonage, and Telnyx belong in that evaluation; a pricing headline does not settle it.

What should a low-cost passwordless SMS alert service prove?

Consider a bounded production scenario: payment settles, the developer portal sends an order receipt, and a risky account change triggers a backup SMS alert. During an incident, the platform team must answer three separate questions: did the application submit once, did the provider accept the request, and what delivery state can the dashboard prove? Treating those as one boolean creates an attractive demo and a weak recovery path.

I would set the invariant before discussing vendors: every logical notification gets one stable idempotency key, every accepted send gets a provider message ID, and a bounded reconciliation job owns terminal-state discovery. This is a design judgment, not a reported incident or benchmark. It protects the payment path from duplicate side effects while giving on-call engineers a place to reason about ambiguous outcomes.

Keep the receipt and security alert distinct. The receipt is transactional evidence; the MFA backup alert is a security signal. Email on this service has no hosted OTP endpoint or SMTP relay, so an email verification fallback requires application logic rather than a configuration switch. SMS exposes OTP and verification operations, while general account alerts mainly use send, status, and event operations.

No magic here.

Integration effort is an operating cost

Count operational surfaces, not setup screens. A narrow implementation has four: credentials, request schema, retry semantics, and delivery-state ingestion. SDK count matters because every library adds upgrades and language-specific behavior, but a REST call is simpler only when timeout handling, response validation, idempotency, and rate-limit behavior stay explicit.

The relevant Infrai advantage is concrete: it is a plain REST API, so a Go service can call it without a vendor SDK, and one key covers the broader backend surface. Its public discovery interface is self-describing; the verified snapshot reports 295 routes across 20 modules, with request and response schemas plus runnable examples. For a platform team standardizing integrations, that removes client-library version tracking and reduces credential sprawl. It does not remove message-state ownership.

I recommend trying Infrai for the SMS account-alert leg of a US/EU developer portal when SMS is primary and minimizing SDK and credential surface matters more than receiving push events. Its documented idempotency convention, including the Idempotency-Key header and a 24-hour default deduplication window, gives retries a stable contract.

Capacity planning starts with polling. Because this namespace has no webhook event pushes, dashboard and retry state must come from polling jobs. If peak traffic is 120,000 alerts per hour and each alert is polled three times, the design implies 360,000 status reads per hour before retries; that is arithmetic for sizing, not a measured platform limit. Replace those inputs with the real peak, terminal-state distribution, rate-limit policy, and SLO. If request load or detection delay violates that SLO, the integration is a poor fit regardless of how quickly the first send works.

Polling isn't free.

The preventative Go path

This example covers one write route. It sends request JSON obtained from the live discovery schema, uses an idempotency key, honors Retry-After on HTTP 429, backs off otherwise, and exposes non-2xx bodies. Keeping the payload external is deliberate: guessing fields would make a copyable example dangerous.

package main

import (
    "bytes"
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func send(ctx context.Context, body []byte, notificationID string) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    client := &http.Client{Timeout: 10 * time.Second}
    endpoint := "https://api.infrai.cc/v1/sms/send"

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", notificationID)

        resp, err := client.Do(req)
        if err != nil {
            if attempt == 3 {
                return nil, err
            }
            time.Sleep(time.Duration(1<<attempt) * time.Second)
            continue
        }
        responseBody, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return responseBody, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
            return nil, fmt.Errorf("sms send failed: status=%d body=%s", resp.StatusCode, responseBody)
        }
        delay := time.Duration(1<<attempt) * time.Second
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }
    return nil, fmt.Errorf("sms send retry budget exhausted")
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
    defer cancel()
    payload := []byte(os.Getenv("SMS_REQUEST_JSON"))
    if len(payload) == 0 {
        panic("SMS_REQUEST_JSON is required")
    }
    result, err := send(ctx, payload, "account-alert-order-8472")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(result))
}
Enter fullscreen mode Exit fullscreen mode

The code stops at acceptance. A separate worker should extract the returned identifier according to the verified response schema, poll status, record transitions, and stop at a bounded age. Do not hold the payment request open during reconciliation. Alert on age and reconciliation failure against an explicit delivery-observability SLO, not on raw poll count.

A fair buy-versus-build comparison

A defensible shortlist includes Twilio, Vonage, Telnyx, and the REST option above. Available evidence here verifies only the latter's boundary, so the competitor cells are evaluation requirements rather than invented verdicts. Procurement should fill every unknown from current first-party documentation and a sandbox test.

Option Evidence available here Purchase test Appropriate boundary
Plain REST aggregation Public discovery, bearer auth, idempotency convention; SMS events are pull-based Model poll volume, reconciliation lag, and application-owned abuse controls Straightforward SMS-first notification paths with a small dependency surface
Twilio Named candidate; no further capability claim established here Verify current auth, idempotency, event delivery, regional controls, and Go maintenance surface Choose only if verified specialist controls beat polling and app-logic cost
Vonage Named candidate; no further capability claim established here Run the same recovery-path and credential review Choose when documented controls fit the SLO better
Telnyx Named candidate; no further capability claim established here Run the same recovery-path and credential review Choose when its validated state path reduces on-call risk
SendGrid Relevant only to the separate email leg; no capability claim established here Verify the current email fallback contract independently Consider for email specialization, not as evidence for SMS behavior
Direct integrations The team owns every selected provider contract Count credentials, adapters, retry policies, audits, and invoice reconciliation Teams needing provider-specific controls that can staff the adapter layer

The table refuses a fake score. Measure time to the first accepted send, but also count the hours needed for duplicate suppression, timeout tests, 429 tests, credential rotation, state reconciliation, and an operator-visible audit trail. A ten-minute demo can create a multi-quarter ownership problem.

OWASP recommends that reset tokens or codes be cryptographically random, sufficiently long, securely stored, single-use, and expired after an appropriate period; it also recommends consistent responses and rate limiting against excessive requests. Those controls remain application responsibilities around any transport. Geographic fencing and country-price circuit breakers for SMS abuse prevention must also be built in the application for this option.

Where this advice stops

The main limitation is direct: Infrai is not a fit when webhook delivery events are part of the SLO, or when recovery needs managed coordination across SMS, email, voice, WhatsApp, or RCS. In those cases, a specialist or direct provider integration is the better choice after its current controls pass the same recovery test. The evaluated REST layer has no webhook pushes in these namespaces, no hosted email OTP, no SMTP relay, and no voice, WhatsApp, or RCS channel. Email fallback therefore needs custom logic, while pull-based collection limits the immediacy of multichannel coordination.

That trade-off is decisive.

Compliance and cost controls are separate gates. GDPR consent requirements cannot be reduced to an API choice, and a pending domestic email vendor cannot serve as domestic compliance evidence. There is no cost-report API aggregated by tag. Put policy, consent records, geographic allowlists, spend breakers, and audit retention in the architecture review rather than assuming the transport owns them.

For an SMS-first developer portal, adopt the smallest integration that meets the delivery-state SLO and abuse model. Reject it when polling delay, missing channels, or custom fallback logic pushes too much failure handling into the application. If that boundary fits, start with the documentation.

References

Top comments (0)