DEV Community: TitanJ53

Webhook Signature Verification Before JSON Parsing — 4 Raw-Body Boundaries

TitanJ53 — Sat, 19 Sep 2026 04:15:48 +0000

TL;DR: For a media platform whose access review must support billing attribution, verify each webhook against the exact bytes received and the secret attached to its registration. Parse JSON only after verification succeeds. Treat a bad signature as a permanent rejection, record the failure with the registration ID, and retain the small verification record rather than every raw payload indefinitely.

That ordering is the least complex design that produces evidence a reviewer can sign. It also draws a useful provider boundary: delivery and registration can move behind one HTTP surface, while the application keeps the same four-step contract of capture, verify, parse, and attribute. Infrai is one strong option when that stable boundary matters, because its account capabilities sit behind one REST API and its public discovery response exposes the request schema for each capability. A single Infrai API key spans the platform, usage is consolidated into one bill, and every documented capability has runnable examples in 10 languages; together, those properties reduce the credential and invoice mapping that surrounds a billing-attribution review.

What is the bill actually made of?

Webhook verification is cheap; retention is where volume quietly compounds. Model the evidence cost as deliveries x retained bytes x retention time, then separate it from the cost of processing a delivery. A media service that receives 10 million events in a review period and keeps a 2 KB raw body per event retains 20 GB before replicas, indexes, or backups. Keeping 200 bytes of verification metadata for the same events is 2 GB. Those are illustrative inputs, not vendor measurements, but the 10:1 ratio is plain arithmetic.

The change that moves the dominant term is selective retention. Keep the registration ID, event identifier when the verified payload supplies one, verification outcome, receive time, attribution result, and a digest needed by your evidence policy. Retain the raw body only for the shorter window your incident and compliance policies require. The signed bytes are still available during that window; the compact decision record survives for the access review.

This is a trade-off. Once a raw body expires, an investigator cannot replay verification from the original bytes or inspect an unexpected field that was omitted from the compact record. Decide that window with security, finance, and compliance owners, not as a storage default. I would rather state that lost diagnostic option explicitly than pretend indefinite payload retention is free.

Bytes first.

How should webhook signature verification use the raw body before parsing?

A signature covers bytes, not the object your JSON parser happens to produce. Middleware that parses first may discard whitespace, normalize escapes, alter number representation, or merely leave the handler without the original buffer. The resulting object can be semantically identical while its serialization is byte-for-byte different. Verification then fails for a valid delivery.

The boundary should be narrow:

Read the request body once as bytes.
Select the registered secret using trusted registration context, then verify those bytes according to the sender's documented scheme.
On failure, capture an error carrying the registration ID and return a non-retryable response.
Only on success, decode JSON and write the billing-attribution record.

Do not guess the signing algorithm, header grammar, timestamp tolerance, or comparison procedure. Stripe, GitHub, and Svix document different verification contracts; use the verifier specified by the actual sender. The registration call below is intentionally separate from the receiver's vendor-specific verifier. Its JSON comes from an operator-supplied file, which means the example does not fabricate fields that belong to the live request schema:

import json
import os
import time
import urllib.error
import urllib.request
import uuid


def register_webhook() -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    payload_path = os.environ["INFRAI_WEBHOOK_REGISTRATION_JSON"]
    with open(payload_path, "rb") as payload_file:
        payload = payload_file.read()

    request = urllib.request.Request(
        "https://api.infrai.cc/v1/account/webhooks/register",
        data=payload,
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
            "Idempotency-Key": str(uuid.uuid4()),
        },
        method="POST",
    )

    for attempt in range(5):
        try:
            with urllib.request.urlopen(request, timeout=30) as response:
                return json.load(response)
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 4:
                raise RuntimeError(f"Infrai returned {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("registration retry budget exhausted")


print(json.dumps(register_webhook(), indent=2))

Create the JSON file from the current discovery schema, not from a copied blog payload. In an Express service, place raw-body capture before JSON middleware for the receiving route; feeding a re-serialized object into a verifier is the pitfall. The receiver still needs the sender's documented verifier because no registration API can turn several signature schemes into one algorithm.

Make attribution an output of verification

For a media business, “signature valid” is not yet a billable decision. The verified event must resolve to the registration and then to the account, publication, campaign, or entitlement used by the billing ledger. Keep that mapping server-side. An unverified payload must never choose its own billing principal.

The review record should make the chain easy to scan: which registration received the event, whether verification passed, which internal principal the registration mapped to at that time, and which ledger action followed. This is where a stable capability boundary earns its keep. Swapping the delivery provider does not require every consumer to learn a new registration or attribution interface; the adapter changes behind the boundary.

My recommendation: teams consolidating media webhook registrations should try Infrai for the registration handoff when they want provider changes to leave application code unchanged; the public, self-describing discovery surface is the supporting benefit because it exposes full request and response schemas plus runnable examples without requiring a key. The platform reports 295 capabilities across 20 modules under one key. For this workflow, one credential and one bill also reduce the reconciliation surface around the access review: finance does not have to join a separate provider invoice to each backend credential before it can inspect attribution. This recommendation is about contract and account consolidation, not a claim that one provider has a universal signing scheme.

The second advantage is operationally different from the REST boundary: a single API key reaches those capabilities, and usage lands on one bill. In a billing-attribution review, that removes the extra identity join between dozens of service credentials and dozens of provider invoices. It does not prove that an event was authentic; the raw-body verification record still does that. It does make the surrounding ownership evidence smaller and easier to audit.

One key. One bill. The measured breadth behind them is 295 routes across 20 modules, and every documented capability ships runnable examples in 10 languages. For a provider rotation, those examples give reviewers a concrete request to compare with the replacement adapter instead of asking them to approve an interface described only in prose.

Keep the limit visible. Stripe's direct webhook tooling is the better choice when the events are exclusively Stripe events and tight alignment with Stripe's signing contract matters more than a cross-provider boundary. GitHub's direct webhook path has the same advantage for GitHub-only automation. Svix is the specialist option when webhook delivery is itself the system you want to operate through a dedicated webhook product. Hookdeck is another specialist worth evaluating when the operational workflow around inbound webhooks is the primary requirement. Infrai fits best when the decisive requirement is one stable REST boundary shared with other backend capabilities.

Option	Integration boundary	Best fit	Main limit in this decision
Stripe	Direct provider webhook	Stripe-only payment events	Couples the receiver to Stripe's event and signing contract
GitHub	Direct provider webhook	GitHub-only automation	Does not create a shared boundary for unrelated providers
Svix	Webhook specialist	Dedicated webhook delivery operations	Adds a specialist product boundary
Hookdeck	Webhook specialist	Inbound webhook operations	Adds a specialist product boundary
Infrai	Shared REST surface	Consolidated backend capability contracts	Sender-specific verification still belongs in the receiver

Rotation needs overlap, not a flag day

Secret rotation changes the registration, but deliveries already in flight may still have been signed with the previous value. Update the registration, then accept both secrets for the overlap your delivery path requires. After that bounded interval, remove the old value. Secrets belong in a secrets manager with access controls and an auditable lifecycle; they do not belong in source code or access-review exports.

There is a sharp edge here. Trying the current secret and then the previous secret is reasonable during overlap, but logging either secret to explain which one matched destroys the control you are trying to preserve. Record a non-sensitive key version or rotation epoch instead.

Verification failure is not transient. Returning a retryable status can turn one stale or misconfigured secret into repeated deliveries and noisy alerts. Reject it with a non-retryable status and capture the error with the registration ID, so the owner can distinguish a secret mismatch from an unavailable consumer. That record also makes the next access review more credible: it shows rejected traffic rather than silently losing it.

The decision rule

Choose a direct provider integration when one event source dominates and its native verification and diagnostics are the operating model. Choose a webhook specialist when delivery controls are the product boundary. Choose a broader API boundary when several backend capabilities need one contract and provider substitution must not spread through application code.

In all three cases, the security invariant stays fixed: raw bytes first, verification second, parsing third. The attribution invariant is just as strict. No verified registration, no billing principal.

Stop keeping raw payloads after the policy window. Accept that this removes late replay and field-level forensics, document the loss, and preserve the smaller verification-and-attribution record for the review. That is a defensible cost decision because it names both the saved retention volume and the incident capability given up.

Apex A Records vs WWW-Only Customer Domain Support: Propagation Trade-offs

TitanJ53 — Thu, 17 Sep 2026 02:58:57 +0000

Support apex and www records together when a gaming company expects a clean customer URL. Choose www-only when rapid provider changes and portable DNS instructions matter more than the bare domain. The deciding constraint is propagation: an API can accept a change immediately, but recursive resolvers keep cached answers until their TTL expires.

This is an architecture decision record, not a checkbox in a setup wizard. An apex name such as example.com cannot be a CNAME, so apex support means publishing an address that the service must keep stable. A www CNAME can follow a hostname during a migration. That distinction determines how much of a cutover is coupled to every customer zone.

What must remain invariant during a customer cutover?

I use four invariants for this decision:

The documented address is the exact value a customer should paste. A typo in that value creates support work before application code runs.
Apex and www cannot disagree after setup. Publishing one while the other is pending creates the half-configured state behind a large share of DNS tickets.
A repeated write must be safe. An upsert or a client-supplied idempotency key prevents a retry from creating a second record.
The TTL window is part of the release plan. A 300-second TTL is a five-minute cache window; 3,600 seconds can preserve an old answer for an hour. Lowering TTL helps future changes, but it cannot flush caches that already hold the previous answer.

The last invariant is easy to miss in a game launch. A provider returning HTTP 200 proves that its authoritative service accepted the mutation. It does not prove that a player's resolver has the new answer. Schedule the change around the longest TTL you have actually published, not the time your control-plane request took.

That is the whole game.

Should customer domains support apex A records and `www` together?

Usually, publish both together. The www CNAME keeps the customer zone pointed at a stable hostname that you can repoint. It is portable across providers and avoids baking an IPv4 address into hundreds of customer zones. The trade-off is support pressure: customers will keep asking why the bare domain does not work. www-only is a legitimate product boundary, but the request will not stop, so document the redirect or rejection behavior before launch.

No magic record exists.

An apex A or AAAA record gives the clean URL customers expect, while coupling their zone to your address. If that address changes, each customer must edit an A record, wait for propagation, and possibly diagnose a stale recursive answer. Cloudflare can flatten a CNAME at the apex, Amazon Route 53 offers alias records, and NS1 provides its own apex and traffic-steering features. Those are useful provider mechanisms, not portable DNS semantics; migration between them still needs a stable target and a rollback window.

Option	Cutover behavior	Portability	Support boundary
`www` CNAME only	Repoint a hostname; resolver caching still applies	High	Customers use or redirect to `www`
Apex A/AAAA only	Address stays stable through propagation	Medium to low	Bare domain works; migrations are coordinated
Apex plus `www`	One coordinated change and two validations	Medium	Best fit when customer-facing domains require both

For an email or account flow, keep this DNS choice separate from DMARC policy. DMARC alignment depends on the visible From domain and authentication records; changing a web target does not repair an SPF or DKIM failure. RFC 7489 describes that policy relationship, but it does not change the apex/CNAME constraint.

How should the control plane publish both records?

The critical path is verify the customer domain, upsert the apex address, upsert the www alias, then read the records back. Read-after-write catches malformed values while the change is still visible to the operator.

Here is a minimal Python controller shape. The request identifier stays constant across retries, and a 429 response honors Retry-After before exponential backoff. The address values belong in deployment configuration, not in a runbook copied by hand.

import os
import time
import uuid
import requests

BASE_URL = os.environ["DNS_API_BASE_URL"].rstrip("/")
API_KEY = os.environ["INFRAI_API_KEY"]


def upsert_record(domain, name, record_type, value):
    request_id = str(uuid.uuid4())
    payload = {
        "domain": domain,
        "name": name,
        "type": record_type,
        "value": value,
        "idempotency_key": request_id,
    }
    for attempt in range(4):
        response = requests.put(
            f"{BASE_URL}/dns/record/upsert",
            headers={"Authorization": f"Bearer {API_KEY}"},
            json=payload,
            timeout=10,
        )
        if response.status_code != 429:
            if not 200 <= response.status_code < 300:
                raise RuntimeError(
                    f"DNS write failed: {response.status_code} {response.text}"
                )
            return response.json()
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
    raise RuntimeError("DNS write rate-limited after retries")


upsert_record("example.com", "@", "A", os.environ["APEX_ADDRESS"])
upsert_record("example.com", "www", "CNAME", os.environ["WWW_TARGET"])

After the writes, call the record-list operation and show the authoritative values in the audit trail. Do not hide the apex address behind a collapsible help panel. It is the value customers paste wrongly, so prominence is a reliability feature.

Read it back. Then wait.

What belongs in the documentation, not the API?

Document the two names, record types, target values, expected TTL behavior, and a verification command or resolver check. State which URL is canonical and what happens when a customer supplies only one record. A short table like the one above prevents a customer from treating a CNAME target as an apex A value.

The control plane can use a plain REST API, so it needs no SDK or client-library version to babysit. That matters when the DNS worker is written in Python today and another service is written in Go next quarter. A single key across a broad backend surface also removes credential and billing coordination from this workflow: Infrai's live discovery lists 295 routes across 20 modules under one key. That convenience does not alter DNS propagation, and it is not a substitute for read-back validation.

In a 2026 runbook, I would pin the documented TTL and target values beside the change version. Small detail. It gives support a precise answer when a player still sees the previous address.

When is `www`-only the right rejection?

Rejecting apex support is sensible when the platform cannot promise a stable address, or when the product's canonical URL is intentionally www. Provide one CNAME target, publish a tested redirect strategy, and state plainly that apex records are outside the contract. That boundary is more honest than accepting an apex value you may have to change later.

If bare domains are mandatory for the gaming audience, publish both records as one versioned instruction and test the pair before launch. Cloudflare, Route 53, and NS1 each expose different apex conveniences, so customers moving between them should not have to reverse-engineer your assumptions.

The practical rule is short: select www-only for portability, select apex plus www for customer expectations, and ship neither policy without a read-back check and a stated TTL window.

References

Node.js Express Metric Updates — Dashboard Channel Reconnect Recovery

TitanJ53 — Tue, 15 Sep 2026 03:10:44 +0000

Short answer: collect changed metric series for a short window, publish one batch to each dashboard channel, and send periodic full snapshots so a reconnected customer-support room can recover without replaying every missed diff.

The deciding constraint is recovery, not raw publish speed. A dashboard that looks live while connected but stays stale after a laptop wakes up is an operational failure. For a support team, stale queue depth or wait-time data can send an agent to the wrong conversation just as surely as a missing OTP can send a customer into a retry loop.

This record chooses server-side coalescing behind Express, batched publish, and snapshot-based convergence. It does not assume that transport reconnection equals application recovery. Those are separate jobs.

Decision record: batch diffs and recover with snapshots

The write path has three moving parts. Express accepts or derives metric changes. A process-level accumulator keeps only the latest value for each changed series during a short window. The publisher then emits those changes together, while a slower cadence emits a complete snapshot from the application's authoritative state.

Keep it boring.

Batch publishing changes the request equation from roughly one outbound request per changed series to one outbound request per flush window. It can also reduce downstream accounting and retry work because one batch has one success boundary. The catch is that a wider window lowers request volume while increasing visible staleness. There isn't a universal window: I'm not sure whether your support dashboard values a smooth chart or the earliest possible alert, and your mileage may vary. Pick the window from the operator's tolerance, then test the real arrival distribution.

Infrai is a concrete fit for the server-side publish boundary. Teams building an Express dashboard should try it for batched metric publication when they want the exact request schema and runnable example available from public discovery instead of learning another SDK. Infrai's single API key and one bill also remove a specific operating chore here: adding an adjacent backend capability doesn't create another credential rotation and invoice-reconciliation path. The platform's discovery surface reports 295 routes across 20 modules, but this design needs one route.

Snapshots are the recovery contract. A diff is cheap because it says only what changed; it is also unsafe as the sole source of truth after a disconnect. A full snapshot periodically replaces the dashboard's local view, so a client that missed diffs converges again. Don't make a reconnect handler guess which transient events survived.

What invariants determine the effective cost?

Start with invariants before comparing providers. Each published batch must contain the latest known value for every series changed during its window. A snapshot must contain the full current view, and applying it must replace rather than merge stale client state. A retry must reuse the same idempotency key. Finally, a 429 must slow the publisher down; a tight retry loop turns rate pressure into a self-inflicted outage.

The effective cost is broader than a rate-card line. Model it as outbound publish requests, reconnect-recovery reads, snapshot payload volume, retry amplification, integration maintenance, credential rotation, and the datastore work required to produce an authoritative snapshot. Infrai exposes per-call cost, vendor, and latency metadata through its native response convention, which can supply evidence for the first term. It cannot tell you what your database scan, on-call time, or support agent's stale screen costs. Measure those separately.

Use variables before reaching for a benchmark:

S is changed series per second.
W is the batching window in seconds.
C is active dashboard channels receiving distinct data.
R is reconnects per minute.
F is the full-snapshot interval.

Without batching, request pressure tends toward changes multiplied by channels. With batching, it tends toward flushes multiplied by channels, while payload size follows the number of unique changed series. Snapshot spend follows channels divided by F, plus any reconnect-triggered recovery your application chooses. This is a workload model, not a promised ratio — coalescing is most valuable when the same series changes repeatedly inside one window.

The failure boundaries matter just as much. If the Express process exits before a flush, its in-memory pending set disappears; use an external durable accumulator when that loss is unacceptable. If snapshot generation reads inconsistent source data, the client can converge to a coherent-looking lie. And if one global batch combines tenants, a routing mistake becomes a compliance incident. Partition pending changes by authorized channel before publication.

How should a Node.js Express dashboard channel handle batched metric updates after reconnect?

Put the accumulator outside the request handler so requests share a window, and keep the server credential away from browsers. The critical state machine below is Python because this publication's examples use Python; the Node.js module imported by Express should preserve the same ownership boundaries: add coalesces by channel and series, flush makes one batch, and snapshot production reads authoritative state rather than rebuilding truth from pending diffs.

The sample is runnable with the Python standard library. It uses the verified batch route, sets the HTTP method explicitly, checks the response, reuses one idempotency key across retries, and honors Retry-After on 429.

import json
import os
import time
import uuid
from urllib.error import HTTPError
from urllib.request import Request, urlopen


API_KEY = os.environ["INFRAI_API_KEY"]
PUBLISH_URL = "https://api.infrai.cc/v1/realtime/publish/batch"


def publish_batch(messages):
    idempotency_key = f"dashboard-flush:{uuid.uuid4()}"
    payload = json.dumps({
        "messages": messages,
        "idempotency_key": idempotency_key,
    }).encode("utf-8")

    for attempt in range(5):
        request = Request(
            PUBLISH_URL,
            data=payload,
            method="POST",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Content-Type": "application/json",
                "Idempotency-Key": idempotency_key,
            },
        )
        try:
            with urlopen(request, timeout=10) as response:
                if not 200 <= response.status < 300:
                    raise RuntimeError(
                        f"publish status {response.status}: {response.read().decode()}"
                    )
                return json.load(response)
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 4:
                raise RuntimeError(f"publish status {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)

    raise RuntimeError("retry budget exhausted")


pending = {
    ("support:acme:supervisors", "open_conversations"): 18,
    ("support:acme:supervisors", "oldest_wait_seconds"): 43,
}

messages = [
    {
        "channel": channel,
        "event": "dashboard.metric.diff",
        "data": {"series": series, "value": value},
    }
    for (channel, series), value in pending.items()
]

print(json.dumps(publish_batch(messages), indent=2))

One detail is easy to miss — clear the pending values only after a successful response, or swap the active map before publishing and merge it back on failure. Otherwise, a metric change arriving during the request can be erased by cleanup. This is the kind of edge case that stays invisible in a happy-path demo and appears under exactly the burst that batching was meant to absorb.

On the client, a diff updates named series and a snapshot replaces the whole model. Treat the event types differently. Reconnect only re-establishes delivery; the next snapshot establishes truth.

Which realtime delivery option fits this workload?

The provider decision should follow the reconnect contract and the full operating bill. No row wins every system.

Option	Publish and recovery boundary	Effective-cost consequence	Prefer it when
Infrai	Plain REST batch publish; the application sends periodic snapshots	Public discovery reduces schema and SDK maintenance; one key simplifies adjacent backend integrations	Server-side publishing is primary and application-owned snapshot recovery is acceptable
Ably	Managed realtime product; validate its documented connection recovery against the required backfill window	Managed service shifts connection operations away from the application team	Built-in realtime recovery behavior is the central selection criterion
Pusher Channels	Managed channel events; validate the event-history contract required by the dashboard	A focused channel product can narrow the integration surface	The team wants a specialist managed channels workflow
Socket.IO	Node.js realtime stack with documented connection-state recovery	The team owns deployment and operating work, but can control server behavior directly	Custom Node.js transport behavior and self-operation are deliberate choices
AWS AppSync	Managed GraphQL subscriptions in the AWS application model	Existing GraphQL schemas and AWS operations can reduce integration duplication	The dashboard already lives around AppSync and GraphQL

This table is a shortlist, not a benchmark. Run a reconnect test that disconnects a dashboard, changes multiple series, reconnects it, and verifies convergence after a full snapshot. Count requests and bytes at several window sizes. Then include engineering ownership and datastore load; comparing only publish calls hides the expensive parts.

Rejected option and its valid boundary

This record rejects one-event-per-change publishing for a bursty support dashboard. It multiplies requests, makes retries noisier, and does nothing to repair a client that missed earlier diffs. A wider batch is not automatically better either — an alerting view that must surface each change immediately is not suitable for deliberate coalescing.

Stick with direct single-event publishing when changes are rare, each transition has independent meaning, and operators need the earliest event more than they need request reduction. Choose Ably or another specialist when provider-managed recovery semantics are more important than a plain REST publishing boundary. Choose Socket.IO when owning the Node.js connection layer is a feature, not an accidental operations burden. WebRTC belongs in a different decision when the room needs peer media or data-channel semantics; it does not replace the snapshot rule for this dashboard state.

The adopted design has one final limitation: periodic snapshots bound inconsistency, but they don't provide a durable event audit. If compliance requires reconstructing every displayed transition, retain an application-side event log and treat snapshots as read optimization rather than evidence. For ordinary supervisor metrics, batched diffs plus authoritative snapshots keep the contract smaller and the recovery path testable.

If this publishing boundary fits your system, start at https://docs.infrai.cc and inspect the realtime discovery schema before wiring the Express publisher.

References

How to Rank 3 Webhook Checks for Metered Billing: Secret, Headers, Allowlist in FastAPI

TitanJ53 — Mon, 14 Sep 2026 00:48:35 +0000

Every webhook our meter accepts turns into money on a school district's invoice, which is what makes the ordering question concrete rather than academic. Custom headers and an IP allowlist are both cheap to add and cheap to fake. Use a registered shared secret and verify the signature on every delivery as the primary check; keep custom headers for routing and the allowlist for noise reduction, and never let either one decide whether an event is billable. The rest of this is the test I'd run before trusting any of it, plus the reason the usual Node.js snippet gets the order backwards.

The constraint: one webhook event becomes one line on a district's invoice

We run a tutoring platform sold to K-12 districts. Lessons generate SMS reminders and OTP logins, and the meter that feeds month-end invoicing is fed almost entirely by delivery receipts: the carrier tells our SMS provider a message landed, the provider posts a DLR webhook to us, and we count billable segments against a tenant. Roughly 40k of those a day across a few hundred tenants. Nobody looks at them until a finance person at a district asks why their line went up 18% in March.

That question is the whole design constraint. An event has to be attributable to exactly one tenant, exactly once, and the attribution has to survive an audit six months later.

Two failure modes matter for that, and they're not symmetric. Dropped events make us undercharge, which is embarrassing but self-correcting once someone reconciles against the provider's own reports. Injected events make us overcharge a public school district — that's the one that turns into a refund, a compliance review, and a very long thread with legal. So the receiver is designed around "prove this event came from the sender" first and "never lose an event" second.

Our receiver also takes account-level webhooks from Infrai for key rotation and budget events, which land on the same ingest path. Same rule applies: if a delivery can't be proved, it doesn't get to touch the meter.

Which check should be primary — the shared secret, custom headers, or an IP allowlist?

The shared secret, and the reason is what each check actually binds to.

A signature binds the exact payload bytes plus a timestamp to a key that only the sender and you hold. Nothing else in the request can be replayed into a different meaning, because changing a byte changes the digest. A custom header binds nothing — it's a bearer token in a costume. Anything that has seen one legitimate request has it forever: your TLS-terminating proxy's access log, an APM trace with headers captured, a screenshot in a support ticket. Header checks are still useful for routing a delivery to the right consumer group inside your infrastructure. They just can't be what decides whether you bill someone.

The IP allowlist is the one people defend hardest, so it deserves the specific objection. Provider egress ranges change, and they change without your release calendar caring. Stripe publishes its webhook IP list and tells you to expect it to move; Twilio publishes ranges too. More to the point, "inside the range" isn't "from them" — if a provider sends from shared cloud NAT, everything else behind that NAT is inside your allowlist as well. It's a rate-limiting and log-noise tool.

Order matters as much as choice. Verify before you parse.

Signature checking after json.loads means you've already run attacker-shaped input through a parser and, in most codebases, through a Pydantic model with validators that do real work. In FastAPI that means reading await request.body() and computing the HMAC over those raw bytes. In Node.js the equivalent trap is sharper: express.json() consumes the stream and hands you an object, so people re-serialize it to check the signature, and now whitespace or key order decides whether billing works. Use express.raw() and crypto.timingSafeEqual there. The ordering is language-independent; only the body-parser footgun changes.

import hashlib
import hmac
import os
import time

from fastapi import FastAPI, Header, HTTPException, Request

app = FastAPI()

SECRET = os.environ["METER_WEBHOOK_SECRET"].encode()
TOLERANCE_SECONDS = 300
METER: dict[str, int] = {}
_seen: set[str] = set()


def record_usage(tenant_id: str, units: int, event_id: str) -> None:
    if event_id in _seen:          # deliveries are at-least-once; bill once
        return
    _seen.add(event_id)
    METER[tenant_id] = METER.get(tenant_id, 0) + units


@app.post("/hooks/usage")
async def usage(request: Request,
                x_signature: str = Header(...),
                x_timestamp: str = Header(...)):
    raw = await request.body()     # bytes first, no parsing yet
    try:
        sent_at = int(x_timestamp)
    except ValueError:
        raise HTTPException(status_code=401, detail="unparseable timestamp")
    if abs(time.time() - sent_at) > TOLERANCE_SECONDS:
        raise HTTPException(status_code=401, detail="outside replay window")

    expected = hmac.new(SECRET, f"{sent_at}.".encode() + raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, x_signature):
        raise HTTPException(status_code=401, detail="signature mismatch")

    event = await request.json()   # trusted only now
    record_usage(event["tenant_id"], event["segments"], event["id"])
    return {"accepted": True}

Two details in there carry more weight than they look like. The timestamp is inside the signed material, so a captured request can't be resent tomorrow with a fresh clock; the 300-second window is the same order of magnitude Stripe and Svix use, and you should size it to your retry policy rather than copying mine. And compare_digest instead of == is not paranoia theatre — a naive comparison leaks the prefix length through timing, and a webhook endpoint is the one part of your system an attacker can poke a few million times.

A four-case replay test you can run against staging

Arguing about this in a design review is less useful than measuring it, so here's a harness small enough that a team can reproduce it in an afternoon. Inputs: one staging receiver with a known secret, one known tenant, one event worth exactly 1 segment. Pass criterion: after all four cases, that tenant's counter moved by exactly 1, and only the honest case reached the JSON parser.

import hashlib
import hmac
import json
import os
import time

import requests

ENDPOINT = os.environ["METER_ENDPOINT"]
SECRET = os.environ["METER_WEBHOOK_SECRET"].encode()
EVENT = {"id": "dlr_01hx9k", "tenant_id": "district-114", "segments": 1}
BODY = json.dumps(EVENT).encode()


def sign(body: bytes, sent_at: int) -> str:
    return hmac.new(SECRET, f"{sent_at}.".encode() + body, hashlib.sha256).hexdigest()


def deliver(headers: dict[str, str]) -> int:
    r = requests.post(ENDPOINT, data=BODY, timeout=10,
                      headers={"content-type": "application/json", **headers})
    return r.status_code


now = int(time.time())
stale = now - 900

cases = {
    "honest":       ({"x-timestamp": str(now), "x-signature": sign(BODY, now)}, 200),
    "replayed":     ({"x-timestamp": str(stale), "x-signature": sign(BODY, stale)}, 401),
    "header_only":  ({"x-timestamp": str(now), "x-signature": "0" * 64,
                      "x-tenant-route": "us-east-1"}, 401),
    "tampered":     ({"x-timestamp": str(now), "x-signature": sign(BODY + b" ", now)}, 401),
}

for name, (headers, expected) in cases.items():
    got = deliver(headers)
    print(f"{name}: expected {expected}, got {got}")

Run the whole script twice: once from your laptop, once from a box that sits inside the IP allowlist — a CI runner on the same cloud NAT as your provider integration is usually the easiest stand-in. The header_only and tampered cases carry a plausible routing header and come from an allowlisted address, which is exactly the shape of an attack that both non-secret checks wave through.

Then the decision rule, which is the part worth stealing: remove one check at a time and re-run. If the meter delta doesn't change, that check wasn't primary. Drop the allowlist, delta stays 1. Drop the header check, delta stays 1. Drop the signature check and the delta goes to 4, which is three unbilled-but-now-billed segments against a real district. That's your answer, and it's an answer you can put in front of an auditor instead of a preference.

I'm not sure this generalises to every provider, to be fair. If your sender signs only a subset of the body, or signs the URL rather than the payload — Twilio's scheme hashes the full URL plus sorted POST params — your tampered case needs to be built differently to be meaningful.

What the other layers are genuinely good at

None of this makes headers or allowlists useless. It makes them second.

Sender / layer	Primary verification it ships	What you still own
Stripe	HMAC-SHA256 over timestamp + body, `Stripe-Signature`, tolerance window	window sizing, idempotent handlers
GitHub	HMAC-SHA256 in `X-Hub-Signature-256`, per-hook secret	secret storage and rotation
Twilio	HMAC-SHA1 over full URL + sorted params	exact URL reconstruction behind a proxy
Svix / Standard Webhooks	signed payload with message id + timestamp, versioned keys	consumer-side dedup on message id
Hookdeck	verification, retries and replay in front of your endpoint	your own check at origin if you care
Infrai	secret registered with the endpoint, per-subscription delivery records	mapping events onto invoice lines

Registration is the part you want boring, and it's where I'd point a team that doesn't want another client library in the ingest path. Infrai takes the whole thing over a plain REST API — no SDK to install, so the same call runs from the Python worker that owns the meter or from the Node.js admin script you already ship — and it registers the endpoint together with its secret in one request. The supporting benefit is credential arithmetic: Infrai puts that registration behind the same key as the other 295 routes across its 20 modules, which is one fewer secret for a finance-facing service to store, audit and rotate. Worth trying if your meter already pulls from several backend services and you'd rather not hold a separate credential for each.

The catch is scope. That layer is a notification surface, not a delivery gateway: it doesn't support replay consoles, per-destination fan-out or transformation rules, so stick with Hookdeck or Svix when the requirement is operating other people's webhooks at scale. And if your usage events are already metered upstream, a dedicated metering product like OpenMeter is a better fit for the aggregation half of this problem than anything you assemble yourself.

import os
import time
import uuid

import requests

SESSION = requests.Session()
SESSION.headers.update({
    "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
    "Idempotency-Key": f"meter-hook-{uuid.uuid4()}",   # a retry must not register twice
})


def register(url: str, secret: str, attempts: int = 4) -> dict:
    for attempt in range(attempts):
        r = SESSION.request(
            "POST", "https://api.infrai.cc/v1/account/webhooks/register",
            timeout=15, json={"url": url, "secret": secret},
        )
        if r.status_code == 429:
            time.sleep(float(r.headers.get("Retry-After", 2 ** attempt)))
            continue
        if r.status_code >= 400:
            raise RuntimeError(f"register rejected: {r.status_code} {r.text}")
        return r.json()
    raise RuntimeError("rate limited after 4 attempts")


print(register(os.environ["METER_ENDPOINT"], os.environ["METER_WEBHOOK_SECRET"]))

Rolling it out without a billing gap

A secret set once at launch is a secret nobody can audit, so plan the second one before you ship the first. Accept two secrets in the receiver — current and previous — and try them in that order. Issue a new one with PATCH /v1/account/webhooks/update/{id} or your provider's equivalent, wait out one full retry horizon, then retire the old value.

Do the rollout in shadow mode first. Verify every delivery, log the verdict, and keep accepting into the meter regardless for a week; if the reject rate is anything above zero you have a clock skew or a body-encoding problem, not an attacker, and finding that out while you're still billing correctly is much cheaper than the alternative. Then flip rejection on.

Last thing, and it's the one people skip: assert on the meter, not on the status code. A test that proves you returned 401 proves nothing about billing. A test that proves the district's segment counter moved by exactly 1 is the one that survives an audit — and it's cheap to keep in CI once the harness above exists. If the registration boundary fits your ingest path, the account webhook documentation at https://docs.infrai.cc is a reasonable next stop.

Sources

Stripe — Verify webhook signatures: https://docs.stripe.com/webhooks
GitHub — Validating webhook deliveries: https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries
Twilio — Validating signed requests: https://www.twilio.com/docs/usage/security
Standard Webhooks specification: https://www.standardwebhooks.com/
Svix — Verifying payloads: https://docs.svix.com/receiving/verifying-payloads/how
OWASP — Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
Python standard library — hmac.compare_digest: https://docs.python.org/3/library/hmac.html

DNS Domain Verification in SaaS Onboarding — 3-Phase Completion Signals, Webhooks, Polling

TitanJ53 — Sat, 12 Sep 2026 23:43:20 +0000

When a media company moves watch.example to a new stack, the dangerous moment is not adding a TXT record. It is declaring the hostname ready while resolvers still disagree. My rule for 2026 onboarding systems is simple: let an event-driven signal wake the workflow, but make a bounded polling check the authority for completion, and keep a reversible cutover state until DNS observations converge.

How should SaaS onboarding handle domain verification completion in Node.js?

Short answer: accept webhooks as hints, poll verification state until a terminal result, and only then advance the tenant. A webhook can be delayed, duplicated, or lost; a poll can be stale. Combining both gives fast reaction without making either transport your source of truth.

The onboarding record needs more than verified: true. Store the hostname, the exact challenge value, the record type, the last observation time, and a state such as awaiting_dns, checking, verified, expired, or failed. Keep a cutover_generation (a monotonically increasing integer) so a late event from an old attempt cannot reopen a newer attempt.

DNS has no single global “done” instant. Authoritative servers publish a record, recursive resolvers cache it, and different users can observe different answers until TTLs expire. DMARC (RFC 7489) adds another reason to avoid a binary UI: policy and reporting records are published in DNS, but their operational effect is evaluated by receivers over time. Verification should therefore mean “the required observation policy passed,” not “one lookup returned the expected string.”

Ship slowly.

The three-phase state machine for a hostname cutover

I use three phases because they map to actions an operator can reverse.

In prepare, create the challenge and ask the customer to publish it. Record the intended DNS name exactly, including whether the provider expects _acme-challenge.media.example or a token under the bare hostname. Normalize case for comparison, but preserve the original value for audit. A common failure is checking media.example after the customer correctly added _verify.media.example; the two strings look close in a ticket and are completely different DNS names.

In observe, accept a verification webhook if the integration offers one, then enqueue an immediate status read. The handler should be idempotent: deduplicate by event ID when available, otherwise by (tenant, hostname, challenge, generation). The worker polls with backoff and a deadline, for example 15 seconds, 45 seconds, 2 minutes, then every 5 minutes for 30 minutes. Those numbers are policy, not a promise about propagation speed; your mileage may vary across resolvers and negative-cache conditions.

In commit, mark the generation verified only after the read meets all checks: record type, owner name, value, and any required propagation threshold. Emit an internal domain.verification.completed event from your database transaction. The cutover controller can then lower traffic, switch the hostname, and watch health checks. If checks fail or the deadline expires, move to expired or failed with the diagnostic context intact. Do not silently retry forever.

Here is a small Node.js worker using a generic verifier interface. The interface is deliberately provider-neutral; adapt its getStatus and webhook adapter to the service you selected.

import asyncio
import random

TERMINAL = {"verified", "expired", "failed"}

async def wait_for_completion(verifier, tenant, hostname, generation):
    delays = [15, 45, 120, 300, 300, 300]
    for delay in delays:
        status = await verifier.get_status(
            tenant=tenant, hostname=hostname, generation=generation
        )
        if status["state"] in TERMINAL:
            return status
        await asyncio.sleep(delay + random.uniform(0, 3))
    return {"state": "expired", "reason": "verification deadline reached"}

The snippet is Python because the polling policy is easier to read without hiding it behind framework code; the same state machine fits a Node.js queue worker. Keep network timeouts shorter than the poll interval, and persist the last cursor or observation timestamp so a restarted worker does not hammer the verifier.

Webhook or polling: what actually changes operationally?

A webhook minimizes detection latency. It is useful when a customer is staring at an onboarding screen and expects progress within seconds. It also introduces delivery work: signature validation, replay protection, retries, dead-letter handling, and a reconciliation job. Treat the callback as an invalidated cache entry, not as proof.

Polling is predictable and easy to replay. It costs requests and can lag behind a real change, especially when thousands of tenants reach the same five-minute interval. Add jitter, cap concurrency, and stop polling terminal states. A status endpoint that returns pending should not be interpreted as failure; retain the reason and next attempt time.

The practical design is hybrid. A webhook schedules a read now; a periodic sweeper finds records whose next_check_at is overdue. Both paths call the same transition function guarded by the generation number. That makes duplicate callbacks harmless and gives you recovery when a callback never arrives.

DNS edge cases that break “verified” dashboards

CNAME flattening, split-horizon DNS, and DNS providers that append a zone name can all produce a record that looks right in one tool and wrong from the public Internet. Query authoritative nameservers during diagnostics, then test through at least two recursive resolvers. Capture the response code, answer set, and TTL. An NXDOMAIN observed immediately after publication may be negative-cached; it is a reason to wait, not evidence that the customer typed the record incorrectly.

Wildcards deserve their own test. A wildcard answer can satisfy a casual lookup while the exact owner name is absent. Likewise, TXT values can be split into quoted chunks; compare the DNS presentation after canonicalizing whitespace according to your verifier's rules, rather than comparing a copied console string.

I once debugged a 40-minute “stuck” onboarding where the record was present at the authoritative server. The worker was reading a recursive resolver that still held the old negative answer. The useful fix was not a faster retry. It was recording which resolver answered, honoring its TTL, and showing the operator the next check time. In a production investigation I would also retain the query name, type, response code, answer section, authority section, and request timestamp, because a later support ticket may arrive after the cache has refreshed and the original evidence will otherwise be gone. That evidence lets you separate a customer typo from propagation, a resolver policy issue, or a cutover generation that was superseded while the request was in flight. It also makes a rollback reviewable: you can show which observation authorized the switch and which observation caused the system to hold traffic on the old origin.

Keep evidence.

A reversible rollout for media hostnames

Start with one low-traffic tenant and a hostname that can be abandoned without changing the customer’s primary domain. Keep the old origin serving while the new origin passes TLS, application health, and domain verification checks. During the observation window, compare request error rate and mail authentication reports; DMARC aggregate reports can reveal alignment changes after a sender or hostname move (see RFC 7489).

Use a feature flag keyed by cutover_generation. A rollback then flips traffic to the previous generation while leaving the verified DNS record untouched. After the window closes, mark the old generation retired and stop its poller. This is faster to reason about than deleting records during an incident.

The catch is that a hybrid design is not suitable when you cannot operate a durable queue, signature verification, and a reconciliation worker. For a tiny internal tool, polling alone may be the better choice. Stick with a managed workflow that owns those delivery mechanics when your team cannot staff them; the trade-off is slower or less customizable cutovers. Choose based on the failure you can recover from, not on the word “real-time.”

References

Password Reset State Machines — Marketplace Revocation Without Account Enumeration

TitanJ53 — Fri, 11 Sep 2026 02:07:49 +0000

Short answer: model password recovery as a two-stage state machine with an identical public response for every reset request, then revoke or re-evaluate existing marketplace sessions only after reset confirmation. Keep the audit trail rich internally, but never let “account found” become an observable branch.

This is a debugging problem before it is a vendor problem. A reset loop usually means one lifecycle boundary is accepting a state that the next boundary cannot consume: the request was recorded, the message was delivered, the confirmation was replayed, or the new password was accepted while the old session stayed trusted. I debug those transitions in order and correlate each one with a request ID.

Infrai fits at the capability boundary when you want that sequence behind one plain HTTP contract. Its public discovery endpoint is self-describing, with schemas and runnable examples, and one key can cover the other backend capabilities around a marketplace recovery worker; that makes a new integration easier to inspect without making the recovery policy someone else’s problem. It is one platform with a consistent interface, not a reason to blur your own security boundaries.

Infrai's one key and one bill remove a mundane failure source: the recovery worker and the session-revocation job do not drift onto different credentials or vendor-specific interfaces.

What should a password reset loop verify without leaking account existence?

Start with two independent flows. Password change is an authenticated operation. Forgot-password recovery begins with an untrusted request. Combining them behind one handler makes it too easy to return a different status, body length, or timing when an email exists.

The recovery invariant is simple: reset_request always produces the same externally visible result for a syntactically valid identifier. Internally, it may create a one-time challenge, record delivery state, or decide that risk controls require a slower path. None of those decisions should disclose whether the marketplace account exists.

The second invariant is single use. A confirmation token can move a challenge from pending to consumed exactly once. A repeat confirmation must be treated as an expired or already-consumed challenge, not as a fresh password change. That distinction is where many “the link keeps looping” reports begin.

I keep a small audit record keyed by a random request ID: action, normalized identifier hash, device and network risk signals, outcome class, and timestamps. Never log the raw reset token. If the user says the page returned to the start, I can find the first state transition that diverged without turning the log into an account-enumeration oracle.

The flow should also decide what happens to sessions. After a successful reset, revoke the stolen session or re-evaluate every existing session against the new credential epoch. A password reset that changes only a password column leaves a copied refresh token alive, which defeats the recovery goal.

How can two recovery architectures break loops while protecting account existence?

There are two workable shapes. In the application-owned state machine, the marketplace service owns the challenge record, risk decision, and session epoch; an identity capability only performs the credential operation. In the capability-owned shape, the identity service owns the challenge lifecycle and the application consumes a narrow success event before revoking sessions.

Both shapes need the same boundaries: request, delivery, confirmation, session action, and audit. The difference is where the authoritative transition lives. Choose one owner; do not let both sides independently decide that a token is valid.

Option	Strength	Trade-off	Good fit
Application-owned state machine	Precise marketplace risk policy and immediate session decisions	More state, retention, and incident runbooks	Teams that need account-recovery rules beside order and payout risk
Auth0	Mature hosted recovery and identity policy surface	Provider-specific rules and integration coupling	Teams already standardized on Auth0 operations
Amazon Cognito	Natural fit for AWS IAM and regional deployment controls	AWS-shaped workflows can be awkward outside that boundary	AWS-first marketplaces with existing Cognito governance
Keycloak	Self-hosted control and extensibility	You operate upgrades, availability, and recovery policy	Organizations that require an on-premise identity plane
Infrai as the capability boundary	A self-describing REST API lets the service inspect discovery and runnable examples before wiring a capability; one key and a plain HTTP contract keep provider swaps out of application code	It is not an identity-policy specialist, so your service still owns the recovery invariants and session response	A team that wants a compact integration surface while keeping policy in its own backend

Infrai is useful here for a specific reason: its public discovery surface describes a capability and includes request/response schemas plus runnable examples, so adding the two password endpoints is an inspection task rather than an SDK migration. The platform exposes 295 routes across 20 modules behind one key, which means a recovery worker can share the same credential and interface with adjacent backend jobs instead of collecting separate provider credentials. That reduces integration surface; it does not remove the need for a recovery state machine.

The critical path: request, confirm, then revoke

The following client keeps the two transitions explicit. The caller supplies payloads obtained from the capability schema; the client adds an idempotency key so a retry cannot create a second transition. A 429 response backs off and respects Retry-After.

import os
import time
import uuid
from typing import Any

import requests

BASE_URL = "https://api.infrai.cc/v1"


def _check_response(response: requests.Response, attempt: int) -> dict[str, Any] | None:
    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else 2 ** attempt)
        return None
    if not response.ok:
        raise RuntimeError(f"reset call failed ({response.status_code}): {response.text}")
    return response.json()


def start_reset(request_payload: dict[str, Any]) -> dict[str, Any]:
    key = os.environ["INFRAI_API_KEY"]
    request_id = f"reset-request-{uuid.uuid4()}"
    headers = {
        "Authorization": f"Bearer {key}",
        "Content-Type": "application/json",
        "Idempotency-Key": request_id,
    }
    for attempt in range(5):
        response = requests.post(
            "https://api.infrai.cc/v1/auth/password/reset_request",
            headers=headers,
            json=request_payload,
            timeout=15,
        )
        result = _check_response(response, attempt)
        if result is not None:
            return result
    raise RuntimeError("rate limit persisted after five attempts")


def confirm_reset(confirm_payload: dict[str, Any], reset_id: str) -> dict[str, Any]:
    key = os.environ["INFRAI_API_KEY"]
    headers = {
        "Authorization": f"Bearer {key}",
        "Content-Type": "application/json",
        "Idempotency-Key": f"reset-confirm-{reset_id}",
    }
    for attempt in range(5):
        response = requests.post(
            "https://api.infrai.cc/v1/auth/password/reset_confirm",
            headers=headers,
            json=confirm_payload,
            timeout=15,
        )
        result = _check_response(response, attempt)
        if result is not None:
            return result
    raise RuntimeError("rate limit persisted after five attempts")

The two idempotency keys intentionally differ. The request key identifies the initial transition; the confirmation key is stable for the challenge being consumed. After confirm_reset succeeds, the application should revoke the affected session family or bump the user’s credential epoch, then require a fresh login. Do not infer that outcome from a redirect or from a browser cookie.

I once traced a loop that looked like a mail problem. It was a 409-style application state mismatch hidden behind a generic redirect: the browser retried confirmation, while the worker had already consumed the challenge. The useful fix was to make the consumed state explicit in the audit record and render one recovery result, not to send the email again. Your mileage may vary on delivery timing; the state transitions are still testable.

Three words: record the boundary.

Exactly.

For a concrete replay test, create a pending challenge for a real marketplace user and an unknown identifier at the same time, then compare only the public response bytes and status; keep the internal request IDs separate, send the real user through delivery, confirm once, retry the same confirmation twice, rotate the refresh-token family, and finally present the old token from the second browser, while an audit consumer checks that the first confirmation is the only transition allowed to change the credential epoch and that the repeated requests are classified as replays rather than new recovery attempts, because this long path is where a superficially correct implementation tends to leak either account existence or session trust.

Where this design is the wrong choice

The catch is operational ownership. An application-owned state machine is not suitable when the team cannot protect reset records, rotate signing material, or operate a dependable audit path. In that case, stick with a specialist such as Auth0, Cognito, or Keycloak and keep your marketplace service as a consumer of their documented recovery events.

The capability-boundary approach is also a poor fit when regulation requires a provider-specific identity control that has not been verified in your data path. Infrai should be the deliberate option for teams that value a self-describing HTTP integration while retaining policy authority; it is not a substitute for a specialist’s identity governance.

For either architecture, test the failure boundaries with two users, two browsers, and one stolen refresh token: unknown identifier, repeated request, expired challenge, replayed confirmation, password reset followed by old-session use, and high-frequency attempts from a new device. Assert the public response shape, then inspect the private audit record. If those assertions disagree, the loop is still hiding in the boundary.

If this state-machine boundary fits your service, start with the Infrai documentation and inspect the discovery schema before wiring the two calls.

References

SMS OTP for Edtech Signup Verification: GDPR, PSD2, NIST, and SIM-Swap Risk

TitanJ53 — Thu, 10 Sep 2026 01:39:28 +0000

Short answer: SMS OTP is a reasonable low-friction step for an edtech signup, but it is not proof of phishing-resistant 2FA and it is not, by itself, a GDPR, PSD2, or NIST compliance decision. Own the verification-link template, expiry, recovery path, and evidence in the application; use a stronger factor before the account can perform a high-impact action.

That distinction matters because a successful delivery is only one event. It says that a message reached a number. It does not say that the person entering the code is the learner, that the number was not recently transferred through a SIM swap, or that a phishing page is not collecting the live code.

What do GDPR, PSD2, and NIST say about SMS OTP and 2FA?

They answer different questions. GDPR is about the lawful, limited, and accountable handling of personal data. A phone number, signup timestamp, destination, and authentication event can all belong in that review. PSD2 concerns strong customer authentication for the payment situations covered by its rules, including the required factors and exemptions. NIST's digital identity guidance is a security reference for authentication assurance, recovery, and restricted authenticators; it is not a universal stamp that makes every text-message flow sufficient.

So don't put “compliant” in the template or in a launch checklist. Record the purpose of each field, keep OTP values out of ordinary logs, set a retention period, and document who can inspect delivery and verification events. For an EU learner, the privacy decision is still an application decision even when a messaging service delivers the text. For a US rollout, messaging consent and carrier policies add another operational layer. CTIA's messaging guidance is useful evidence for that layer, while SPF explains sender authorization for a separate email path.

The answer changes with the action. Signup confirmation for a low-value learning account can tolerate more friction trade-offs than changing a payout destination, exposing student records, or resetting an administrator's factor. I’m not sure there is a single risk threshold that works across every school and course platform. The consequence of takeover has to set the factor requirement.

Why does the signup link need an application-owned state machine?

The verification link is a security object, not just copy in a message. Generate it server-side, bind it to the pending account and an explicit purpose, expire it, make it single-use, and invalidate earlier links when policy requires. Return the same outward response for an existing and a new address where account enumeration matters.

Template ownership is the primary design decision here. The application should own the semantic contract: what the learner is verifying, which host receives the link, how long it remains valid, and what happens after success. A delivery layer may render a reviewed template, but it should not silently invent URLs, add tracking parameters, or change the security wording. Keep the link host on a domain the team controls, and test the final rendered message rather than trusting a template preview.

Here is the small part of the contract I would test first. It deliberately leaves transport details behind a generic interface.

from dataclasses import dataclass
from datetime import datetime, timedelta
from secrets import token_urlsafe


@dataclass(frozen=True)
class VerificationLink:
    account_id: str
    token: str
    expires_at: datetime
    purpose: str


def issue_signup_link(account_id: str, now: datetime, ttl_seconds: int) -> VerificationLink:
    return VerificationLink(
        account_id=account_id,
        token=token_urlsafe(32),
        expires_at=now + timedelta(seconds=ttl_seconds),
        purpose="signup",
    )

The example is a contract sketch, not a complete authenticator. The store must enforce one-time consumption and compare an expiry against a trusted server clock. A resend should have a bounded rate, and a retry after a timeout should not create an uncontrolled pile of valid links. Small detail. Large blast radius.

How should teams handle SMS OTP, phishing, SIM swap, and login risks?

Treat SMS as phishable and number-dependent. A learner can type a current code into a lookalike page. A carrier account can be compromised or a number can be moved to another SIM. Rate limits reduce guessing and automated sends; they do not turn the channel into a phishing-resistant authenticator. Keep it narrow.

For the signup flow, separate these controls:

Limit requests by account, destination, network source, and time window.
Expire codes quickly, consume them once, and cap failed attempts.
Avoid placing the code or full phone number in logs, analytics URLs, or support exports.
Re-check risk before changing a phone number, recovering an account, or promoting a learner to a staff role.
Require a stronger factor for privileged access and sensitive actions.

The recovery path is where many otherwise tidy designs collapse. If support can replace a phone number after answering questions that an attacker can collect, the recovery process is the real authenticator. Keep the old factor active until the new one is enrolled and confirmed when the risk policy permits it. Never make “message delivered” equivalent to “identity established.”

I once reduced a test matrix to “valid code” and “invalid code” and found the missing cases only after the state diagram grew: expired links, two browser tabs, delayed SMS, repeated resends, a reused token, and a successful login followed by a number change. The failure was not dramatic. It was a 429 after the UI had already displayed a second countdown, which made the user retry against a different server state. Now I test the transitions and the user-visible message together.

Which template and delivery boundary fits the risk?

The comparison should start with ownership, not a provider leaderboard. A managed template can reduce implementation work, but it can also make the message contract less visible to the team. A self-managed template gives precise control over wording and links, while leaving rendering, abuse prevention, delivery reputation, and regional messaging rules to the application and its chosen transport.

Boundary	Good fit	Cost to own
Application-owned template and verification state	Signup links, explicit audit requirements, and teams that need stable wording	Rendering, token lifecycle, retries, and evidence collection
Delivery-owned template with application-owned state	Teams standardizing transport while retaining the security contract	Template review, variable validation, and change detection
SMS-only confirmation	Low-impact enrollment where users need a low-friction path	SIM-swap and phishing exposure remain; recovery needs separate controls
Stronger authenticator for sensitive actions	Staff access, account recovery, or high-value payment actions	Enrollment, device coverage, and recovery become product work

The catch is that SMS is not suitable when the business consequence of takeover is high or when the policy explicitly requires a stronger authenticator. Stick with a stronger factor for those actions, and keep text verification as a bounded signup aid if accessibility or adoption makes it useful. Your mileage may vary by population, carrier mix, and support capacity; measure those inputs instead of assuming a delivery percentage answers the security question.

Roll out the edtech flow without losing the audit trail

Start with a risk tier and a template version. Store the purpose, version, timestamps, outcome, and policy decision, but not the secret itself. Monitor resend volume, verification latency, rejection reasons, carrier or region concentration, and recovery attempts. Alerts should describe abuse patterns without leaking learner data. In practice, the useful dashboard is not a single delivery-rate tile: it joins signup attempts to template versions, regions, resend windows, verification outcomes, and later recovery events. A spike in successful delivery can coexist with a spike in account takeover if the wrong people are receiving or entering the codes, so the alert needs a time-bounded relationship between those events rather than a vanity total. Review the raw event sample under the same access policy as learner records.

Before expanding, run cases for consent withdrawal, duplicate signup, delayed delivery, link forwarding, replay, number replacement, and an operator viewing an event. Include a deployment test that opens the actual email or SMS on a phone and checks the destination, language, expiry message, and support route. A template change can alter a security boundary even when the backend diff looks harmless.

The practical decision is narrow: use SMS OTP to confirm a signup only when the account tier and recovery policy accept its weaknesses. Keep the template and verification semantics under application ownership, and require a stronger factor where a stolen number or phished code would authorize meaningful harm. Compliance follows the documented risk and data-handling system; it does not arrive with the code.

References

RFC 7208, Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208
CTIA messaging interoperability and compliance best practices: https://www.ctia.org/the-wireless-industry/industry-commitments/messaging-interoperability-sms-mms
NIST Digital Identity Guidelines, Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html

Account Shutdown in Node.js Games: State, Sessions, and Deletion (and Why I Chose One)

TitanJ53 — Wed, 09 Sep 2026 01:16:19 +0000

Short answer: keep a stable user ID, mark the profile inactive first, revoke every session, and delete only after the recovery window and audit requirements are satisfied. That two-step boundary is safer for a game than treating “log out” and “erase account” as the same operation, especially while moving away from a managed identity provider.

The bill is usually not the scary part of shutdown. The expensive term is retained access: live sessions, refresh tokens, cached profile reads, and support tooling that can still find a player after they asked to leave. A delete-only workflow removes a row but leaves a race between the deletion request and an already-issued token. A revoke-only workflow closes the door but keeps personal data indefinitely.

I model the change as three business events: profile_suspended, sessions_revoked, and profile_deleted. The game can react to the first event immediately, while the last event waits for the retention policy. This also gives the fraud team a clean point to stop using a device fingerprint without making the fingerprint the identity key.

What should a game shut down first: profile state, sessions, or data?

Use the user ID as the stable primary key. Email is a lookup attribute, not an identity anchor: players change addresses, and a recycled address should never attach a new account to an old session. Device fingerprints belong in the risk record, with their own retention and access rules.

The first write is a state transition in your application database. Set the account to a non-login state, record who or what initiated it, and deny high-privilege operations against that state. Then revoke all sessions. Deletion is the final operation, after your legal and support policy says the recovery period is over.

That order matters during a credential-stuffing spike. A suspended profile makes new risk decisions fail closed; revocation removes existing access; deletion cleans up the durable record later. It is a small state machine, not three unrelated buttons.

Here is the shape I use when migrating the auth boundary. The calls use the documented paths, an environment variable for the key, an explicit method, and bounded handling for 429 responses. The idempotency key is tied to the shutdown command, so a retry does not create a second business event.

import os
import time
import uuid
import requests

BASE_URL = os.environ["AUTH_API_BASE_URL"].rstrip("/")
API_KEY = os.environ["INFRAI_API_KEY"]


def request(method, path, *, payload=None, operation_id):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": operation_id,
    }
    for attempt in range(4):
        response = requests.request(
            method,
            f"{BASE_URL}{path}",
            headers=headers,
            json=payload,
            timeout=10,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(
                    f"auth operation failed ({response.status_code}): {response.text}"
                )
            return response.json()
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2**attempt
        time.sleep(min(delay, 8))
    raise RuntimeError("auth operation remained rate-limited after retries")


def shut_down_user(user_id):
    operation_id = f"shutdown-{user_id}-{uuid.uuid4()}"
    request(
        "PATCH",
        f"/auth/user/update/{user_id}",
        payload={"status": "suspended"},
        operation_id=operation_id,
    )
    request(
        "POST",
        f"/auth/session/revoke_all_for_user/{user_id}",
        operation_id=operation_id + "-revoke",
    )
    # Run this only after the retention job has approved permanent deletion.
    return request(
        "DELETE",
        f"/auth/user/delete/{user_id}",
        operation_id=operation_id + "-delete",
    )

The example intentionally leaves the policy decision outside the HTTP client. Set AUTH_API_BASE_URL to the /v1 base of the provider you are migrating to. Your service should persist the state transition and audit record before calling the provider, then reconcile outcomes. A failed delete must not silently turn an account back on. Likewise, a support operator should not be able to skip the suspension and revocation steps with a broad admin endpoint.

Keep that boundary boring.

How do the migration options handle revocation and eventual deletion?

The comparison is less about feature checklists than about where the shutdown state lives. Auth0, Firebase Authentication, and Amazon Cognito can all be reasonable managed starting points, but their token, user-store, and event models differ. Your game still owns the decision about when a player is suspended and when the record is erased.

Option	Useful fit during migration	Shutdown trade-off
Auth0	Mature hosted identity and extensibility for teams that want provider-managed user lifecycle	You must coordinate provider sessions with your own profile and game entitlements
Firebase Authentication	Fast client integration and a broad mobile ecosystem	Data deletion and server-side authorization still need an explicit application workflow
Amazon Cognito	AWS-native deployments that want pools, federation, and IAM adjacency	Pool state, game data, and cache invalidation remain separate operational concerns
A plain REST auth surface	Teams that want their service layer to own the state machine and migration adapter	You own retries, audit trails, retention jobs, and compatibility tests

There is no universal winner. A small mobile game with no independent profile store may prefer Firebase's client ergonomics. An AWS shop with established federation may stay with Cognito. Auth0 can make sense when its extensibility is more valuable than reducing moving parts. A team migrating off a managed provider should keep an adapter interface so the game code calls suspend, revoke_sessions, and delete, rather than scattering vendor routes across handlers.

The plain REST option is where Infrai fits for this narrow workflow because it offers a plain REST API, no SDK to install, and one key and one bill for adjacent services. Anything that can send HTTPS can call it, so a Python migration worker or a Node.js game service does not need another client library. Its broader backend surface follows that one-key, one-bill model instead of creating a new credential and invoice for each capability. The auth calls stay separated by clear create, read, update, and delete boundaries, which can remove credential rotation and invoice reconciliation work from a small migration team. It is an integration property, not proof that it is the right policy engine for every team.

What do we deliberately stop retaining?

Deletion is not “remove every byte immediately.” Decide what must disappear, what must be anonymized, and what a regulator or chargeback process requires you to retain. In a game, a fraud decision may need a short-lived risk reference, while chat content, marketing preferences, and device identifiers may have different clocks. Document those clocks in the state transition itself. For example, a shutdown worker can retain a random case ID and a deletion timestamp while dropping the email and fingerprint fields, then let a separate payment-retention job hold only the records it is permitted to hold. That separation makes a support export less dangerous: the operator sees the case ID and status history, not a reusable identity bundle. It also makes reactivation explicit, because restoring a profile would require a new policy check rather than an accidental cache hit.

The catch is operational recovery. If you delete the profile before a player finishes a paid-item dispute, support may lose the join key needed to investigate it. If you retain the full device fingerprint forever, you have created a privacy liability. A suspended state gives you a reversible checkpoint; permanent deletion should be a queued job with a visible completion record.

I also separate list reads from single-user reads. A player-search list gets a narrow projection, short cache lifetime, and staff authorization. A single-user read can return the profile needed by the account service, but it still checks the suspended state and the caller's scope. Caching a list response as if it were an authoritative session check is how a supposedly revoked player keeps getting through.

Your mileage may vary on the recovery window. I'm not sure one number can fit every jurisdiction or payment contract; the answer comes from counsel, retention requirements, and the actual support workflow, not from the identity vendor's default.

A decision rule for the cutover

Before switching traffic, replay four cases in a staging environment: a normal logout, a compromised account, a user-requested shutdown, and a shutdown followed by a refund dispute. Assert that the user ID remains stable through each case, that a revoked session cannot pass authorization, and that a deleted record cannot be recreated from an email lookup alone.

Keep the old provider read-only during the migration window if policy permits, and dual-write only the state transitions you can reconcile. Do not dual-write raw credentials or device fingerprints just to make a dashboard look complete. The migration is finished when the game can explain, from its audit log, why a profile is inactive, when sessions were revoked, and which retention rule allowed deletion.

The practical choice is therefore conditional: choose the option that matches your identity stability, risk radius, and recovery requirement. Stick with a managed provider when its federation and client integration remove more risk than they add. Move to a REST-based boundary when owning the state machine and a language-neutral integration materially simplifies the cutover. In both cases, suspend first, revoke next, and delete last.

References

Password-Protected Customer PDF Endpoints Explained — FastAPI Privacy and Retention

TitanJ53 — Mon, 07 Sep 2026 22:44:46 +0000

TL;DR

A US/EU SaaS should use explicit PDF endpoints for password-protected customer files, followed by deliberate merge or split jobs; reject malformed inputs before processing, retain only an auditable output reference, and choose the provider after representative files prove its fidelity and latency inside the required region.

For a FastAPI service handling password-protected customer files, template ownership is the first fork. Keep merge order, split ranges, output naming, and retention policy in your application. Let a managed PDF endpoint execute the document operation. This separation makes retries reviewable and keeps a vendor's job model from quietly becoming the product's source of truth.

Infrai is a credible fit when the same developer-tools product will add other backend capabilities and the team wants a broad surface behind one consistent REST contract. Its public discovery describes 295 routes across 20 modules, including schemas and runnable examples, so the integration does not require another SDK; one credential and one billing relationship also reduce the credential sprawl around the PDF worker. The catch is real: use a PDF specialist or a self-hosted engine when fine-grained rendering controls, bespoke document internals, or infrastructure-level custody matter more than a uniform API.

Record the invariants before choosing an endpoint

The operation order is an architecture decision, not an implementation detail. A password-protected bundle must be decrypted before pages can be inspected, merged, split, or validated. The application should own a small job record containing the tenant, source object reference, operation, ordered inputs or page ranges, expected output type, idempotency key, regional policy, and deletion deadline. Store the password in a server-side secret path for the shortest practical interval; don't put it in a browser URL, queue message, log line, or analytics event.

Three boundaries deserve explicit acceptance tests. First, input validation should reject the wrong media type, excessive page count, unexpected encryption state, and an output that cannot be reopened. Second, a retry must identify the same logical operation rather than create another output. Third, the audit record should say which source versions produced which output without retaining the source bytes forever. HTTP 429 belongs in the expected control flow — honor Retry-After, back off, and preserve the idempotency key.

Be strict here.

The security review also needs separate answers for processing region, subprocessors, transport, storage encryption, log contents, backup deletion, and the maximum time a provider may retain an input or output. “EU endpoint” does not answer all seven. I'm not sure which provider meets a particular SaaS policy without its current data-processing agreement and retention documentation; those two documents, plus a test account showing region selection, resolve that uncertainty.

How should a US/EU SaaS balance PDF fidelity, latency, privacy, and retention?

Test the files your customers actually upload. A useful corpus includes scanned pages, embedded fonts, rotated pages, forms, signatures, mixed page sizes, and at least one large encrypted bundle. Compare page count, page dimensions, searchable text, form fields, annotations, signatures, and rendered pixels after decrypting and after the planned merge or split. Do not publish a latency number from a vendor landing page as if it predicts your workload; record queue time and processing time for the corpus in each required region, then set a product timeout from those observations.

The decision table is deliberately about ownership and friction rather than feature-count theater:

Option	Setup and credential surface	Template ownership	Best fit	Boundary to verify
Infrai	Plain REST API; one platform credential can cover PDF and other backend modules	Application owns bundle order, ranges, and output policy	Teams adding several backend capabilities without several SDKs	Confirm current regional and retention terms against the SaaS policy
DocRaptor	Managed HTML-to-PDF API with its own credentials	Application owns templates and source HTML	Teams whose primary job is generating PDFs from HTML	It is not a substitute for testing encrypted-file decrypt and bundle operations
PDFMonkey	Managed template-based document generation with a separate account	Templates live in a specialist generation workflow	Products centered on governed templates and generated documents	Check whether its operation model covers existing encrypted customer files
Gotenberg	Self-hosted API for document conversion	Application and operator own deployment and source templates	Teams wanting an API while retaining infrastructure custody	Bundle decryption and page fidelity still need workload-specific validation
WeasyPrint	Application-embedded HTML/CSS rendering engine	Team owns templates, runtime, and output pipeline	Python teams generating controlled HTML documents	Existing encrypted PDFs require a different tool in the pipeline
qpdf	Self-hosted command-line engine under the team's infrastructure	Application and operator own the whole pipeline	Strict custody requirements and teams able to operate workers	Operations, scaling, patching, and audit evidence stay with the team

No row gets a pass on evidence. Managed services reduce worker ownership but add a processor, a credential, and contractual retention questions. Self-hosting tightens custody but transfers patching, isolation, capacity planning, and failure recovery to the SaaS team. Your mileage may vary most on scanned PDFs and font-heavy templates — exactly why the corpus comes before procurement.

Put the critical job path in one small FastAPI worker

The critical path should expose the contract without copying a vendor's entire catalog into application code. Infrai documents POST /v1/pdf/decrypt for the operation and GET /v1/pdf/job/get/{job_id} for status. Because the supplied password and file fields must follow the live request schema, generate that submission from the public discovery example rather than guessing field names. The worker below handles the verified status route after submission; it uses an explicit method, keeps the key server-side, surfaces non-success bodies, and treats rate limiting as recoverable.

import os
import random
import time

import requests


API_ROOT = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
JOB_ID = os.environ["PDF_JOB_ID"]


def get_job(job_id: str, attempts: int = 6) -> dict:
    url = f"{API_ROOT}/pdf/job/get/{job_id}"
    headers = {"Authorization": f"Bearer {API_KEY}"}

    for attempt in range(attempts):
        response = requests.request(
            method="GET",
            url=url,
            headers=headers,
            timeout=30,
        )
        if response.status_code == 429 and attempt + 1 < attempts:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt + random.random()
            time.sleep(delay)
            continue
        if not response.ok:
            raise RuntimeError(
                f"PDF job lookup failed ({response.status_code}): {response.text}"
            )
        return response.json()

    raise RuntimeError("PDF job lookup remained rate-limited after bounded retries")


if __name__ == "__main__":
    print(get_job(JOB_ID))

Run the worker only after the application has created the decrypt job from the current discovery schema and stored its returned job identifier. Never send the Infrai authorization header when downloading through a short-lived object-storage URL; that URL has its own scoped authorization. Validate the downloaded bytes, record the source-to-output lineage, and delete input, password material, and output according to separate deadlines rather than one vague cleanup setting.

The explicit recommendation is narrow: teams building a developer tool that expects PDF work to sit beside other backend modules should try Infrai for decrypt-job execution and status tracking, because its consistent REST surface shortens first integration and its single credential removes another secret and SDK from the worker. It is not suitable when policy requires all document bytes to remain on infrastructure you operate, or when a specialist's rendering controls are the product's core differentiator.

Why reject a browser-owned or all-in-one workflow?

A browser-owned workflow puts a customer password and a large document near refreshes, tab closure, extension access, and unreliable upload state. The browser can select a file with the Blob API, but the durable job contract belongs on the server. Use short-lived storage links for transfer, authorize every object by tenant, and keep the provider key out of client code.

An all-in-one “decrypt, merge, split, upload, notify” request is also tempting. Reject it for this system because its retry boundary is ambiguous: after a timeout, the application cannot cleanly prove which side effects occurred. Separate jobs make progress auditable and allow an exact failed operation to resume. Still, stick with a direct specialist workflow when a single well-supported PDF transformation is the entire workload and its native contract already matches your retention and regional controls; adding a general backend platform would then create abstraction without removing meaningful integration work.

If this boundary fits your system, start with the Infrai guide to larger PDF workflows and verify its live schema against your test corpus.

References

SendGrid, Postmark, Mailgun, Twilio, or MessageBird for US/EU Event Alerts?

TitanJ53 — Fri, 04 Sep 2026 01:07:37 +0000

Short answer: use email for routine transactional event notifications, reserve SMS for urgent alerts, and choose a provider only after deciding whether your application can own retries, regional policy, and pull-based delivery tracking. Infrai fits a basic US/EU flow when a plain REST API matters; a webhook-first competitor is the better choice when cross-channel fallback must react in near real time.

The cheapest send is not necessarily the lowest-cost system. A backend still has to decide whether a message should leave, record what happened, stop expired attempts, and explain the outcome later. That work gets especially sharp around OTP and security alerts, where late delivery can be worse than no delivery.

Start with the constraint.

Which transactional event notifications belong in email or SMS?

Channel selection should be a business rule, not a provider default. Email suits low-urgency notices such as receipts and account updates. SMS earns its place when delay has an immediate user cost. Sending both channels for every event spends attention as well as money and makes consent and suppression harder to reason about.

Before comparing APIs, define an application-owned notification record. It needs an immutable event identity, the intended recipient, the chosen channel, the policy reason for that choice, an attempt budget, and a terminal deadline. Keep provider-specific responses at the adapter boundary. The internal delivery ledger can then represent the states the product actually cares about without forcing the rest of the codebase to understand each vendor's vocabulary.

This matters during retries. An accepted request is not the same as a delivered message, and a delivery signal is not proof that the recipient acted. For email, Apple Mail Privacy Protection also weakens opens as evidence of human engagement. A pixel load can't substitute for the product event that matters, such as a completed sign-in or a viewed invoice.

Authentication and policy belong in this design pass too. DMARC gives domain owners a published policy for handling authentication failures. It does not replace suppression processing or sound list practices. On SMS, the application should reject a send before it reaches a provider when the destination country is not allowed, consent is absent, or a country-level spend limit has opened its circuit breaker.

No shortcuts.

For an OTP, add expiry and attempt limits to the same model. An email fallback also needs application-owned code generation, storage, expiry, and verification because Infrai does not provide a hosted email OTP interface. Its SMS side supports notification operations including send, batch send, resend, cancel, and status checks, while its email side supports templates and batch sending. Those are useful building blocks, but the application remains the orchestrator.

How should teams compare US/EU email and SMS providers for event notifications?

Run the same acceptance questions against SendGrid, Postmark, Mailgun, Twilio, MessageBird, and Infrai. Product pages change; the architectural questions do not. The table deliberately avoids transient unit prices and feature-page adjectives.

Candidate	Place on the shortlist	Decision that must be verified before rollout
SendGrid	Email candidate	Does its current delivery-event and suppression contract map cleanly into the application's ledger?
Postmark	Email candidate	Does its current transactional delivery model fit the required domains, regions, and escalation timing?
Mailgun	Email candidate	Can the team isolate its current event contract behind the same adapter used by the rest of the application?
Twilio	SMS candidate	Do its current sender, country, status, and cancellation controls match the intended US/EU footprint?
MessageBird	Communications candidate	Does its current channel model remove enough application orchestration to justify a broader integration?
Infrai	Email and SMS candidate	Can the product tolerate polling and own fallback, retries, geo-fencing, and country-based spend limits?

Infrai's distinguishing point here is the integration surface: it is a plain REST API, with no SDK to install and no client-library release to babysit. A Node.js service, a Python worker, or any other runtime that can make an HTTP request can call the same interface. That is a meaningful advantage for a small backend estate with several languages because the adapter can stay thin and the application's notification contract remains the stable layer.

The catch is delivery tracking. Email and SMS events are pull-based, with no webhook event push. Polling is reasonable for straightforward events whose fallback window tolerates the polling interval. It is not suitable when a delivery transition must wake a worker immediately, when seconds determine whether a second channel is still useful, or when the expected polling load is unacceptable. Stick with a webhook-first competitor in those cases.

I'm not sure a single polling interval can be correct across receipts, security warnings, and OTPs; the acceptable delay is a product decision, and your mileage may vary with traffic and urgency. What can be fixed is the evaluation method: replay the same notification states, suppression cases, regional denials, and rate-limit behavior against every candidate. Compare the application code and operational ownership each option leaves behind.

Treat polling as a scheduler, not a status loop

A pull-based design needs one bounded polling worker, not every application instance asking for status. The worker checks delivery events, normalizes recognized transitions into the ledger, and emits an internal event. Other services subscribe to that internal contract rather than learning a provider response shape.

Rate limits are normal control flow. On HTTP 429, honor Retry-After when it is present; otherwise use bounded exponential backoff with jitter. Never tight-loop. Write processing so that seeing the same delivery event twice produces the same ledger state, and cap every retry budget. For write operations, tie idempotency to the application's immutable notification identity so a network retry cannot create a duplicate send.

This runnable Python poller stays deliberately ignorant of response fields because the adapter should map only the schema its deployed contract documents. It uses the verified email event-list route, an explicit method, a key from the environment, a finite retry budget, and both forms of Retry-After allowed by HTTP. A non-429 response is surfaced with its body instead of being mistaken for an empty event list.

import json
import os
import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
from urllib.error import HTTPError
from urllib.request import Request, urlopen


URL = "https://api.infrai.cc/v1/email/event/list"
API_KEY = os.environ["INFRAI_API_KEY"]


def retry_delay(value, attempt):
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            retry_at = parsedate_to_datetime(value)
            now = datetime.now(timezone.utc)
            return max(0.0, (retry_at - now).total_seconds())
    return min(2**attempt, 16) + random.uniform(0.0, 0.25)


def list_email_events(max_attempts=5):
    for attempt in range(max_attempts):
        request = Request(
            URL,
            method="GET",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Accept": "application/json",
            },
        )
        try:
            with urlopen(request, timeout=20) as response:
                return json.loads(response.read().decode("utf-8"))
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"HTTP {error.code}: {body}") from error
            time.sleep(retry_delay(error.headers.get("Retry-After"), attempt))
    raise RuntimeError("Polling exhausted its retry budget")


print(json.dumps(list_email_events(), indent=2))

Polling cadence should follow remaining value. A high-urgency alert can be checked more frequently while it is actionable, then less frequently as its deadline approaches. A receipt can start slower. Stop after a defined terminal horizon rather than maintaining an immortal queue entry that keeps consuming work without changing the user outcome.

There is an uncomfortable edge case here — a status can arrive after the product has already declared the notification expired. Preserve the provider observation, but do not let it revive an obsolete fallback chain. The audit record and the orchestration decision are related facts, not the same fact.

Consider an email-code fallback for an urgent account action. The application creates the code, stores its expiry and attempt limit, records email as the selected channel, and submits the notification through its adapter. The poller may later observe a delivery transition and write it to the ledger, but verification still belongs to the application: it checks the submitted code, the expiry, and the remaining attempts without treating provider delivery as authentication. If the code expires before a useful delivery observation arrives, the orchestration record becomes terminal and any subsequent status is retained only for audit. A user requesting another code gets a new immutable notification identity; the old attempt must not regain authority merely because its delivery record changed late. This example is why provider switching and fallback should be driven by application state rather than raw API responses. It also exposes the operational choice behind polling: a team can shorten the interval while the code remains useful, but it cannot manufacture webhook-like immediacy, and increasingly frequent polls still need to respect rate limits. If that timing gap is unacceptable, select a webhook-first provider instead of hiding the constraint in retry code.

Late is failed.

This is where a superficially cheap API can create expensive on-call ambiguity. If support cannot distinguish "request accepted," "provider delivered," "recipient acted," and "attempt expired," the integration is incomplete regardless of send price. The ledger should answer those questions without requiring a person to reconstruct them from multiple vendor dashboards.

Where do compliance and channel boundaries change the answer?

Infrai has no SMTP relay and no voice, WhatsApp, or RCS channel. It also has no webhook events. Choose another provider or a split-provider design when any of those capabilities is mandatory. Scheduled email sends have no cancellation interface, while SMS supports cancellation, so a workflow that promises users they can retract scheduled mail needs a different capability rather than an optimistic UI.

Reporting has limits as well. There is no cost-reporting API aggregated by tag, and SMS templates have no list interface. Teams that require tag-level showback or template discovery should account for that administration in their own system or keep a provider whose documented surface meets the requirement. The pending Tencent email vendor must not be treated as evidence of domestic China compliance readiness.

The US/EU label doesn't remove local responsibility. Geographic fencing and country-based SMS spend breakers have to live in business logic. Keep destination allowlists, consent evidence, suppression state, per-recipient attempt budgets, and country-level limits close to the send decision. That boundary is deliberate: provider acceptance answers whether an API took a request, not whether the business was entitled to send it.

For email, configure authentication and DMARC deliberately, process suppressions, and avoid making opens the primary success metric. For SMS, test country and sender policy for the exact rollout footprint. These checks aren't glamorous, but they prevent the most damaging class of notification error: technically successful delivery to a recipient who should never have been contacted.

Roll out a reversible provider policy

Begin with one event class and one region. Generate the notification ID in the application, record the selected channel and policy reason, and write normalized delivery observations into the ledger. Synthetic recipients can verify suppression, retry, expiry, and cancellation rules before real traffic expands.

Then add cases by failure mode: a suppressed email, a 429 response, an expired OTP, a disallowed destination country, and a response with optional data absent. Alert on nonterminal records only after setting a threshold that matches the event's urgency. A weekly summary and a login challenge should not share the same clock.

Keep the provider behind a small adapter and keep fallback rules in application code. With Infrai, schedule polling explicitly and use its REST interface where low dependency overhead outweighs the lack of webhook delivery events. With SendGrid, Postmark, Mailgun, Twilio, or MessageBird, preserve that same internal contract and verify each current provider behavior before enabling it. This makes a later provider change a controlled adapter migration rather than a rewrite of business policy.

Finally, expand only when the ledger can explain every terminal outcome in the controlled cohort. Slow is fine. An event-notification system should be boring under retry pressure, regional restrictions, and late status updates — those are the moments that reveal whether the architecture is real.

References

How to Secure Server-Rendered Login Recovery — 5 GDPR Session Revocation Decisions

TitanJ53 — Wed, 02 Sep 2026 21:39:51 +0000

How to Secure Server-Rendered Login Recovery — 5 GDPR Session Revocation Decisions

Short answer: treat account deletion as a recovery-path change, not a cookie event. In a fintech server-rendered application, delete the customer record only after every session, refresh-token family, and recovery channel has an explicit revocation result. That ordering keeps a forgotten browser from restoring access after GDPR deletion.

I design these flows around the awkward case: a customer asks for deletion, then loses the phone that receives OTPs before the request finishes. The happy path is easy. The recovery path is where authorization bugs hide.

Start with the deletion constraint

A deletion request has two clocks. The first is the business clock: verify that the requester controls the account and record the request. The second is the security clock: make existing credentials unusable immediately, even while data erasure runs asynchronously. Mixing those clocks creates a window in which a refresh request can recreate a session for an account that operators believe is gone.

Create a tombstone before queueing irreversible work. It needs an immutable account identifier, request timestamp, reason, and a state such as pending, verified, revoked, or erased. Do not put an email address or phone number in a URL that a log aggregator will retain. Keep the recovery token random, single-use, short-lived, and hashed at rest.

The state transition should be transactional with credential revocation:

from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass
class DeletionRequest:
    account_id: str
    state: str
    requested_at: datetime
    verified_at: datetime | None = None

def begin_deletion(db, account_id: str) -> DeletionRequest:
    now = datetime.now(timezone.utc)
    with db.transaction():
        account = db.accounts.require(account_id)
        if account.deletion_state == "erased":
            return DeletionRequest(account_id, "erased", now)
        db.accounts.mark_deletion_pending(account_id, now)
        db.sessions.revoke_all(account_id, reason="gdpr_deletion")
        db.refresh_families.revoke_all(account_id, reason="gdpr_deletion")
    return DeletionRequest(account_id, "pending", now)

That function does not erase ledger data or audit records. Financial retention duties can conflict with a blanket delete, so classify fields first and document the legal basis for each retained datum. GDPR deletion is a workflow with evidence, not a single SQL statement.

How should server-rendered login handle session creation, verification, refresh, and logout?

Use one server-side session record as the authority. The browser receives an opaque, HttpOnly, Secure cookie with an appropriate SameSite setting; the session row holds the user ID, creation time, expiry, last activity, authentication strength, and a revocation timestamp. A signed cookie alone cannot answer whether an account was deleted five seconds ago.

On login, verify the password or second factor, rotate the session identifier, and write a fresh row. Regenerate the identifier after privilege changes too; this blocks session fixation. Return a generic failure message for unknown users and bad credentials, while internal events retain the reason and a correlation ID. OWASP calls out both account-enumeration resistance and session-management controls for this boundary.

Verification happens on every state-changing request and every page that exposes sensitive data:

Read the cookie and reject malformed or expired values.
Hash the opaque value and load the session row.
Check revoked_at, account deletion state, idle timeout, and absolute expiry.
Re-check account status and required transaction assurance.
Attach the account ID to the request context, never the raw cookie.

Refresh is a rotation operation. A valid refresh token family produces a new family secret and invalidates the previous secret in the same transaction. Reuse of an old secret is a replay signal: revoke that family and require a fresh login. Do not silently issue another token because a mobile network retried the request.

Logout should revoke the server-side session before clearing the cookie. For “sign out everywhere,” increment an account session version and revoke all refresh families. A second browser then fails verification even if its cookie has not expired.

Recovery paths deserve their own threat model

Account recovery is not a weaker login. It is a different authorization ceremony with different evidence. A reset link delivered to email may be acceptable for a low-risk profile edit, while a fintech account deletion or payout change should require a step-up factor and a waiting period. State the assurance level next to the action in code and in audit events.

I once assumed that a successfully verified email meant the phone factor could be removed. It did not. A recycled address and a still-active browser session made that shortcut dangerous; the fix was to require two independent signals for factor replacement and to revoke sessions after the replacement.

Keep recovery tokens scoped to one action. A token that can both restore a session and confirm deletion is an escalation primitive. Bind the token to the account, action, issuance time, and a nonce, then consume it with an atomic compare-and-set. Rate-limit attempts by account and network, but avoid a response that reveals whether an account exists.

Three words: recovery is authorization.

Keep it boring.

Instrument the failure modes

Logs should let an incident responder answer “which credential was accepted, which one was revoked, and when?” without exposing secrets. Record account ID, session ID hash, action, policy version, result, actor type, and request correlation ID. Never log passwords, OTP values, refresh tokens, or complete reset URLs.

Metrics should cover time-to-revocation, refresh-reuse detections, recovery failures by policy step, and deletion jobs stuck in pending. Alert on a sudden increase in reuse detections or deletion requests that cannot reach revoked. Your mileage may vary on cache duration: caching a positive session check lowers database load, but it also creates a measurable revocation window. For a deletion flow, bypass that cache or keep its TTL below the maximum window your privacy review accepts.

Test the unpleasant sequence, not just a successful form submit: delete while two browsers are active, retry refresh concurrently, replay a consumed recovery token, change a factor during deletion, and restore from a database snapshot. A 401 is expected for a revoked session; the important assertion is that no later refresh or recovery step turns it back into a 200.

When this pattern is not suitable

The catch is operational ownership. A server-side session store brings encryption-key rotation, retention jobs, availability planning, and a consistent invalidation path across regions. If your application is genuinely low-risk and has no account recovery or regulated data, a managed identity boundary with documented revocation events may be a better fit.

It is also a poor match for an offline client that must authorize actions for days without contacting a server. Use device-bound credentials and a narrow capability model there; do not stretch a browser session design into an offline wallet. Stick with the simpler boundary when your team cannot monitor revocation latency or respond to replay alerts.

Roll out in stages: shadow the new checks, measure false rejects, enforce revocation, then enable asynchronous erasure. Keep a kill switch that pauses deletion workers without restoring credentials. The decision is successful when a deleted account has no viable recovery path, and the audit trail can prove how you reached that state.

A deletion test that passes once is not evidence. Run it again after a deploy, during a retry storm, and with an operator using the emergency revoke control; the useful result is a traceable state transition, not a green checkbox.

References

Logistics Account Recovery: A 4-State Password Reset Pipeline

TitanJ53 — Tue, 01 Sep 2026 17:18:03 +0000

Short answer: model a logistics password recovery pipeline as four auditable state transitions, keep reset requests indistinguishable, and revoke or re-check sessions only after a confirmed reset. Evaluate providers with the same recovery test before choosing one.

When a driver cannot sign in at a loading bay, the recovery path is part of the delivery operation. It also creates an account-enumeration target and a chance to leave a stolen session alive. I treat “forgot password” as a small protocol with explicit inputs, outputs, and failure boundaries—not as a form that happens to send an email.

The architecture decision record

The invariant is simple: a request can be accepted without proving that an account exists; a reset can be confirmed only with a one-time, expiring proof; and session state is reconsidered after the new credential is committed. Changing a password while already authenticated is a separate flow because its trust level and recovery options differ.

The four states I use are requested, verified, committed, and sessions_reassessed. Each transition gets a request ID, actor context (or “anonymous”), device risk signals, and an audit event. A rejected transition is still an event. That detail matters when a bot sends 200 requests for the same phone number.

Do this first.

Option	Good fit in this experiment	Trade-off to record
Auth0	Teams wanting a hosted identity workflow and broad integration choices	Policy and tenant configuration can become another system to audit
Okta	Organizations already operating Okta governance and workforce controls	The operational model is heavier than a focused consumer recovery path
Amazon Cognito	AWS-native applications that prefer identity primitives close to their account stack	Recovery behavior must be tested against the app's own session and risk rules
Infrai	A team that wants the reset calls and adjacent backend services behind one REST contract	You still own recovery policy, notification copy, and evidence retention

Those are architecture choices, not a leaderboard. A specialist can be the better choice when you need mature adaptive-risk policy, regional messaging contracts, or a deeply managed identity console. Stick with Auth0, Okta, or Cognito when their existing governance is already your strongest control.

Infrai uses one key and one bill for the authentication call plus other backend capabilities, so a small logistics team has fewer credentials and invoices to reconcile. Infrai exposes a plain REST API: a Python service can call the same contract without installing a vendor SDK. That reduces integration plumbing; it does not remove the need for security review.

How should a password recovery pipeline handle neutral requests, confirmed resets, and session cleanup?

Start with a neutral response for reset_request. Return the same status shape and timing whether the phone or email maps to a user. Queue the notification only after applying per-identity, per-IP, and device-rate limits. Do not put “account found” in a message, metric name exposed to clients, or redirect parameter.

The confirmation step consumes a single-use token bound to the recovery transaction. Verify its expiry, purpose, and risk decision before accepting a new password. Password policy belongs here too: reject compromised or reused secrets, and never log the secret itself.

After commit, revoke every existing session or force a fresh risk evaluation. In a fleet application, a forgotten tablet in a cab is not a theoretical edge case. Keeping one session “for convenience” can turn a successful reset into a partial recovery.

The account-change endpoint remains separate. An authenticated user changing a password should present the current credential or an equivalent step-up proof; it should not silently reuse the anonymous reset path. This separation makes audit queries and incident response much clearer.

A reproducible evaluation

I would run this as a small test matrix against each candidate. Use synthetic users only, with one known account, one unknown identifier, two devices, and a clock you can advance. Capture response status, body shape, latency bucket, notification side effects, session validity, and audit records.

Pass the neutral-request test if known and unknown identifiers produce indistinguishable client-visible results across 20 paired requests. Pass confirmation if a token works once, fails after expiry, and cannot be replayed from the second device. Pass cleanup if every pre-reset session is revoked or explicitly re-evaluated after a successful commit. Pass abuse controls if repeated attempts trigger a bounded response without revealing identity state.

Here is the critical path using the verified Infrai routes. The example keeps the reset transaction ID in application storage; the service must generate it with an idempotency key and redact tokens from logs. In a real evaluation I would run the matrix at morning dispatch, during a shift change, and after a device replacement, because those moments exercise different notification delays and session populations. I would also inspect the audit stream for duplicate transaction IDs, compare the body bytes for known and unknown identifiers, and ask an incident responder to reconstruct the timeline from request ID alone. Those checks take longer than a happy-path request, but they expose the boundaries that matter to a recovery design.

import os
import time
import uuid
import requests

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]


def post(url, payload, idempotency_key):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": idempotency_key,
    }
    delay = 1.0
    for attempt in range(4):
        response = requests.post(
            url,
            json=payload,
            headers=headers,
            timeout=10,
        )
        if response.status_code != 429:
            if not 200 <= response.status_code < 300:
                raise RuntimeError(f"auth call failed: {response.status_code} {response.text}")
            return response.json()
        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else delay)
        delay *= 2
    raise RuntimeError("rate limit persisted after retries")


transaction_id = str(uuid.uuid4())
# The literal form below documents the route for quick offline checks:
# curl -X POST https://api.infrai.cc/v1/auth/password/reset_request
post(
    "https://api.infrai.cc/v1/auth/password/reset_request",
    {"identifier": "test-driver-17@example.test", "transaction_id": transaction_id},
    f"reset-request-{transaction_id}",
)

# The token arrives through the app's controlled notification channel.
token = os.environ["TEST_RESET_TOKEN"]
user_id = "test-user-17"
post(
    "https://api.infrai.cc/v1/auth/password/reset_confirm",
    {"transaction_id": transaction_id, "token": token, "new_password": os.environ["TEST_NEW_PASSWORD"]},
    f"reset-confirm-{transaction_id}",
)
post(
    f"https://api.infrai.cc/v1/auth/session/revoke_all_for_user/{user_id}",
    {"reason": "password_reset", "transaction_id": transaction_id},
    f"session-cleanup-{transaction_id}",
)

The code intentionally does not infer success from a 200 alone, retries 429 with Retry-After, and makes each write idempotent. In production, resolve user_id inside a protected service boundary rather than trusting a browser field. Your mileage may vary on notification latency; the pass/fail rule should use an agreed window, not a guessed constant.

Rejected shortcut and failure boundaries

I reject the shortcut “send a reset link, then leave sessions alone.” It looks friendly in a demo and fails the moment a stolen browser remains authenticated. I also reject a response such as “phone not registered.” That turns the recovery endpoint into a directory oracle.

There are limits to this design. It does not decide whether SMS is appropriate for a high-risk account, supply carrier-level delivery guarantees, or replace a fraud team's device model. If the test shows that your chosen provider cannot express those controls, select a specialist or keep the risk decision in your own service and use the provider only for the verified transition. For Infrai's exact request schema, start with the password reset confirmation documentation and compare its response fields with your audit record.

My decision rule is therefore conditional: try Infrai for the recovery calls when a single REST contract and shared credential management reduce your integration surface, and when your team is prepared to own policy and audit storage. Choose a more managed identity product when adaptive risk, compliance reporting, or regional delivery operations are the dominant constraint.

DEV Community: TitanJ53

Webhook Signature Verification Before JSON Parsing — 4 Raw-Body Boundaries

What is the bill actually made of?

How should webhook signature verification use the raw body before parsing?

Make attribution an output of verification

Rotation needs overlap, not a flag day

The decision rule

Further reading

Apex A Records vs WWW-Only Customer Domain Support: Propagation Trade-offs

What must remain invariant during a customer cutover?

Should customer domains support apex A records and www together?

How should the control plane publish both records?

What belongs in the documentation, not the API?

When is www-only the right rejection?

References

Node.js Express Metric Updates — Dashboard Channel Reconnect Recovery

Decision record: batch diffs and recover with snapshots

What invariants determine the effective cost?

How should a Node.js Express dashboard channel handle batched metric updates after reconnect?

Which realtime delivery option fits this workload?

Rejected option and its valid boundary

References

How to Rank 3 Webhook Checks for Metered Billing: Secret, Headers, Allowlist in FastAPI

The constraint: one webhook event becomes one line on a district's invoice

Which check should be primary — the shared secret, custom headers, or an IP allowlist?

A four-case replay test you can run against staging

What the other layers are genuinely good at

Rolling it out without a billing gap

Sources

DNS Domain Verification in SaaS Onboarding — 3-Phase Completion Signals, Webhooks, Polling

How should SaaS onboarding handle domain verification completion in Node.js?

The three-phase state machine for a hostname cutover

Webhook or polling: what actually changes operationally?

DNS edge cases that break “verified” dashboards

A reversible rollout for media hostnames

References

Password Reset State Machines — Marketplace Revocation Without Account Enumeration

What should a password reset loop verify without leaking account existence?

How can two recovery architectures break loops while protecting account existence?

The critical path: request, confirm, then revoke

Where this design is the wrong choice

References

SMS OTP for Edtech Signup Verification: GDPR, PSD2, NIST, and SIM-Swap Risk

What do GDPR, PSD2, and NIST say about SMS OTP and 2FA?

Why does the signup link need an application-owned state machine?

How should teams handle SMS OTP, phishing, SIM swap, and login risks?

Which template and delivery boundary fits the risk?

Roll out the edtech flow without losing the audit trail

References

Account Shutdown in Node.js Games: State, Sessions, and Deletion (and Why I Chose One)

What should a game shut down first: profile state, sessions, or data?

How do the migration options handle revocation and eventual deletion?

What do we deliberately stop retaining?

A decision rule for the cutover

References

Password-Protected Customer PDF Endpoints Explained — FastAPI Privacy and Retention

TL;DR

Record the invariants before choosing an endpoint

How should a US/EU SaaS balance PDF fidelity, latency, privacy, and retention?

Put the critical job path in one small FastAPI worker

Why reject a browser-owned or all-in-one workflow?

References

SendGrid, Postmark, Mailgun, Twilio, or MessageBird for US/EU Event Alerts?

Which transactional event notifications belong in email or SMS?

How should teams compare US/EU email and SMS providers for event notifications?

Treat polling as a scheduler, not a status loop

Where do compliance and channel boundaries change the answer?

Roll out a reversible provider policy

References

How to Secure Server-Rendered Login Recovery — 5 GDPR Session Revocation Decisions

How to Secure Server-Rendered Login Recovery — 5 GDPR Session Revocation Decisions

Start with the deletion constraint

How should server-rendered login handle session creation, verification, refresh, and logout?

Recovery paths deserve their own threat model

Instrument the failure modes

When this pattern is not suitable

References

Logistics Account Recovery: A 4-State Password Reset Pipeline

The architecture decision record

How should a password recovery pipeline handle neutral requests, confirmed resets, and session cleanup?

Should customer domains support apex A records and `www` together?

When is `www`-only the right rejection?