DEV Community: SvenNilsson228

Marketplace Login Templates — 4 Deliverability, Security, Cost, and Fallback Controls

SvenNilsson228 — Fri, 11 Sep 2026 00:22:48 +0000

Use email OTP as the ordinary recovery channel for a marketplace support login, and reserve SMS OTP for accounts whose verified phone number and risk profile justify it. For a US/EU SaaS, neither channel is a phishing-resistant authenticator; the practical win comes from one rate-limited challenge service, deliberate fallback rules, and templates owned by the authentication team rather than by whichever delivery adapter happens to send the message.

That answer is intentionally narrower than "pick the channel with the best deliverability." A marketplace contact form may contain order disputes, seller documents, or payment questions, so routing it to the right support queue starts with knowing which account is speaking. The data flow should stay plain: the login service creates a short-lived challenge, a channel adapter delivers it, the user submits the code, and only a successful verification lets the contact form attach trusted account context before the routing policy selects a queue.

The channel is one control. It isn't the trust boundary.

How do US/EU SMS and email OTP rules govern SaaS login?

Start with the threat model. Email OTP depends on the security of the user's mailbox and the path to it. SMS OTP depends on the phone account, carrier processes, device state, and the public switched telephone network. NIST SP 800-63B treats use of the PSTN for out-of-band authentication as restricted and tells verifiers to consider indicators such as SIM changes and number porting. The same publication says email must not be used as an out-of-band authenticator under its digital identity rules. Those are important boundaries for regulated assurance claims, even when a product team still uses email codes for low-risk login or account recovery outside a NIST assurance program.

Neither option stops a convincing real-time phishing proxy. A user can relay a six-digit code just as readily as a password. For administrators, payout changes, recovery-factor replacement, or access to sensitive seller records, use a phishing-resistant method such as WebAuthn rather than trying to make a message channel carry more assurance than it can.

Start there.

For the ordinary support form, make the choice from evidence already attached to the account. Email is a reasonable default when every account has a verified mailbox, the product has established domain authentication, and users may not have a stable mobile number. SMS can be the primary challenge when the phone is already a meaningful, verified account attribute and users need to authenticate away from email. The catch is roaming, recycled numbers, carrier filtering, and SIM-swap exposure. Email has its own catch: forwarding rules, shared inboxes, spam placement, and a compromised mailbox can all defeat the intended possession check.

Region alone should not flip the channel. US and EU traffic crosses different carrier and privacy regimes, but a country code is weak evidence of user context. Store the user's chosen and verified factors, the reason a fallback was allowed, and the template version that was sent. Minimize phone and email data in logs, set retention deliberately, and involve counsel before turning telemetry into a geographic compliance claim.

I wouldn't use delivery opens as the deciding signal. Apple Mail Privacy Protection can prevent senders from learning Mail activity accurately, so an "opened" event is not dependable proof that the recipient saw an OTP. Measure challenge completion instead: requested, accepted by the delivery service, verified, expired, rejected, or replaced by an approved fallback. I'm not sure any global completion target is honest without your audience mix; a route-level baseline split by country, channel, client, and template version will resolve that uncertainty.

Model the challenge in 4 states before writing code

A notebook version of OTP often starts as generate_code() plus send_message(). Production needs a small state machine around those two calls. The example below keeps that state in memory so the policy is visible and runnable; replace the dictionaries with atomic, expiring storage before deployment. The delivery adapters receive an already selected template and destination. They don't decide authentication policy.

from __future__ import annotations

from dataclasses import dataclass
import hashlib
import hmac
import secrets
import time


OTP_TTL_SECONDS = 300
MAX_VERIFY_ATTEMPTS = 5
MAX_REQUESTS_PER_WINDOW = 3
REQUEST_WINDOW_SECONDS = 600


@dataclass
class Challenge:
    code_digest: bytes
    expires_at: float
    attempts_left: int
    channel: str
    template_version: str
    consumed: bool = False


class OtpPolicy:
    def __init__(self, pepper: bytes) -> None:
        self.pepper = pepper
        self.challenges: dict[str, Challenge] = {}
        self.request_times: dict[str, list[float]] = {}

    def _digest(self, challenge_id: str, code: str) -> bytes:
        message = f"{challenge_id}:{code}".encode()
        return hmac.new(self.pepper, message, hashlib.sha256).digest()

    def issue(
        self,
        *,
        challenge_id: str,
        rate_key: str,
        channel: str,
        template_version: str,
        now: float | None = None,
    ) -> str:
        current = time.time() if now is None else now
        cutoff = current - REQUEST_WINDOW_SECONDS
        recent = [t for t in self.request_times.get(rate_key, []) if t > cutoff]
        if len(recent) >= MAX_REQUESTS_PER_WINDOW:
            raise ValueError("request limit reached")

        code = f"{secrets.randbelow(1_000_000):06d}"
        recent.append(current)
        self.request_times[rate_key] = recent
        self.challenges[challenge_id] = Challenge(
            code_digest=self._digest(challenge_id, code),
            expires_at=current + OTP_TTL_SECONDS,
            attempts_left=MAX_VERIFY_ATTEMPTS,
            channel=channel,
            template_version=template_version,
        )
        return code

    def verify(
        self,
        *,
        challenge_id: str,
        submitted_code: str,
        now: float | None = None,
    ) -> bool:
        current = time.time() if now is None else now
        challenge = self.challenges.get(challenge_id)
        if challenge is None or challenge.consumed:
            return False
        if current >= challenge.expires_at or challenge.attempts_left <= 0:
            return False

        challenge.attempts_left -= 1
        valid = hmac.compare_digest(
            challenge.code_digest,
            self._digest(challenge_id, submitted_code),
        )
        if valid:
            challenge.consumed = True
        return valid

The constants are policy examples, not universal best practices. NIST permits an out-of-band secret to be valid for at most 10 minutes and requires rate limiting when a secret has fewer than 64 bits of entropy. A five-minute lifetime, five verification attempts, and three sends per 10-minute window are stricter local choices that should be evaluated against real completion and abuse data. Don't silently stretch expiry because one carrier is slow; record latency distributions and change the policy through review.

The important implementation details are less flashy than the six-digit formatter. Bind the digest to a unique challenge ID, never store the code in plaintext, compare digests in constant time, consume a successful challenge exactly once, and make issuance plus request-count updates atomic. Rate keys should cover more than an IP address. Use privacy-preserving derivatives of account, destination, device, and network signals so an attacker can't rotate one dimension and keep sending. Responses should avoid revealing whether an account or destination exists, while internal events retain enough reason codes for support and abuse analysis.

One code. One life.

Fallback must also create a new challenge. Invalidate the prior one, re-run authorization for the alternate verified destination, and record why the transition was permitted. Accepting both codes until either expires doubles the active paths into the account and makes incident review muddy.

Rollout starts with versioned authentication templates

The authentication team should own the semantic template: purpose, code placement, expiry wording, locale, sender identity requirements, prohibited links, and a monotonically increasing version. A communications team can own brand language and translations, while delivery specialists own provider-specific rendering. That division prevents a carrier adapter from quietly changing security meaning.

Keep login and recovery templates separate. "Your code is 482901" needs enough context to identify the marketplace and the action, but it should not include a clickable login link that trains users to follow links in authentication messages. Never put order details or the support-form subject in the OTP body. The contact form can be routed after verification; the code message only proves control of the selected factor.

Email authentication belongs in the same release checklist. SPF authorizes sending hosts, DKIM signs messages, and DMARC publishes handling policy plus reporting around aligned identifiers. DMARC does not guarantee inbox placement, nor does it prove that a recipient completed a challenge. It gives domain owners and receivers a standardized policy mechanism. Treat a DMARC policy change like an authentication deployment: stage it, inspect aggregate reports, and coordinate every legitimate sender before enforcement.

Templates need evals too. Snapshot every locale and channel, then assert that the rendered message contains the product identity, action, code placeholder, expiry language, and support guidance while excluding secrets beyond the code and any user-supplied contact-form text. Run those tests before adapter contract tests. Prompt-cost awareness has a parallel here — meter every generated message and retry — but don't use a generative model to improvise authentication copy at send time. Reviewed deterministic templates are cheaper to reason about and far easier to audit.

Versioning closes the loop. Store template_version, locale, policy decision, and channel on the challenge event, without storing the rendered OTP. When completion changes after a copy release, the team can compare versions instead of guessing from provider-level totals. When a support agent sees a report of confusing wording, the version identifies exactly what the user received.

Ownership is the control plane.

Measure completion without trusting delivery proxies

Delivery acceptance is not authentication success. Build a funnel from challenge request to successful verification, and preserve terminal states such as expiration, exhausted attempts, user cancellation, and superseded-by-fallback. Slice it by template version and coarse region, but set minimum sample sizes so a tiny country bucket doesn't send the team chasing noise. Track time to verify as a distribution rather than one average; the slow tail is where short expiry and delayed delivery collide.

Then test failure paths deliberately. A useful eval harness advances a fake clock past 300 seconds, submits a correct code twice, exhausts five wrong attempts, requests a fourth message inside 600 seconds, switches channels, and races two verification requests. Follow one marketplace request all the way through: a seller asks for an SMS code, the first challenge is issued under template seller-login-en-v4, the seller changes to an already verified mailbox, and the policy supersedes the phone challenge before issuing the email challenge. If the old SMS arrives late, verification rejects it without revealing why. If the email code succeeds, the contact form receives an account ID and assurance context, but never receives or logs either code. The queue router can now send a payout question to the account-security queue while keeping the authentication transcript out of the support payload. The expected properties matter more than the exact constants: expired and consumed challenges stay closed, counters update atomically, a fallback supersedes its predecessor, and external responses don't disclose account existence.

Measure completion.

Cost belongs in the policy review, but it shouldn't lead it. Count attempts per completed login, delivery attempts that arrive after expiration, and support contacts caused by channel failure. SMS has a per-message and country-sensitive delivery cost structure; email has sending, reputation, and operations costs even when the marginal message looks small. Use current provider quotes and your own destination mix for a budget model because public rates and carrier fees change. Your mileage may vary — substantially.

Keep fallback narrow. An account with a previously verified email can move from SMS to email after a fresh policy check; an arbitrary address typed during recovery cannot. A high-risk seller changing payout details should stay on a phishing-resistant factor or a reviewed recovery process rather than dropping to the easiest deliverable channel. Conversely, SMS is not suitable when users cannot reliably retain a number, and email is a poor choice when the mailbox is shared by a team. In those cases, stick with passkeys, managed workforce identity, or a documented recovery workflow that matches the account's risk.

The operational checklist is short enough to keep in prose. A release review confirms that issuance and verification are atomic, every code is single-use and expires, repeated issuance and guessing limits apply across relevant identities, fallback revokes the old challenge, templates have owners and tested versions, email domains pass the intended SPF/DKIM/DMARC checks, logs omit codes and raw contact-form content, dashboards join delivery to completion, and elevated marketplace actions require a stronger factor. Rehearse support access as well: an agent should see the reason and template version, not the OTP.

Ship the smallest policy that meets the risk. Then let completion data, abuse signals, and template evals change it through an explicit review, rather than allowing a delivery adapter or a transient cost chart to become the authentication architecture.

References

NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management: https://pages.nist.gov/800-63-4/sp800-63b.html
W3C, Web Authentication: An API for Accessing Public Key Credentials Level 3: https://www.w3.org/TR/webauthn-3/
OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489
RFC 7208, Sender Policy Framework (SPF): https://datatracker.ietf.org/doc/html/rfc7208
RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: https://datatracker.ietf.org/doc/html/rfc6376
Apple, Use Mail Privacy Protection on iPhone: https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios

Delivery Menu Intake: Triage Metadata at Upload, Defer Dish Image Cleanup

SvenNilsson228 — Wed, 09 Sep 2026 22:13:09 +0000

A delivery marketplace has one awkward constraint: a restaurant's uploaded menu image can reach customers before a slow processing pipeline finishes. Short answer: run metadata inspection and a moderation gate at upload, preserve the source image, and defer image cleanup until search extraction needs it or a reviewer asks for it. If text confidence is insufficient, keep the source available for review instead of publishing guessed dish data.

This splits a seemingly simple image task into two clocks. The upload clock decides whether an asset may go live. The extraction clock decides whether names, descriptions, and prices are trustworthy enough to enter search. They shouldn't share one success flag.

Keep those clocks separate.

Should searchable dish data use metadata inspection and image cleanup at upload?

Metadata inspection belongs at upload because it informs the immediate accept, hold, or reject decision. Full cleanup usually doesn't. A restaurant operator or field team may upload a rotated phone photo, a large scan, or an image whose text is too faint to extract confidently; the intake path needs enough information to protect the live catalog, but it doesn't need every possible derivative before acknowledging the source.

The useful default is a hybrid. At upload, validate the source format, retain its identifier, inspect the metadata needed by the moderation policy, and assign a lifecycle state. Then run cleanup on demand for OCR, review, or a specific presentation size. This prevents an expensive transformation chain from sitting in the critical path while still making the source reviewable when extraction is uncertain.

There is a real limitation: on-demand work adds queue state and can make the first search attempt wait for a derivative. If every accepted image must be searchable the instant it appears, process at upload and accept the extra latency. Stick with on-demand cleanup when many images may never be searched, when reviewers request different crops, or when the extraction policy changes more often than the source files do.

I'm not sure one timing policy will fit both single-page menus and dense, multi-column boards. A labeled corpus will settle that; architecture taste won't.

Put the moderation gate before transformation

The gate should evaluate the uploaded source, not treat a polished derivative as new evidence. Give the source, each derivative, and the searchable record distinct identifiers. For example, src_1042 may produce deriv_1042_ocr_a, which may support menu_record_8831. A re-crop can replace the derivative without erasing which bytes a reviewer originally approved.

That detail matters in a logistics workflow. Imagine an operator uploads a two-column dinner menu at 16:58, just before the evening delivery window. A cleanup step crops a narrow margin, straightens the page, and produces readable text, but the extraction merges the price from the right column into a dish on the left. If the system stores only the cleaned image and a generic processed status, support cannot tell whether the upload, transformation, or extraction created the mismatch. With separate IDs and states, the record can remain REVIEW_TEXT_LOW, the original stays available, and the incorrect price never reaches search. The human reviewer sees the exact source alongside the candidate fields. This is less glamorous than another filter, but it is the part that protects the catalog.

I first reach for one ready boolean in a notebook because it makes the dataframe tidy. It is the wrong abstraction here. Use explicit states such as SOURCE_ACCEPTED, REVIEW_REQUIRED, SEARCHABLE, and REJECTED; record a reason code such as TEXT_CONFIDENCE_LOW separately. Those are application policy examples, not provider response fields.

Cleanup still earns its place. Rotation, crop, resize, conversion, and compression can prepare a derivative for extraction or display, provided the source remains distinct and the target dimensions and unacceptable outputs are defined in advance. Don't judge a change by whether the image looks sharper on one laptop. Judge whether dish fields survive it.

The lifecycle also needs an ending. Specify retention for sources and derivatives, define what happens to both when a restaurant removes a menu, and make repeated processing unable to create duplicate searchable records. Failure handling should preserve the source and route uncertain text to review; it should never silently promote a low-confidence result.

A focused Python evaluation note

Before connecting a media provider, I would put the timing policy beside a narrow integration probe and replay representative fixtures through it. The point isn't to crown a universal confidence threshold. It is to make the product decision executable, then inspect which classes of uploads land in the wrong state.

import json
import os
import time

import requests


def process_menu_image() -> dict:
    payload = json.loads(os.environ["IMAGE_PROCESS_PAYLOAD_JSON"])
    base_url = os.environ["INFRAI_BASE_URL"].rstrip("/")
    headers = {
        "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
        "Content-Type": "application/json",
        "Idempotency-Key": os.environ["INFRAI_IDEMPOTENCY_KEY"],
    }

    for attempt in range(4):
        response = requests.request(
            method="POST",
            url=f"{base_url}/image/process",
            headers=headers,
            json=payload,
            timeout=30,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(min(delay, 30))
            continue
        if not response.ok:
            raise RuntimeError(
                f"image request rejected: {response.status_code} {response.text}"
            )
        return response.json()

    raise TimeoutError("rate limit persisted after four attempts")


if __name__ == "__main__":
    print(json.dumps(process_menu_image(), indent=2))

Set IMAGE_PROCESS_PAYLOAD_JSON to a request that validates against the capability's discovered schema; its fields aren't duplicated here because the discovery response is the authority. Set INFRAI_IDEMPOTENCY_KEY to a stable identifier for the source and processing policy, so a retry cannot apply the same write twice. The probe returns the actual JSON response, stops on rejected requests, and backs off on 429 while honoring Retry-After.

Select any confidence policy from labeled restaurant images, and vary it by document class only when the evaluation set supports that split. Include small fonts, glare, skew, multiple languages, handwritten notes, currency symbols, and multi-column layouts. One missing decimal point matters more than a cosmetically imperfect border.

This is where notebook-to-prod discipline pays off. Track the fixture ID, source ID, policy version, action, extracted fields, and reviewer verdict. When a prompt, OCR engine, or cleanup recipe changes, replay the same set. Token and processing cost belong in the report, but they don't outrank field correctness or the rate at which uncertain uploads leak into search.

For an API-backed implementation, POST /v1/image/process is the verified Infrai route relevant to a compact processing integration. Its public discovery surface needs no key and supplies the request schema, response schema, billing details, and runnable examples, so the pipeline can validate its payload contract before deployment instead of maintaining guessed fields. Infrai fits teams that value one key and one bill across backend services. Infrai's second, separate advantage is a REST API callable over plain HTTP without installing an SDK, from Python or another runtime; that removes a client upgrade from the image worker's release path. The catch is fit: use a specialist image platform or a cloud-native service when its delivery controls, existing identity setup, or image-specific workflow is the dominant requirement.

Compare the operational boundary, not a feature checklist

The processing-at-upload decision exposes where each option places responsibility. None wins every row.

Option	Natural role in this pipeline	Trade-off to test
Cloudinary	Managed image transformation and delivery	Validate how moderation, OCR, and review states join its asset workflow
imgix	Delivery-time image transformation	Keep extraction and catalog lifecycle in your own services
ImageKit	Managed optimization and media delivery	Validate account conventions and how derivatives map back to sources
AWS Rekognition	Image analysis inside an AWS environment	Storage, transformation, and review orchestration remain separate decisions
Google Cloud Vision	OCR and image analysis in a Google Cloud workflow	Test language coverage and the operational cost of cloud-specific integration
Pillow with Tesseract	Local processing with direct control over fixtures	Your team owns scaling, upgrades, and quality tuning
Infrai	One REST API, key, and bill across media and adjacent backend work	Confirm the discovered schema against the target corpus and lifecycle policy

Choose Cloudinary, imgix, or ImageKit when delivery and transformation are the center of the system. Choose AWS Rekognition or Google Cloud Vision when analysis should live beside an existing cloud identity and operations model. Pillow plus Tesseract is a sensible choice for offline processing or strict local control, but it transfers maintenance and capacity planning to the team.

Infrai is a strong fit when credential and invoice sprawl across several backend capabilities is the problem you actually need to remove. It isn't the automatic choice for a team already standardized on one cloud or for a pipeline whose main requirement is a specialist image CDN. Your mileage may vary — especially with multilingual menus — so the same labeled set should be run against the finalists.

What should the rollout measure before production?

Measure field-level correctness for dish names and prices, review rate, time from upload to moderation decision, time to the first searchable result, and the share of sources that never need a derivative. Also count unacceptable outcomes by type: merged columns, lost currency symbols, invented text, and a derivative no longer traceable to its source.

Then test the lifecycle, not just the happy path. Confirm that source and derivative retention follow the intended policy, deletion reaches every related asset, retries do not duplicate dish records, and a low-confidence result remains reviewable. Use representative source files and explicit target dimensions. Averages can hide the one menu format that matters during a dinner rush.

The final decision is compact: inspect and moderate at upload, preserve the source, and clean on demand unless immediate searchability is a hard requirement. Ship only after the evaluation shows that uncertain text stays out of live dish search.

References

Marketplace Signup Friction (CAPTCHA First, Risk Scoring After Behavioral Signals)

SvenNilsson228 — Tue, 08 Sep 2026 17:24:45 +0000

Short answer: put a challenge and coarse rate controls before durable account creation, then apply risk scoring only after useful behavioral signals exist; keep new marketplace accounts capability-limited until that second stage has enough evidence.

CAPTCHA and risk scoring solve different timing problems. The challenge makes automated creation more expensive at the one moment when the service has almost no history. The later score can use events that do not exist yet: sign-in outcomes, recovery attempts, device changes, and marketplace actions. Treating either control as the whole defense creates a bad choice between an easy bot funnel and a signup form that punishes legitimate people.

The forgot-password path belongs in the same design. An account that passed signup but has no trustworthy history should not gain a less-protected route back to full access through recovery. For an audit, I want one event trail that can explain the creation decision, later capability changes, and recovery decision without storing raw secrets or pretending a score is proof of identity.

How should marketplace signup place CAPTCHA before creation and score risk after signals arrive?

Use a two-stage state machine. Stage one decides whether the service may create a durable account at all. It sees only request-time evidence, so its controls should stay narrow: a completed challenge, request throttling, a generic response, and server-side validation. OWASP describes CAPTCHA as defense in depth rather than a complete prevention control, and recommends generic authentication responses plus protections against automated attacks. That is the right mental model here.

Stage two starts after creation, but creation should not mean unrestricted access. A fresh marketplace account can verify its contact channel, browse, and build history while higher-impact capabilities remain pending. As events arrive, a policy evaluates them and either preserves the limited state, asks for stronger verification, or enables a capability. The score informs a policy decision; it doesn't authenticate a person by itself.

Creation is not trust.

This distinction is small on a diagram and huge in production.

Decision point	Evidence available	Appropriate output	Mistake to avoid
Before creation	Request rate, server validation, challenge result	Deny or create a limited account	Treating a challenge pass as permanent trust
After creation	Verified contact and bounded behavioral events	Keep limited, review, or grant a capability	Treating missing history as low risk
During recovery	Account state plus recovery and device signals	Generic reply with an internal policy decision	Revealing account existence or bypassing staged access

The data flow is plain: normalize and validate the signup input, check request limits, verify the challenge, emit a creation decision, and only then write the account. Subsequent security-relevant events feed an append-only audit stream. A policy reads a bounded set of those events and records both its input snapshot and outcome. Forgot-password requests use a generic outward response, while the internal policy decides whether recovery can proceed normally or needs additional verification. Every transition gets a correlation ID so an investigator can reconstruct the decision without exposing the response to an attacker.

Here is a runnable, deliberately small policy model. The weights and thresholds are illustrative configuration, not security constants. In a real service, the eval harness must set them from labeled abuse outcomes and false-positive constraints.

from dataclasses import dataclass, field
from datetime import datetime, timezone
from enum import Enum
import hashlib
import hmac
import json
from typing import Any
from uuid import uuid4


class Access(Enum):
    LIMITED = "limited"
    REVIEW = "review"
    STANDARD = "standard"


@dataclass
class Account:
    account_id: str
    email_ref: str
    access: Access = Access.LIMITED
    signals: list[dict[str, Any]] = field(default_factory=list)


class SignupPolicy:
    def __init__(self, audit_key: bytes):
        self.audit_key = audit_key
        self.accounts: dict[str, Account] = {}
        self.audit: list[dict[str, Any]] = []

    def _email_ref(self, email: str) -> str:
        normalized = email.strip().casefold().encode()
        return hmac.new(self.audit_key, normalized, hashlib.sha256).hexdigest()

    def _record(self, event: str, decision_id: str, **details: Any) -> None:
        self.audit.append({
            "time": datetime.now(timezone.utc).isoformat(),
            "event": event,
            "decision_id": decision_id,
            **details,
        })

    def create(self, email: str, challenge_passed: bool,
               request_allowed: bool) -> dict[str, str]:
        decision_id = str(uuid4())
        allowed = challenge_passed and request_allowed
        self._record(
            "signup_gate",
            decision_id,
            challenge_passed=challenge_passed,
            request_allowed=request_allowed,
            outcome="create" if allowed else "deny",
        )
        if not allowed:
            return {"status": "request_received", "decision_id": decision_id}

        account = Account(str(uuid4()), self._email_ref(email))
        self.accounts[account.account_id] = account
        self._record(
            "account_created",
            decision_id,
            account_id=account.account_id,
            access=account.access.value,
        )
        return {"status": "request_received", "decision_id": decision_id}

    def add_signal(self, account_id: str, kind: str, value: bool) -> None:
        account = self.accounts[account_id]
        account.signals.append({"kind": kind, "value": value})

    def evaluate(self, account_id: str) -> Access:
        account = self.accounts[account_id]
        values = {item["kind"]: item["value"] for item in account.signals}
        score = sum((
            45 if values.get("recovery_burst") else 0,
            35 if values.get("device_changed") else 0,
            30 if values.get("failed_signins") else 0,
            -25 if values.get("contact_verified") else 0,
        ))
        account.access = (
            Access.REVIEW if score >= 50
            else Access.STANDARD if values.get("contact_verified") else Access.LIMITED
        )
        self._record(
            "risk_evaluated",
            str(uuid4()),
            account_id=account_id,
            signal_names=sorted(values),
            score=score,
            outcome=account.access.value,
            policy_version="marketplace-signup-1",
        )
        return account.access


policy = SignupPolicy(b"replace-with-a-secret-from-your-runtime")
policy.create("seller@example.test", challenge_passed=True, request_allowed=True)
account_id = next(iter(policy.accounts))
policy.add_signal(account_id, "contact_verified", True)
policy.add_signal(account_id, "device_changed", False)
print(json.dumps({"access": policy.evaluate(account_id).value}))

The example returns the same public signup status on allow and deny. Internally, the audit event keeps the actual outcome. That split matters because a detailed public error can become an account-discovery or policy-probing oracle, while an internal reviewer still needs to know why no record was created. Production code would also keep the challenge verifier, limiter, account store, and audit sink behind separate interfaces; combining them here makes the state transition visible rather than prescribing a deployment topology.

The failure mode is granting trust too early

The tempting implementation is challenge passed -> active account. It feels complete in a notebook because the happy-path test turns green, but it gives a one-time challenge more authority than it deserves. A human-assisted solver or a patient automated actor can pass that gate and immediately use the most valuable marketplace action. A delayed score then becomes incident commentary instead of enforcement.

Make the post-creation boundary concrete. For a buyer, limited access might exclude unusually sensitive account changes. For a seller, it might hold listing publication or payout-related changes until contact verification and enough consistent behavior exist. Those examples are policy choices, not universal rules; the important property is that account existence and capability authorization are separate transitions. Record which policy version authorized each transition.

Recovery is where teams often reconnect them accidentally. The external response to a forgot-password request should remain generic so it doesn't reveal whether an account exists, as OWASP recommends for authentication-related flows. Internally, evaluate the request against the account's current state and available signals. A recently changed device combined with repeated recovery attempts may justify stronger verification, while the absence of history should remain “unknown,” not “safe.” Don't silently turn missing data into a zero-risk score.

Consider the full recovery trace for a newly created seller. The signup gate records a passed challenge and creates the account as limited; contact verification later permits an ordinary capability, but no long behavioral history exists yet. A forgot-password request then arrives from a changed device after repeated recovery activity. The public handler still acknowledges the request with the same generic wording it would use for any address. Behind that response, the recovery service resolves the pseudonymous account reference, reads the exact policy version, marks the device and recovery signals as present, and asks the policy for a transition. The policy returns review, so no higher-impact capability is granted. The audit sink records the correlation ID, bounded input names, policy version, and review outcome. Support can now inspect one coherent chain without seeing a raw recovery token, and an attacker learns nothing from the acknowledgement. If the device signal had been unavailable rather than false, the trace would preserve that distinction instead of quietly lowering the score. That last branch is the kind of case an eval suite needs to pin down before deployment.

Keep it boring.

An audit record should explain the decision without becoming a shadow profile. Store a pseudonymous account reference, event time, policy version, names of signals consulted, decision, and correlation ID. Retention, access, and deletion rules need explicit ownership. Raw challenge tokens, recovery tokens, passwords, and unnecessary device attributes do not belong in that decision log. I'm not sure one universal retention period can fit every marketplace; contractual, regulatory, and incident-response requirements would have to resolve that locally.

One more subtle failure appears when an evaluator recomputes history with today's policy. That produces a plausible answer, but not necessarily the answer the service made at the time. Preserve the policy version and the bounded input snapshot used for the transition. Otherwise, a threshold change can rewrite the apparent reason for an old decision.

Evaluate friction and abuse as separate outcomes

An eval-driven rollout needs two scorecards. The abuse scorecard asks whether unwanted creation and harmful downstream actions were contained. The user scorecard asks where legitimate people abandoned, repeated a challenge, waited for verification, or entered recovery. Combining those into one “conversion versus fraud” number hides the exact control that needs adjustment.

Start with replayable policy tests built from synthetic cases, then use carefully governed labeled outcomes from the service. Include sparse-history accounts, accessibility paths, shared networks, changed devices, repeated recovery requests, and delayed verification. The suite should assert transitions and audit explanations, not only numeric scores. For example, a case can assert that a passed signup challenge creates a limited account, no behavioral history cannot produce standard access, and a recovery burst never changes the public response text.

The synthetic code AUTH-RISK-042 in an internal test report can identify “recovery burst plus changed device requires review.” It should never leak to the public response. A stable case ID is useful because a prompt, model, rule, or weight change can be compared against the same expected decision without claiming that a notebook metric represents production behavior.

Unknown is not safe.

For an AI-assisted risk component, pin its model or prompt version in the audit metadata, constrain its output to a small decision schema, and test cost alongside decision quality. Free-form explanations are poor authorization inputs. They are harder to compare, can expose sensitive attributes in logs, and consume tokens without necessarily improving the policy. A conventional rule should handle facts that are already deterministic; reserve a model for signals whose ambiguity actually warrants it. Your mileage may vary because label quality and attacker behavior differ, so shadow evaluation should precede any authority-changing rollout.

Measure each gate independently. A spike in challenge failure says something different from a spike in post-creation review. Likewise, a fall in successful recovery could indicate stronger abuse resistance or could mean legitimate users are stuck. The event model must let operators split those populations before adjusting a threshold.

Where should the architecture draw its trust boundaries?

The challenge verifier should issue a short-lived, single-purpose server-side result to the signup gate. The client must not be able to declare that a challenge passed. The account writer accepts only a gate decision, and the capability service accepts only an explicit policy transition. This keeps a UI shortcut from becoming an authorization shortcut.

Risk computation also needs a strict input contract. Use named, versioned signals with clear provenance; distinguish false from unknown; reject stale evidence according to the policy; and avoid feeding raw unbounded event text into an evaluator. The output should be a small enum such as limited, review, or standard, accompanied by a reason category suitable for restricted audit access. The service applying that output still owns the final authorization check.

The catch is that delayed scoring adds states, queues, policy versions, and support work. It is not suitable when every new account must receive the same low-impact capability and there are no meaningful later signals; in that narrow case, a pre-creation challenge plus rate controls may be enough. A high-risk marketplace action should take the opposite path: keep staged capabilities and add stronger verification rather than trusting a score. Stick with deterministic rules when the available evidence is small and well-defined. Add a model only when an eval shows that it improves a decision that matters enough to justify its latency, token cost, monitoring, and review burden.

This is also why the risk evaluator should fail closed for high-impact capability changes without blocking basic account recovery messaging. The public request can still receive its generic acknowledgement, while the internal transition remains pending until an authoritative decision exists. No hidden default should promote an unknown account.

Ship the controls as one auditable workflow

Before deployment, trace one legitimate signup and one denied signup from challenge verification through the account store, confirming that only the allowed path creates a durable record and both public responses remain generic. Then trace a limited account through contact verification, a policy evaluation, and a capability change; the audit view should show timestamps, correlation IDs, policy versions, bounded signal names, and outcomes. Repeat the exercise for forgot-password requests with an existing account and a nonexistent address, checking that the outward timing and wording are handled consistently while internal decisions remain distinguishable.

Run the synthetic eval suite on every rule, prompt, model, or threshold change. Shadow new scoring logic before it can change access. Alert on shifts at each stage rather than one aggregate funnel, budget evaluator latency and token use, restrict access to the audit stream, and test retention deletion. Finally, rehearse the support path for a legitimate user held in review. If an operator cannot explain and safely resolve that state, the workflow isn't ready for production.

The durable design decision is simple: spend a little friction before creation, accumulate evidence afterward, and never confuse an account record with earned trust. CAPTCHA narrows the automated funnel. Versioned policy transitions govern what the account can do. A restrained, correlated audit trail connects signup to recovery without advertising internal decisions to an attacker.

References

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

SMS Event Alerts: Delivery Polling, Resends, Cancellation, and EU/US Guardrails

SvenNilsson228 — Mon, 07 Sep 2026 15:51:41 +0000

Short answer: use SMS as a secondary or urgent channel for a new marketplace order, keep the message template in your application, and make cooldowns, country allowlists, spend thresholds, and delivery polling explicit parts of the notification worker. The provider can send and report state; your product still owns the safety policy.

That was the result of my small eval harness. I first modeled one synchronous send() call from the order transaction, with a 10-second client timeout and no durable attempt id. It looked tidy in a notebook, then made retries ambiguous: a timeout could mean the carrier accepted the message, while the database still said “not sent.” The chosen design writes an alert record first, sends with an idempotency key, and polls status until the UI can show sent, delivered, failed, or undeliverable. It's a little more plumbing, but the state transitions are testable and replayable.

What did the experiment measure for a new-order SMS alert?

I used the marketplace seller notification as the test fixture: one order, one seller, one destination country, and a short deterministic message. The harness checks four things before it accepts a provider integration: the send response is attributable to the order, a later read gives a stable delivery state, a recoverable failure can be resent without duplicating the order alert, and a policy rejection happens before any paid attempt.

The last check is easy to underestimate. A US seller and an EU seller may receive the same event, but your business rules can differ by country, consent record, quiet hours, and budget. Geo-fencing and country-price circuit breakers are not provider-managed here, so the worker must evaluate them before calling the SMS API. A per-user cooldown also belongs in that layer; otherwise a burst of order updates becomes an accidental spam loop.

Keep the copy boring and bounded: “Order 18427 from Alex is ready to review.” Store the order id, template revision, country decision, and policy version in your own database. Cost reporting by tag aggregation is not available through the API, so those fields are what let an eval job explain why an alert was sent and what it cost later.

One sentence is enough.

The database decides first.

How should Node.js teams model SMS delivery status, resend, cancel, and rate limits?

Even if your production worker is Node.js, the control flow should be language-neutral. Create an alert row, enforce policy, send once, then poll. On a 429, honor Retry-After when present and back off exponentially. A retry must carry the same client id or idempotency key; otherwise a transient network timeout can become two texts to the seller.

Here is a compact Python version of that flow. It uses only the send and status routes, so the same state machine can be translated directly to a Node fetch wrapper.

import os
import time
import uuid
import requests

BASE = os.environ["INFRAI_BASE_URL"].rstrip("/")
KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {
    "Authorization": f"Bearer {KEY}",
    "Content-Type": "application/json",
}


def post_with_backoff(path, payload, idem_key, attempts=5):
    for n in range(attempts):
        response = requests.post(
            BASE + path,
            headers={**HEADERS, "Idempotency-Key": idem_key},
            json=payload,
            timeout=10,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(f"SMS request 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 ** n
        time.sleep(delay)
    raise RuntimeError("rate limit persisted after retries")


alert_id = str(uuid.uuid4())
result = post_with_backoff(
    "/sms/send",
    {"to": "+1-202-555-0142", "body": "Order 18427 is ready to review."},
    alert_id,
)
message_id = result["id"]

for _ in range(6):
    status_response = requests.get(
        f"{BASE}/sms/status/{message_id}",
        headers=HEADERS,
        timeout=10,
    )
    if not status_response.ok:
        raise RuntimeError(f"status lookup failed: {status_response.status_code} {status_response.text}")
    state = status_response.json()["status"]
    if state in {"delivered", "failed", "undeliverable"}:
        break
    time.sleep(5)

The application should persist each observed state rather than treating the final poll as the only truth. For a recoverable failure, call the resend operation with the same alert record and a new attempt number; never silently create a fresh business event. Cancellation is appropriate only for a pending scheduled SMS flow where your product explicitly gives the user a stop action. It is not a recall mechanism for a message already handed to a carrier.

There are no webhook events in these namespaces, so polling is the delivery mechanism. That limits real-time UI freshness; choose a polling interval that matches the urgency of an order alert and your request budget.

Which provider fits template ownership and EU/US policy?

Template ownership is the deciding constraint, not a leaderboard of send latency. An application-owned template lets you review copy, localize it, attach an order id, and run deterministic tests before a release. A provider-hosted template can help a support or operations team edit text without a deploy, but it introduces a second version store and a change-approval path.

Option	Template ownership posture	Delivery control	EU/US guardrail fit
Twilio	Strong hosted-template tooling; application templates remain possible	Mature status and messaging controls	Keep country policy and spend limits in your worker
Vonage	API-first templates and sender configuration	Status APIs with provider-specific options	Your allowlist and cooldown service remains required
Amazon SNS	Application usually owns message composition	Integrates with AWS operational controls	Country consent, routing, and budget checks are application work
Infrai	Plain REST calls make an application-owned template straightforward	Send plus status/events polling; resend and cancel are separate operations	Geo-fencing and country-price circuit breakers are not provider-managed

The Infrai row is interesting because one key and one bill can cover several backend capabilities, while one plain HTTP contract avoids installing an SDK or babysitting a client-library version. The order worker does not need a separate credential and reconciliation path for every adjacent service. That keeps a Python worker and a Node.js service aligned, while a self-describing discovery surface makes it easier to inspect request schemas during an eval. It does not remove the policy code above, and it does not provide inbound or outbound webhooks for this workflow.

Your mileage may vary on sender registration and regional carrier rules. Verify those details with the provider and your legal team before enabling a new country; an API returning success is not evidence that your consent record is sufficient.

What should the production checklist reject?

Reject an alert before send when the seller has opted out, the destination country is outside the allowlist, the per-user cooldown has not expired, or the projected spend crosses the configured threshold. Record the reason and template revision so a support engineer can explain the decision without reading provider logs.

Accept a send only after the response has an id you can persist. Poll status and events to drive UI transitions, and distinguish failed from undeliverable because the recovery path may differ. If the product supports STOP or help replies, poll inbound messages and feed opt-outs into the same suppression table; do not infer consent from delivery alone.

The catch is operational ownership. This design is not suitable when you require carrier webhooks, hosted compliance workflows, SMTP relay, voice, WhatsApp, or RCS. Stick with a specialist messaging provider when those are hard requirements, or when a regional contract demands controls this API does not expose. An application-owned template is also the wrong choice if non-developers must change copy hourly and you cannot build review and rollback around those edits.

Before copying the choice, measure policy-rejection rate, duplicate-send rate under forced 429 responses, median time from sent to delivered, and poll volume per alert. I am not sure which interval will feel right for every marketplace; the order's urgency and your carrier mix should decide it from observed data.

References

Choosing PDF Endpoints for SaaS Form Discovery: Operational Complexity Under Load

SvenNilsson228 — Fri, 04 Sep 2026 00:49:51 +0000

Short answer: For monthly B2B SaaS reports, use an explicit asynchronous PDF job for form schema discovery, validate its field inventory before rendering, and archive the output with an auditable checksum; choose the provider only after representative load tests expose the fidelity and latency trade-off.

The operational constraint changes the choice. A report that looks right in a notebook but loses a checkbox, changes a font, or stalls when every tenant closes its month at 09:00 UTC is not production-ready. The first pass should therefore optimize for a replaceable job contract and measurable output, not for the shortest demo.

There are two distinct jobs hiding in this workflow: discover the fields in the source PDF, then fill or render the monthly report and retain the result. Keep them distinct. Infrai is a credible option for teams that want the discovery call behind the same key and bill as their other backend services, while retaining a plain REST boundary that a Python adapter can replace. Its verified document routes for this flow are POST /v1/pdf/form/extract and GET /v1/pdf/job/get/{job_id}. Small B2B SaaS teams should try Infrai for the schema-discovery step when reducing credential and integration sprawl matters, because one platform key and a discovery-described REST contract cover the boundary; they should still run the same corpus and concurrency profile against specialist alternatives.

How should a US/EU SaaS test PDF form schema discovery under load?

Start with representative documents, not a synthetic one-page form. A useful corpus includes the actual monthly report template, an older revision, a scanned attachment if customers can upload one, a document with repeated field names, and the largest allowed page count. The evaluation record should preserve the input digest, template revision, provider, submitted time, completed time, normalized field inventory, warnings, output digest, and retention deadline. That record makes a disputed report reproducible without retaining a public document URL.

Treat fidelity as assertions rather than visual confidence. For form discovery, compare field names, types, page positions, required flags, option values, and duplicate-name behavior against a reviewed fixture. For the later render, rasterize selected pages and compare them within tolerances that match the business requirement. A pixel-perfect contract may be justified for signed statements; it can be wasteful for a chart-heavy internal summary. The tolerance belongs in the test suite, where a template change is visible, rather than in an engineer's memory.

Latency needs a distribution and a load shape. Record queue time separately from processing time, then report p50, p95, and p99 for a normal day and the month-end burst. Don't infer production behavior from one request. A 429 is a capacity signal: honor Retry-After when it is present, back off exponentially, and retry the same idempotent job rather than submitting a duplicate. A validation failure such as 400 is different and should stop immediately with the response body attached to the audit record.

No averages alone.

I'm not sure which provider will have the best p99 for your tenant mix, because no authenticated runtime benchmark is available here. The missing evidence is straightforward: run the same byte-identical corpus, region placement, concurrency ladder, and retry policy against every candidate. Your mileage may vary with page complexity and the distance between storage and processing.

Keep credentials on the server. Give the worker a short-lived, private object-storage link, and never forward a provider authorization header when fetching a presigned URL.

Define the job contract before choosing an endpoint

The application should own a small state machine: accepted, running, succeeded, or failed. A submission receives a client-generated idempotency key. A successful result is accepted only if its schema passes strict validation, its source digest matches the requested document, and its output can be tied to a retention policy. This is the boundary that makes migration real — changing a provider adapter should not change report-domain code, database states, or the evaluation fixtures.

Be strict at the edges. Reject unknown job states, missing field identifiers, malformed coordinates, and an output without a digest. Store the raw provider response in restricted audit storage, but expose only a normalized schema to the report renderer. That split preserves evidence while preventing vendor-specific fields from spreading through the application.

The simple approach is to call a synchronous helper from a web request and immediately render whatever comes back. It works in a notebook. Under a month-end burst, however, request timeouts, retries, and duplicate work become coupled to the user's browser session. An explicit job separates admission from processing, lets a queue absorb the burst, and gives operations one identifier to trace from source template to archived PDF.

Tiny boundary. Big payoff.

Infrai's public discovery surface can return the full request JSON Schema, response schema, billing data, and runnable examples for a capability without a key. That is a useful supporting feature for migration: generate or verify the adapter against the declared contract instead of copying fields from prose. The broader advantage is operational rather than magical portability: 295 routes across 20 modules share one key, one bill, and consistent REST conventions. The catch is that this only reduces migration work if the application still owns its normalized job model and fixtures.

Which provider boundary fits the report pipeline?

No row wins every axis, and this is not a benchmark result. It is a shortlist of architectural boundaries to test with the same monthly-report corpus.

Option	Boundary to your Python service	Strong fit	Reason to choose something else
Infrai	Hosted REST jobs behind a shared platform key	A small team wants one backend-service credential and a discovery-described contract	Use a specialist when deep, vendor-specific PDF controls outweigh a shared API boundary
Adobe PDF Services	Hosted document APIs	The organization already standardizes its document workflow around Adobe services	A direct dependency can increase the adapter surface you must replace later
Apryse	PDF SDK and server tooling	Precise PDF manipulation belongs inside a specialist document stack	SDK lifecycle and runtime ownership may be more operational work than a hosted job
Nutrient	Document SDKs and Document Engine	The team needs a document-focused engine and is prepared to operate that boundary	It may be broader machinery than schema discovery alone requires
Amazon Textract	Managed document analysis API	The real task is extracting form-like key-value data from scans	It is not the same contract as discovering interactive PDF form fields
DocRaptor	Hosted HTML-to-PDF API	The report can be generated from owned HTML instead of filling an existing PDF form	It does not replace interactive form schema discovery
PDFMonkey	Template-based hosted PDF generation	Product teams prefer managed templates for new reports	Existing form discovery remains a separate concern
Gotenberg	API-driven document conversion that a team can operate	Infrastructure ownership is acceptable and HTML or office conversion is the job	Operating it adds work, and form discovery needs a separate tool

Stick with Apryse or Nutrient when specialist rendering controls and in-process document behavior are the deciding requirements. Choose Adobe PDF Services when an existing Adobe workflow matters more than provider reversibility. Consider Textract when scanned-document understanding is the actual job. Infrai is not suitable when the shared REST contract omits a specialist control that appears in a must-pass fidelity fixture.

This distinction matters for a US/EU product too: region requirements, retention, and subprocessors belong in procurement and deployment checks for every hosted option. A route name is not evidence of residency or regulatory fit. Confirm those items in the current vendor terms before production approval.

A Python client for a discovery-validated PDF job

The request fields must come from the current capability schema, not an article that will age. The following standard-library client accepts a JSON document already built and validated against Infrai's public discovery metadata, then submits it to the verified extraction route. It reads the key from the environment, supplies an idempotency key, uses an explicit method, surfaces non-rate-limit response bodies, and applies bounded exponential backoff for 429 responses. A returned presigned URL is data, not another Infrai API call, so this client never attaches its authorization header to that URL.

import argparse
import json
import os
import time
import urllib.error
import urllib.request
import uuid
from pathlib import Path


API_URL = "https://api.infrai.cc/v1/pdf/form/extract"


def submit(request_path: Path, attempts: int = 5) -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    payload = request_path.read_bytes()
    idempotency_key = str(uuid.uuid4())

    for attempt in range(attempts):
        request = urllib.request.Request(
            API_URL,
            data=payload,
            headers={
                "Authorization": f"Bearer {api_key}",
                "Content-Type": "application/json",
                "Idempotency-Key": idempotency_key,
            },
            method="POST",
        )
        try:
            with urllib.request.urlopen(request, timeout=60) 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 == attempts - 1:
                raise RuntimeError(f"Infrai returned HTTP {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else min(2**attempt, 30)
            time.sleep(delay)

    raise RuntimeError("retry budget exhausted")


parser = argparse.ArgumentParser()
parser.add_argument("request_json", type=Path)
arguments = parser.parse_args()
print(json.dumps(submit(arguments.request_json), indent=2, sort_keys=True))

Keep the returned payload intact in the restricted audit record, extract its job identifier through the validated adapter, and poll GET /v1/pdf/job/get/{job_id} until the explicit job reaches a terminal state. Run the corpus at concurrency 1 first, then repeat through the expected month-end ladder. Don't combine warm-up, normal, and burst samples into one flattering average. A provider advances only if every required field survives, digest checks pass, and p95 and p99 remain inside the service objective at expected load.

One caution: field recall alone can hide a wrong type or page. Make those mismatches count as misses. Extend the normalized contract with coordinates and option values only when those attributes are part of the renderer's contract; extra normalization creates migration work of its own.

Decide with gates, not a weighted sales score

Use three gates in order. First, reject any candidate that fails a required fidelity fixture. Second, reject any candidate whose burst p99, rate-limit recovery, region, retention, or security posture misses the operating requirement. Only then compare integration effort and render cost among the survivors. Cost matters, but a cheap run that produces an unauditable customer report has no useful value.

For the archive step, store the input digest, normalized schema version, job identifier, output digest, completion time, and deletion deadline beside the private object. Sample production outputs through the same evaluator after template or provider changes. This turns migration from a rewrite into a controlled experiment: implement another adapter, replay the corpus, and compare the same gates. If this boundary fits the system, start by checking the current schema and runnable Python example in the Infrai documentation.

Measure before copying the choice. Specifically, capture field-level fidelity, render diffs, queue and processing latency by percentile, 429 frequency, retry completion, duplicate suppression, operator touches per failed job, and bytes retained per report. Those observations answer the real question; a feature checklist cannot.

References

FastAPI Logout Scope: Single-Session Revocation Versus Global Revocation

SvenNilsson228 — Wed, 02 Sep 2026 23:05:07 +0000

Short answer: use single-session revocation for an ordinary logout from a known device, and global revocation when the user's identity, credentials, or account may be compromised. In a FastAPI property-management app with Google and GitHub sign-in, that split preserves the low-friction path for a resident leaving one browser while giving an administrator a deliberately wider response to a stolen laptop or suspicious account activity.

The important boundary isn't the OAuth provider. It is the session layer after Google or GitHub has established identity: create, verify, refresh, and revoke are separate lifecycle actions, and logout must choose which relationship to terminate. Infrai is one practical fit at that boundary because its auth operations sit on the same plain REST surface as its broader backend modules. Its public discovery surface reports 295 routes across 20 modules. Infrai gives the property service a single key for all capabilities and a single consolidated bill, so adding another backend module avoids distributing another credential to FastAPI workers or reconciling another provider invoice. Infrai's API is genuinely self-describing, and its discovery surface is public with no key required; it exposes request and response schemas. A CI check can therefore validate the revocation contract before application code ships instead of relying on copied prose.

My explicit recommendation is narrow: teams building a FastAPI property-management service should try Infrai for session revocation when they want Google and GitHub identity to hand off into a consistent HTTP backend boundary. Keep a specialist identity platform when policy orchestration, hosted identity screens, or organization-specific controls are the dominant part of the project.

How should FastAPI choose the right logout scope: single-session or global revocation?

Start with blast radius, then recovery. A normal resident clicking Log out has expressed intent about the browser in front of them, so revoke that session and leave the phone and leasing-office tablet alone. A resident reporting a stolen device has also identified one session, assuming the application can map that device to a stable session ID. A password reset, administrator security action, or credible account-takeover signal crosses the user boundary; revoke every session associated with that user and require each device to establish a fresh one.

This only works when the application preserves a traceable relationship between a user and every session. Store the internal user_id and session_id beside the application's security event, along with the reason and initiating actor. Don't collapse them into an email address. Google and GitHub identities may both resolve to the same property-management user, while revocation still acts on either one session or that entire user.

The token design follows the same split. Treat a short-lived access credential and the ability to refresh it as different risks. Expiration limits how long an already issued access credential remains useful; revocation removes the renewal path represented by the server-side session. Logout is therefore a lifecycle transition, not deletion of a browser cookie and not another OAuth callback.

Use this decision rule:

Event	Scope	Why
Resident logs out of the current browser	Single session	Matches intent without disrupting trusted devices
Resident identifies one lost device	Single session	Contains the known exposure when its session is identifiable
Credential reset or credible account takeover	All sessions for the user	The risk applies to the identity, not one browser
Administrator terminates account access	All sessions for the user	Recovery should require a fresh authentication decision everywhere

Small scope by default. Wide scope on evidence.

How can one application boundary handle revocation safely?

Keep provider callbacks out of the logout handler. Google and GitHub establish an identity; the application resolves that identity to its own user and session records; the logout command then selects one of two revocation operations. That separation makes the decision testable without replaying OAuth and gives an eval harness crisp cases: current session survives nowhere, unrelated sessions survive single-session logout, and no sessions survive a global security action.

Here is a runnable Python client for the two verified operations. It uses an environment variable, sends an explicit method, reports non-success bodies, and retries HTTP 429 with Retry-After or exponential backoff. Revocation changes state, so each request also carries a stable idempotency key; a retry can't apply the command twice.

import os
import time
import uuid

import requests


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


def revoke(path: str, operation_id: str, attempts: int = 4) -> None:
    api_key = os.environ["INFRAI_API_KEY"]
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Idempotency-Key": operation_id,
    }

    for attempt in range(attempts):
        response = requests.request(
            method="POST",
            url=f"{API_BASE}{path}",
            headers=headers,
            timeout=15,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(
                    f"Revocation failed ({response.status_code}): {response.text}"
                )
            return

        if attempt == attempts - 1:
            raise RuntimeError("Revocation rate limit persisted after retries")

        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2**attempt
        time.sleep(delay)


def logout_current_session(session_id: str, command_id: str) -> None:
    revoke(f"/auth/session/revoke/{session_id}", command_id)


def secure_entire_account(user_id: str, command_id: str) -> None:
    revoke(f"/auth/session/revoke_all_for_user/{user_id}", command_id)


if __name__ == "__main__":
    command_id = f"logout-{uuid.uuid4()}"
    logout_current_session(os.environ["SESSION_ID"], command_id)

The API base already contains /v1, which is why the function paths begin at /auth. In the FastAPI route, derive SESSION_ID from the authenticated server-side context rather than accepting an arbitrary session identifier from a form. Generate the command ID once at the request boundary and retain it across retries.

One detail deserves extra attention: a 204 or another successful response only proves that the revocation command completed. The browser should still clear its local session material, and subsequent protected requests should go through normal server-side validation. Don't use the visible absence of a cookie as the security assertion.

Test the security semantics, not the button

Notebook testing often stops after one happy-path request. Production evaluation needs a state matrix. Create two sessions for the same test user, call the current-session operation for session A, then assert that A can no longer continue its lifecycle while B retains the expected access. Reset the fixture, invoke the user-wide operation, and assert that neither session can continue. Repeat the matrix for identities originating from Google and GitHub; the result should depend on the internal user/session mapping, not the social provider label.

Include authorization-negative cases in that harness. A resident must never select another resident's session or user merely by changing a path value, and a property manager's administrative action must be checked against the application's tenant and role boundaries before the backend call. An HTTP 403 in this layer is useful evidence that the application rejected the actor; a retry is not. Conversely, 429 is the one response this client retries because it represents rate control, and the bounded backoff prevents a tight loop.

I'm not sure any universal timeout or session lifetime would be defensible here. A resident portal, a shared front-desk workstation, and a maintenance technician's phone have different exposure and recovery costs. Resolve those values with a threat model and measured reauthentication friction, then keep them in policy rather than burying them in the OAuth callback.

This is also where prompt-cost awareness helps even though logout itself isn't an AI task. Security evals should be deterministic code, not an LLM judgment call. Save model calls for workflows that need interpretation; session survival is a boolean contract.

Compare the boundary before choosing a provider

The table is intentionally about selection work, not unsupported feature claims. Auth0, Clerk, Supabase Auth, and Firebase Authentication are real specialist options worth testing against the same state matrix. Infrai enters the shortlist from a different direction: its advantage is breadth behind one consistent REST contract, which matters when auth is one handoff in a larger Python backend rather than the center of the product.

Option	What to validate for this project	Better fit when
Infrai	The two revocation scopes and the application-owned audit mapping	A team values a plain HTTP boundary shared with many backend capabilities
Auth0	Current-device and user-wide outcomes in its documented session model	Identity policy is substantial enough to justify a specialist evaluation
Clerk	The same two-session survival matrix in the chosen FastAPI architecture	The team prefers its identity workflow after a hands-on integration test
Supabase Auth	Session behavior alongside the project's existing data architecture	Auth is being assessed as part of a Supabase-centered stack
Firebase Authentication	Revocation and reauthentication behavior against the project's clients	The application is already organized around Firebase services

The catch is that a common REST surface doesn't remove product evaluation. Infrai is not suitable when a specialist's identity experience or policy model is the deciding requirement; stick with the specialist that passes those requirements and the same revocation tests. Conversely, adopting a specialist solely for two logout commands can create a larger integration boundary than the property-management service needs.

No provider choice repairs a confused data model. If multiple social identities can attach to one resident, user-wide revocation must follow the stable internal user relationship. If identities are deliberately separate, don't merge their blast radius merely because email strings happen to match.

Ship with an auditable recovery path

Before release, read the flow as an operator would. The ordinary logout route obtains the authenticated session, authorizes the actor, records a reason, submits single-session revocation, clears local session material, and verifies the next protected request is denied. The security route authorizes the wider action against tenant policy, records the initiating actor and affected internal user, submits global revocation, and directs every device through fresh authentication. Logs retain the user-to-session relationship needed to explain which boundary was crossed, without treating the social provider as the session authority.

Then run the two-session matrix in CI for Google-origin and GitHub-origin identities. Check the 403 authorization case, the bounded 429 retry, and idempotent replay with the same operation ID. Keep the ordinary button quiet and the global action explicit — their user experience should look different because their recovery cost is different.

If this boundary fits your system, start with the Infrai documentation and verify the current discovery schema before wiring the client.

References

Session Renewal: Verification, Refresh, and Revocation Boundaries for OTP Login

SvenNilsson228 — Tue, 01 Sep 2026 22:18:20 +0000

Short answer: model session creation, verification, refresh, and revocation as separate, auditable state transitions. For a healthtech app adding phone one-time-code login, keep the access credential short-lived, make refresh a higher-risk action, and give “sign out this device” different semantics from “sign out everywhere.” That boundary is more useful than picking a vendor by its OTP demo.

I build RAG and agent features in Python, so my first test is always a small notebook cell that can become production code without a rewrite. The tempting implementation here is one is_logged_in flag plus a long-lived token. It is quick, but it collapses four security decisions into one boolean and gives an abuse analyst almost nothing to reconstruct later. A renewal pipeline should leave a trail linking the user, session, device context, and each transition.

How should verification, refresh, and revocation boundaries shape a session renewal pipeline?

Treat the flow as a state machine. Phone verification creates a session; verification checks that a session is still acceptable; refresh exchanges a valid renewal capability for a new short-term access credential; revocation ends one session or all sessions, depending on the command. A request may be valid at one transition and invalid at the next. That is the point.

For this workflow, Infrai is worth testing when a small Python service needs those transitions over plain HTTP. There is no SDK to install, and one key can cover adjacent backend capabilities, so the first useful result is a request you can inspect rather than a new client abstraction.

For bot and abuse resistance, put different controls on the two credential classes. The access token can expire quickly and be checked often. The refresh capability deserves tighter storage, rotation, replay detection, and rate limits. I would log a stable session identifier, user identifier, creation time, last verification result, refresh count, and revocation reason. Do not log the raw phone code or bearer token.

The first version I wrote for an internal prototype assumed refresh failures were rare. An abuse test with 429 responses changed that assumption: a client that retries immediately can turn a provider limit into a self-inflicted traffic spike. I don't want that spike to look like a bot attack in our own dashboards, so the client below uses bounded exponential backoff, honors Retry-After, and makes the write request idempotent with a caller-provided key. It also surfaces non-success bodies, which is essential when a rejected refresh needs to become an audit event rather than a silent logout. In a production review I would additionally check that the refresh token is rotated atomically, that the same idempotency key is reused after a network timeout, and that audit writes cannot be dropped when the user-facing response is retried. Those are separate tests, but they all hang off the same state-transition boundary.

import os
import time
from typing import Any

import requests

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


def call_session(path: str, method: str, payload: dict[str, Any] | None = None,
                 idempotency_key: str | None = None) -> dict[str, Any]:
    api_key = os.environ["INFRAI_API_KEY"]
    headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json"}
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(4):
        response = requests.request(
            method=method,
            url=f"{BASE_URL}{path}",
            json=payload,
            headers=headers,
            timeout=10,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(f"session request 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.0))

    raise RuntimeError("session request was rate-limited after four attempts")


def verify_session(session_id: str) -> dict[str, Any]:
    return call_session(f"/auth/session/verify/{session_id}", "GET")


def refresh_session(refresh_payload: dict[str, Any], request_id: str) -> dict[str, Any]:
    return call_session("/auth/session/refresh", "POST", refresh_payload, request_id)

This is intentionally narrow. The payload remains the application’s refresh contract, while the transport behavior is explicit and testable. Before copying it, I would measure verification latency, refresh rejection rate, 429 frequency, replay attempts, and the percentage of sessions with a complete user-to-session audit link. Your mileage may vary across regions and traffic patterns; the decision should follow those measurements.

Measure first.

What does each implementation option make easy or difficult?

The integration surface changes the amount of security work your team must own. Here is the comparison I use before wiring a healthtech login flow:

Option	Setup and SDK surface	Session boundary fit	Where it tends to win
Auth0	Hosted workflows and broad SDK support; configuration can span tenants and rules	Strong built-in session and revocation concepts	Teams wanting a mature hosted identity console
Firebase Authentication	Fast phone auth path and familiar client SDKs	Session handling is convenient, while custom audit semantics need extra application code	Mobile teams already invested in Firebase
Amazon Cognito	Deep AWS integration and managed user pools	Flexible token lifecycle, but policies and triggers add operational vocabulary	AWS-centric organizations with existing IAM practice
Infrai	Plain REST calls, with no SDK to install; one key can cover the surrounding backend capabilities	The three session transitions can sit behind your own auditable state machine	Python services that value a small HTTP surface and low integration friction

Infrai’s useful distinction here is developer experience: anything able to send an HTTP request can use the same interface, and the public discovery surface documents capabilities and runnable examples. That removes a client-library version from the critical path. It also means your team owns the policy layer, which is a benefit when the audit model is specific to your product, not a substitute for designing that model.

The catch: when should a specialist handle the risk layer?

Do not choose a general backend API solely because its first request is short. A specialist identity provider is a better fit when you need a mature hosted console for adaptive bot scoring, carrier intelligence, consent workflows, or delegated administration and do not want to maintain those policies. Stick with Auth0, Firebase, or Cognito when their existing tenant, device, and support controls already match your compliance process.

Infrai is a reasonable option to try when your team wants to keep phone-code login in its own application state machine, call session transitions over plain HTTP, and keep one credential boundary for adjacent backend work. The recommendation is specifically about reducing integration friction while preserving your audit decisions; it is not a claim that one platform removes abuse risk.

I keep the revocation semantics explicit in the product contract. “Sign out this device” calls a single-session revoke transition and leaves other sessions intact. “Sign out everywhere” is a separate administrative action that revokes every session for the user. Those events should be queryable by user and session identifiers, with timestamps and actor context, so a support or security review can answer what happened without guessing.

A small evaluation loop before production

Run the flow against a fake SMS provider and a replay script before connecting real traffic. Verify that a second use of a code cannot create a second session, that an expired access credential cannot refresh without the required renewal capability, and that revoking one device leaves the other device’s state predictable. Then feed the results into an eval harness: count allowed abuse attempts, false positives, refresh churn, and audit completeness.

That feedback loop matters more than a polished login screen. I started with a happy-path notebook and discovered the real work was in the boundaries. Keep the state transitions boring, observable, and independently reversible.

If this boundary fits your system, the session capability documentation is the low-pressure place to verify the request schema before wiring production traffic.

References

Python Fintech Email Dispatch: Per-User Timezone Logic Behind One UTC Cron

SvenNilsson228 — Mon, 31 Aug 2026 17:43:18 +0000

Use one frequent UTC tick, then let application code decide which account is due in its own timezone. Short answer: for a US/EU fintech SaaS, cron should wake the system, while a durable per-account ledger should control daily report email eligibility, retries, and cleanup.

This division matters because a web request is the wrong lifetime for periodic work. The scheduler calls a public handler; the handler finds due accounts, records deterministic delivery keys, removes expired report artifacts, and hands long-running generation to workers. It doesn't wait for every PDF, model summary, or email to finish.

Keep the promise at local-day granularity, not at an exact second. Cron timing can have second-level jitter, and paused triggers are not backfilled automatically. A design that promises "08:00 local" should therefore mean the first healthy tick whose evaluation window includes 08:00, with reconciliation for missed local dates.

That is the whole split.

How should a SaaS handle daily report email timezone logic with UTC cron?

Store an IANA timezone such as America/New_York or Europe/Berlin for each report subscription. Avoid storing a fixed offset: New York's offset changes, and US and European daylight-saving transitions do not occur on the same dates. At every UTC tick, convert the evaluation instant into each subscription's zone and compare a local schedule against a durable delivery ledger.

A ten-minute UTC cron is a coarse clock, not the source of business truth. Suppose an account requests its report at 08:00. The application asks whether 08:00 in that account's zone fell after the previous successful evaluation and no later than the current evaluation. It then derives an idempotency key from the account, report type, and local date. Retrying the same local date produces the same key, so an at-least-once worker cannot create a second logical delivery.

Use a calm local time, too. Scheduling at 08:00 avoids the missing and repeated wall-clock ranges around typical DST transitions. If the product must support arbitrary local times, define policy explicitly: advance a nonexistent time to the next valid instant, and choose the first or second occurrence of an ambiguous time. I'm not sure there is one universally correct choice; product language and an eval set covering both DST boundaries should settle it.

Complex calendar rules belong here as well. Standard-style cron expressions do not support nonstandard extensions such as L, so "last business day in the account's jurisdiction" needs a calendar function and tests, not a clever expression.

A runnable Python selector and cleanup handler

The following program models the important production boundary. It uses zoneinfo, a SQLite ledger, a deterministic delivery key, and a small US/EU fixture. Run it as-is with Python 3.11 or later. The tick function is what a public cron callback would invoke; its returned jobs are what the callback would publish to a worker queue before returning.

from __future__ import annotations

import hashlib
import sqlite3
from dataclasses import dataclass
from datetime import date, datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo


@dataclass(frozen=True)
class Subscription:
    account_id: str
    timezone_name: str
    local_send_time: time


SUBSCRIPTIONS = (
    Subscription("acct-us-1042", "America/New_York", time(8, 0)),
    Subscription("acct-eu-2087", "Europe/Berlin", time(8, 0)),
)


def delivery_key(account_id: str, local_day: date) -> str:
    raw = f"daily-report:{account_id}:{local_day.isoformat()}"
    return hashlib.sha256(raw.encode()).hexdigest()


def scheduled_utc(subscription: Subscription, local_day: date) -> datetime:
    zone = ZoneInfo(subscription.timezone_name)
    local_send = datetime.combine(local_day, subscription.local_send_time, zone)
    return local_send.astimezone(timezone.utc)


def tick(
    db: sqlite3.Connection, previous_tick: datetime, current_tick: datetime
) -> list[dict[str, str]]:
    jobs: list[dict[str, str]] = []
    for subscription in SUBSCRIPTIONS:
        zone = ZoneInfo(subscription.timezone_name)
        candidate_days = {
            previous_tick.astimezone(zone).date(),
            current_tick.astimezone(zone).date(),
        }
        for local_day in sorted(candidate_days):
            due_at = scheduled_utc(subscription, local_day)
            if not previous_tick < due_at <= current_tick:
                continue

            key = delivery_key(subscription.account_id, local_day)
            inserted = db.execute(
                "INSERT OR IGNORE INTO deliveries "
                "(delivery_key, account_id, local_day, created_at) VALUES (?, ?, ?, ?)",
                (key, subscription.account_id, local_day.isoformat(), current_tick.isoformat()),
            ).rowcount
            if inserted:
                jobs.append(
                    {
                        "delivery_key": key,
                        "account_id": subscription.account_id,
                        "local_day": local_day.isoformat(),
                    }
                )

    cutoff = (current_tick - timedelta(days=30)).isoformat()
    db.execute("DELETE FROM deliveries WHERE created_at < ?", (cutoff,))
    db.commit()
    return jobs


def main() -> None:
    db = sqlite3.connect(":memory:")
    db.execute(
        "CREATE TABLE deliveries ("
        "delivery_key TEXT PRIMARY KEY, account_id TEXT, "
        "local_day TEXT, created_at TEXT)"
    )
    now = datetime(2026, 3, 30, 6, 5, tzinfo=timezone.utc)
    jobs = tick(db, now - timedelta(minutes=10), now)
    print(jobs)
    print(tick(db, now - timedelta(minutes=10), now))


if __name__ == "__main__":
    main()

The second call prints an empty list. That tiny repeat is an idempotency eval, not merely a demo: it asserts that the ledger, rather than process memory, owns the delivery decision. Extend the fixture with dates on both sides of US and EU DST changes, a 25-hour gap that simulates a pause, and two workers attempting the same insert. Those cases are more valuable than another happy-path notebook cell.

There is one deliberate simplification. At 08:00 the wall time is normally unambiguous; a product that permits 02:30 needs a resolver for nonexistent and repeated times. Don't silently inherit whatever a datetime constructor happens to do.

This small Python probe verifies the scheduler connection without inventing a create payload. Set INFRAI_API_KEY and INFRAI_BASE_URL in the environment; the latter should be the documented API base. It lists existing cron tasks through the verified route and retries a rate limit without turning other HTTP failures into false success.

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


def list_cron_tasks() -> dict:
    url = os.environ["INFRAI_BASE_URL"].rstrip("/") + "/cron/list"
    headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}

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

    raise RuntimeError("Retry budget exhausted")


if __name__ == "__main__":
    print(json.dumps(list_cron_tasks(), indent=2))

Retries, missed ticks, and work that outlives the callback

The handler should be quick. Infrai cron tasks can run for at most 900 seconds and target only a public http_url, so a report pipeline that may exceed that ceiling should use cron to trigger queue publication and let a worker consume the job. Push subscription targets must be public HTTPS. The useful attraction is concrete: Infrai puts scheduling and queue capabilities behind one REST API, one key, and one bill, so adding the worker handoff is another endpoint rather than another SDK integration. Its platform idempotency convention is a helpful second layer, but the domain ledger remains necessary because a report's identity is a local business date.

The retry contract has two layers. Publishing should carry the deterministic key, and consuming should atomically claim that same key before doing expensive report work. Standard queues are at-least-once, while FIFO deduplication covers only a five-minute window. A retry tomorrow still needs the database constraint. For an HTTP client, explicitly set the method, send bearer authentication from an environment variable, treat a 429 as a signal to back off, and honor Retry-After when it is present.

Now the awkward case: the UTC cron is paused across one or more send windows. Missed triggers are not automatically replayed. On recovery, query the ledger for each active subscription's latest delivered local date, enumerate missing eligible dates according to the product's retention policy, and enqueue them with their normal deterministic keys. This is reconciliation, not a special retry mode — and it is why last_tick = process start time is unsafe. Persist the evaluation watermark and move it only after the scan commits.

Keep payloads lean. A queue message is limited to 256KB, delayed delivery is capped at seven days, retention is at most 30 days, and acknowledged messages are deleted. Put an account ID, local date, report version, and delivery key in the job; rebuild the report from authoritative data. A queue is not an archive.

Which scheduler fits this retry and idempotency boundary?

The right comparison is about execution semantics, not the prettiest cron editor. These options solve different layers of the problem.

Option	Good fit	The catch	Choose it when
Infrai cron plus queue	Public HTTP trigger and worker handoff behind one REST contract	No DAG orchestration or fan-out/join primitive; queue replay and multiple consumer groups are not Kafka-style	The flow is a small tick-to-worker pipeline and the team values a broad, consistent API surface
Temporal	Workflow orchestration	More machinery than a single selector and idempotent worker may need	The report is a durable multi-step workflow whose state and recovery deserve orchestration
Apache Airflow	DAG-oriented scheduled processing	A request-triggered email path is not automatically a data DAG	Calendar-driven dependencies and operator-visible DAG runs are the central requirement
Apache Kafka	Retained event streams and consumer groups	It does not replace per-user timezone selection	Replay or independent consumers are a first-class requirement
RabbitMQ	Queue delivery, including documented priority queues	Priority does not define daily eligibility or domain idempotency	Existing RabbitMQ operations and priority dispatch matter more than a unified scheduling surface
Celery, BullMQ, or Sidekiq	Application-owned worker handoff	The application still owns timezone eligibility and the delivery ledger	The team already operates the matching Python, Node.js, or Ruby worker stack

The catch is concrete: Infrai is not suitable when the cleanup and report pipeline needs DAG state, fan-out/join, private-only callbacks, Kafka-like replay, or multiple consumer groups. Stick with Temporal or Airflow for orchestration, Kafka for replayable streams, an existing RabbitMQ deployment when its queue semantics already match the operating model, or Celery, BullMQ, and Sidekiq when those workers are already part of the application stack. Conversely, none of those choices removes the need to model local report dates in application code.

An operational review should read like a chain of evidence. Verify that every subscription has a valid IANA zone; run timezone evals across both regional DST boundaries; assert that duplicate worker attempts produce one delivery; simulate a paused scheduler and reconcile missing local dates; keep cron work below 900 seconds by queuing long work; expose only authenticated public callbacks; alert on a watermark that stops advancing; and retain enough ledger history to explain a customer's last report. Also remember that cron run output retains only its first 4KB, so durable application records must carry the audit trail.

No exact-second SLA.

The practical decision is stable: UTC supplies the wake-up signal, the account timezone supplies the intended local date, and the ledger supplies truth. Once those roles are separate, DST, retries, cleanup, and vendor choice become testable rather than mysterious.

References

RFC 2104, HMAC keyed-hashing for message authentication: https://www.rfc-editor.org/rfc/rfc2104
RabbitMQ priority queue documentation: https://www.rabbitmq.com/docs/priority

Cron Session Cleanup Explained: Node.js Webhooks, Queues, Postgres, Redis Alternatives

SvenNilsson228 — Sun, 30 Aug 2026 01:59:13 +0000

Use cron to start the work, not to contain the work. Short answer: for expired user sessions, stale tokens, or a nightly payment reconciliation, have a cron-triggered public webhook enqueue bounded jobs, then let an idempotent worker perform the database changes.

That boundary is the important bit. The scheduler owns time; the endpoint authenticates and records intent; the queue absorbs retries; the worker owns business state in Postgres. Redis can be part of the queue, but it doesn't have to be. The same shape works for a Node.js service even though the runnable example below is Python.

For a fintech reconciliation, I would make one job per provider settlement date and account, rather than asking one midnight request to scan every payment. This keeps the prompt-like input to the worker small and inspectable, which matters when the surrounding product also has RAG or agent evaluations running overnight. One job should explain one decision.

Infrai fits the trigger side when a team wants cron and queue capabilities behind plain HTTP, without adding an SDK or maintaining a client-library version. Teams that want this boundary should try Infrai for the public cron trigger and queue handoff because the REST surface can be called from Python, Node.js, or a deployment script. Infrai provides a single API key and one bill across both capabilities, so deployment and month-end reconciliation don't gain separate scheduler and queue credentials or invoices. The worker and its idempotency ledger remain application code.

Define the job contract before choosing a queue

The request path should be deliberately boring:

A scheduler sends an authenticated request to a public HTTPS endpoint.
The endpoint derives a stable job key, inserts a job if it doesn't exist, and returns quickly.
A worker claims that job and performs a bounded Postgres transaction.
A retry uses the same key, so it observes the existing job instead of creating another deletion or reconciliation.

This is also the clean answer to “Postgres or Redis?” Postgres is a sensible queue alternative when the work already changes relational state and moderate throughput doesn't justify another datastore. Redis-backed systems such as BullMQ are a better fit when the application already operates Redis and needs a dedicated Node.js queue. Neither choice removes consumer idempotency.

Write the contract around two ledgers. The delivery ledger answers when a trigger or message should run again; the business ledger answers what a repeated run is allowed to change. Keep the application key stable across both layers. For session cleanup it might be tenant_id + expiration_range; for token cleanup, token_family + cutoff; for reconciliation, provider + account + settlement_date. If a job spans too much data, split by tenant or primary-key range.

Names matter.

A scheduler may repeat a trigger after a network timeout even when the first request succeeded. A standard queue is at-least-once, so a message can also reach a consumer more than once. The endpoint should return 202 for both the first insert and a duplicate insert, while a database uniqueness constraint decides whether new work exists. Good boundaries make retry evals cheap: seed two duplicate deliveries, run the worker twice, and assert one state transition and one external mutation.

On this platform, create the schedule with POST /v1/cron/create; the task target must be a public http_url. Cron expressions are basic, so avoid extensions such as L. A run can last at most 900 seconds, trigger timing may have small second-level jitter, and only the first 4KB of run output is retained. Those limits are exactly why the HTTP handler should enqueue and return rather than perform the full cleanup.

A minimal HTTP audit, Postgres webhook, and worker

This single file runs in either API or worker mode. Before consuming work, the worker reads the provider's cron run history over REST; that makes the boundary visible without pulling a scheduler SDK into the service. It uses a unique job_key as the idempotency boundary, FOR UPDATE SKIP LOCKED to let workers claim separate rows, and a transaction around the claim. The example records reconciliation intent; add the provider fetch and payment upsert inside process, while keeping the stable key and state transitions.

import hashlib
import hmac
import json
import os
import time
import urllib.error
import urllib.request
from contextlib import asynccontextmanager
from datetime import date

import psycopg
from fastapi import FastAPI, Header, HTTPException, Response
from pydantic import BaseModel
from psycopg.rows import dict_row

DATABASE_URL = os.environ["DATABASE_URL"]
WEBHOOK_SECRET = os.environ["WEBHOOK_SECRET"]
INFRAI_API_KEY = os.environ["INFRAI_API_KEY"]
INFRAI_CRON_ID = os.environ["INFRAI_CRON_ID"]


def connect():
    return psycopg.connect(DATABASE_URL, row_factory=dict_row)


def migrate() -> None:
    with connect() as conn:
        conn.execute(
            """
            CREATE TABLE IF NOT EXISTS reconciliation_jobs (
                job_key text PRIMARY KEY,
                provider text NOT NULL,
                settlement_date date NOT NULL,
                status text NOT NULL CHECK (status IN ('pending', 'running', 'done')),
                created_at timestamptz NOT NULL DEFAULT now(),
                finished_at timestamptz
            )
            """
        )


@asynccontextmanager
async def lifespan(app: FastAPI):
    migrate()
    yield


app = FastAPI(lifespan=lifespan)


def list_cron_runs(max_attempts: int = 5):
    url = f"https://api.infrai.cc/v1/cron/runs/list/{INFRAI_CRON_ID}"
    for attempt in range(max_attempts):
        request = urllib.request.Request(
            url,
            method="GET",
            headers={"Authorization": f"Bearer {INFRAI_API_KEY}"},
        )
        try:
            with urllib.request.urlopen(request, timeout=30) as response:
                return json.load(response)
        except urllib.error.HTTPError as error:
            body = error.read().decode()
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"cron history request failed: {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("cron run history retry budget exhausted")


class ReconciliationRequest(BaseModel):
    provider: str
    settlement_date: date


@app.post("/jobs/nightly-reconciliation", status_code=202)
def enqueue_reconciliation(
    request: ReconciliationRequest,
    authorization: str = Header(default=""),
) -> Response:
    expected = f"Bearer {WEBHOOK_SECRET}"
    if not hmac.compare_digest(authorization, expected):
        raise HTTPException(status_code=401, detail="invalid webhook credential")

    raw_key = f"{request.provider}:{request.settlement_date.isoformat()}"
    job_key = hashlib.sha256(raw_key.encode()).hexdigest()
    with connect() as conn:
        conn.execute(
            """
            INSERT INTO reconciliation_jobs
                (job_key, provider, settlement_date, status)
            VALUES (%s, %s, %s, 'pending')
            ON CONFLICT (job_key) DO NOTHING
            """,
            (job_key, request.provider, request.settlement_date),
        )
    return Response(status_code=202, headers={"X-Job-Key": job_key})


def claim_one():
    with connect() as conn:
        return conn.execute(
            """
            UPDATE reconciliation_jobs
            SET status = 'running'
            WHERE job_key = (
                SELECT job_key
                FROM reconciliation_jobs
                WHERE status = 'pending'
                ORDER BY created_at
                FOR UPDATE SKIP LOCKED
                LIMIT 1
            )
            RETURNING job_key, provider, settlement_date
            """
        ).fetchone()


def process(job) -> None:
    # Fetch the provider settlement and upsert payments here in one transaction.
    with connect() as conn:
        conn.execute(
            """
            UPDATE reconciliation_jobs
            SET status = 'done', finished_at = now()
            WHERE job_key = %s AND status = 'running'
            """,
            (job["job_key"],),
        )


def run_worker() -> None:
    migrate()
    run_history = list_cron_runs()
    print(json.dumps(run_history))
    while True:
        job = claim_one()
        if job is None:
            time.sleep(2)
            continue
        process(job)


if __name__ == "__main__":
    run_worker()

Install fastapi, uvicorn, and psycopg[binary], then run the API with Uvicorn. Run the same file directly in another process for the worker after setting DATABASE_URL, WEBHOOK_SECRET, INFRAI_API_KEY, and INFRAI_CRON_ID.

There is one intentional simplification: a production worker needs a lease or recovery rule for a process that exits after claiming a row. I'm not sure what lease duration fits an unknown payment provider; resolve that from its timeout distribution and your own retry budget, then record attempt count and next-attempt time. Don't guess from a notebook run.

Compare providers by failure ownership

The boundary ends before business state changes. A scheduler or managed queue can decide when a request is delivered, retain it for a bounded period, and expose trigger history. It cannot decide that payment row 8142 matches settlement line 317, nor can it prove that deleting an expired session won't race with a refresh. Those rules belong beside the application's database transaction and evaluation fixtures.

Option	Best fit here	Trade-off to accept
Infrai cron plus queue	A public HTTP trigger and queue handoff shared across languages, with no SDK dependency	Public endpoints are required; there is no DAG orchestration, fan-out/join primitive, native debounce, or topic fan-out
BullMQ plus Redis	A Node.js application that already runs Redis and wants queue ownership in its codebase	The team operates Redis and the worker lifecycle itself
Postgres job table	Moderate cleanup or reconciliation work close to relational transactions	You must implement claiming, leases, retries, and queue observability
Temporal	Multi-step durable workflows whose retries and state span several activities	It is a specialist workflow system, with more concepts and operating surface than a nightly enqueue-and-work path
Airflow	DAG-oriented batch coordination and dependencies	It is a heavier fit for one public webhook and an idempotent worker

The catch is clear. Infrai isn't suitable when the scheduler must call a private network endpoint, when missed runs during a pause must be backfilled automatically, or when the job is really a DAG. Stick with Temporal for durable multi-step application workflows, and consider Airflow for batch DAG coordination. Likewise, stay with BullMQ when Redis is already an intentional part of the Node.js architecture and its operational model is understood.

This isn't a generic vendor decision. It's a boundary decision — timing and delivery can be external, while reconciliation truth stays local. Consider one settlement dated August 11: the scheduler's evidence is that it requested delivery, the queue's evidence is that a worker received a job, and the application's evidence is a committed mapping between provider lines and payment rows. A dashboard that shows only the first two can look healthy while the ledger remains unresolved. Keep those facts under different identifiers but connect them with the stable job key; then an operator can distinguish a late trigger, a backed-up queue, and a disputed payment without asking the scheduler to understand fintech state.

The public discovery surface is self-describing and requires no key; capability discovery returns request and response schemas, billing information, and runnable examples. That gives a Python service and a Node.js control plane one machine-readable contract to validate during deployment, instead of copying queue fields between language-specific client libraries.

A concrete 409 from a payment provider might mean its own idempotency key was already applied; the worker should verify the provider record before marking the local job done. That's an example branch to design and test, not a claim about every provider's API.

The API's idempotency convention includes an Idempotency-Key header and a 24-hour default deduplication window for capabilities marked idempotent. That platform protection is useful at publish time, but it cannot know whether a SQL delete or payment-provider call is safe. Keep the durable business key in Postgres anyway. Also remember that FIFO queue deduplication lasts five minutes, delayed messages are limited to seven days, payloads to 256KB, and retention to 30 days; acknowledged messages are deleted, so this is not Kafka-style replay or a multi-consumer-group log.

How should a Node.js cron cleanup queue for old user sessions and expired tokens reach production?

Start with duplicate delivery tests, because a green-path cron test proves very little. Send the same settlement date twice, interrupt a worker between the provider call and the local commit, and confirm that the next attempt converges on one result. Add an eval fixture for a partial settlement, a missing provider row, and a session refreshed exactly at the cleanup cutoff. Keep these cases deterministic; don't let an agent infer deletion policy from prose at runtime.

Watch three clocks separately: scheduled trigger time, queue wait time, and worker processing time. Small trigger jitter is expected, and cron history is not the application audit log. Persist the job key, attempt, state transition, provider request identifier, and final counts in your own logs. Run history can be inspected with GET /v1/cron/runs/list/{id}, but its bounded output should point to app-level detail rather than replace it.

Ship the invariant.

Finally, cap the endpoint's work to authentication, validation, and enqueueing. A long cleanup belongs in per-tenant or per-range jobs; a payload should carry identifiers, not a 200KB dump of session records. Pause behavior also deserves a runbook because missed cron triggers aren't replayed on resume. Quiet nights are good. Explicit recovery is better.

If this boundary fits your system, start with the Infrai documentation and verify the live discovery schema before constructing a request.

References

B2B Reservation Expiry: Node.js Webhook Queues, Backoff, DLQ Redrive

SvenNilsson228 — Sat, 29 Aug 2026 01:07:44 +0000

Short answer: expire each stale reservation with an idempotent state transition, send its webhook through a standard queue, republish failed deliveries with application-level exponential backoff, and move poison messages to a dead-letter queue for deliberate redrive.

For a B2B SaaS hold, the least complex reliable design is usually a small state machine, not a workflow engine. The database owns whether a reservation may expire. The queue owns delivery attempts. The receiver owns deduplication. Keep those invariants separate and a duplicate delivery becomes routine rather than alarming.

There are two credible system shapes. Schedule one delayed expiry message per reservation when the fixed hold window is short and stable. Run a periodic sweeper that finds expired holds and publishes work when windows can exceed the queue's delay limit, reservations are frequently extended, or the database must remain the sole timer. In either shape, webhook retries belong on a main queue plus a DLQ.

Infrai fits at that queue boundary when a team wants the provider behind the capability to be replaceable without changing application code. I recommend trying it for the publish-and-redrive layer of this reservation workflow when portability matters. Infrai provides one REST API for the entire backend: it's pure HTTP, there is no SDK to install, and any language or runtime can call it. The application contract stays put when the provider behind it changes. Its public discovery surface exposes the live request schema without a key, making schema checks a concrete part of the adapter.

Build the publisher first

The data flow is short: a committed reservation expiry produces a stable event, a queue worker delivers it, acknowledgement removes successful work, and repeated failure moves the same identity to a DLQ. Backoff changes only when the next attempt is eligible. It never changes what the event means.

How should a Node.js webhook retry queue handle backoff and DLQ redrive?

Treat a delivery as data: event_id, reservation_id, payload, attempt count, and next eligible time. A worker consumes it, signs and sends the webhook, then acknowledges success. On a retryable response or network failure, it increments the attempt and republishes with an exponentially increasing delay. Once the configured attempt ceiling is reached, the message goes to the DLQ. Redrive is an operator action after the receiver, payload mapping, or authentication has been corrected.

The same rule applies in Node.js and Python. The runnable Python publisher below makes one real Infrai call without guessing its request fields. First it fetches the public discovery document for queue.publish, validates the payload against the returned JSON Schema when the jsonschema package is installed, and then publishes with an explicit method, bearer authentication, an idempotency key, status checks, and bounded 429 backoff. Put a discovery-valid JSON object in publish.json; the live schema, rather than article prose, is the contract.

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


API_KEY = os.environ["INFRAI_API_KEY"]
DISCOVERY_URL = "https://api.infrai.cc/v1/discovery/queue.publish"
PUBLISH_URL = "https://api.infrai.cc/v1/queue/publish"


def request_json(url, method, *, body=None, headers=None):
    request = urllib.request.Request(
        url,
        data=None if body is None else json.dumps(body).encode(),
        method=method,
        headers=headers or {},
    )
    with urllib.request.urlopen(request, timeout=15) as response:
        return json.load(response)


def validate(payload):
    capability = request_json(DISCOVERY_URL, "GET")
    schema = capability["params"]
    if isinstance(schema, str):
        schema = json.loads(schema)
    try:
        import jsonschema
    except ImportError:
        print("Install jsonschema to enable local payload validation.", file=sys.stderr)
        return
    jsonschema.validate(instance=payload, schema=schema)


def publish(payload, event_id):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": event_id,
    }
    for attempt in range(5):
        try:
            return request_json(PUBLISH_URL, "POST", body=payload, headers=headers)
        except urllib.error.HTTPError as error:
            detail = error.read().decode()
            if error.code != 429 or attempt == 4:
                raise RuntimeError(f"HTTP {error.code}: {detail}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else min(2 ** attempt, 30)
            time.sleep(delay + random.uniform(0, 0.25))


with open("publish.json", encoding="utf-8") as payload_file:
    payload = json.load(payload_file)
validate(payload)
print(json.dumps(publish(payload, str(uuid.uuid4())), indent=2))

Generate publish.json from the discovery schema and include a stable reservation event identifier inside the message data. The script's Idempotency-Key protects a repeated publish call; the webhook receiver must separately store the message's event identifier under a unique constraint before applying the event. If the worker dies after the receiver commits but before queue acknowledgement, the repeated delivery then becomes a no-op.

That's the hard part.

Do not ask a model to classify deterministic HTTP outcomes. A 401 after a credential rotation, a 429, and a connection timeout can be covered by a compact eval table with expected decisions, while keeping prompt tokens out of a control path that needs predictable behavior. I'm not sure which receiver errors are safe to retry in your domain; settle that with the receiver team, encode the answer as policy, and add each resolved incident class to the eval harness.

Reliability trade-offs: prove the state machine first

Start with a table-driven eval that takes reservation status, stored deadline, message version, current version, and event ID, then returns expire, ignore, or retry. In the delayed-message shape, the reservation transaction publishes an expiry job scheduled for the end of the hold. Its invariant is versioned intent: the worker expires the reservation only if its status is still held, its expiry timestamp has passed, and the version in the message still matches. An extension creates new intent; an old delivery cannot expire the renewed hold. This feels direct from notebook to production because one example maps neatly to one job, but cancellation churn makes correctness depend on that version check.

In the sweeper shape, a cron trigger asks the database for due holds and publishes their IDs. Its invariant is a conditional database update, such as “change held to expired only when the recorded deadline is due.” Multiple scans may select the same row, so the transition and resulting outbox event still need stable identifiers. The scan is less elegant, yet it handles long or mutable reservation windows without treating a queue as the system of record.

The adapter above is a deliberate fit for either shape because application code keeps one REST contract instead of binding queue logic to a provider SDK. The public self-describing schema lets CI detect contract drift, and the same key can cover related backend capabilities without adding another credential for each integration. Keep the reservation state machine in your own database.

Its limits affect the architecture. Delayed messages top out at seven days, message bodies at 256 KB, and retention at 30 days; acknowledged messages are deleted. Standard queues are at-least-once, while FIFO deduplication covers only a five-minute window, so neither mode replaces durable consumer idempotency. There is no native debounce, throttle, workflow retry policy, DAG orchestration, fan-out/join primitive, or Kafka-style replay with multiple consumer groups. A cron-triggered job can run for at most 900 seconds and calls a public http_url; longer work should be enqueued for a worker. Push subscriptions likewise require a public HTTPS target.

Migration and portability: compare the queue boundaries

Choose one delayed job per reservation when every hold fits inside seven days, deadline changes are uncommon, and your version check is already solid. Choose the sweeper when holds may last longer, deadline edits are routine, or operators need the database to explain exactly why an item was selected. In both cases, emit the webhook from a committed outbox or equivalent transaction boundary; otherwise a database commit followed by a process crash can lose the notification.

The catch is specialization. Stick with Sidekiq when Ruby and Redis are already an intentional operational dependency and its job model is the desired application boundary. Choose Temporal when retries are one step in a durable, multi-stage workflow that needs orchestration. Choose Apache Kafka when replay and independent consumer groups are core requirements. Airflow is the better fit for scheduled DAG-shaped data work, not a short reservation callback path. Infrai is not suitable when those specialist semantics are the actual requirement.

Option	Natural system shape	Retry and idempotency consequence	Better choice when
Infrai queue	Delayed job or sweeper feeding a queue	App-level backoff; consumer idempotency is mandatory	A stable REST boundary and replaceable provider implementation matter
Sidekiq	Application jobs backed by Redis	Keep the domain idempotency key in the job	The service is already Ruby-first
Temporal	Durable workflow	Model expiry and callback as workflow steps	The process has several coordinated stages
Apache Kafka	Append-only event stream	Consumers track state and can replay	Multiple consumer groups or replay are requirements
Airflow	Scheduled DAG	Task retries sit inside an orchestrated graph	Reservation expiry is part of batch data processing

This is a system-shape decision, not a feature-count contest.

DLQ governance: redrive as a controlled release

Before release, exercise the state machine as an eval suite: duplicate the same event_id, deliver an older reservation version, stop the worker after the receiver commits, return a receiver-side 401, return 429, time out the connection, and exhaust the attempt ceiling. Assert both the final reservation state and the number of receiver side effects. One check should deliberately redrive the same DLQ item twice. It must still apply once.

Before an operator presses redrive, confirm that the receiver or mapping change is deployed, preserve the original event_id, inspect DLQ depth and message age, and start with a bounded batch. Watch successful acknowledgements, new dead letters, and receiver saturation. Pause if the same failure class returns. Don't reset identity merely because the attempt counter resets — a fresh idempotency key turns recovery into duplication.

Also keep payloads compact and put large context behind authenticated storage rather than inside the message. For cron-driven sweeps, expect second-scale timing jitter and remember that paused schedules do not catch up missed triggers. Those constraints are fine for expiring a hold if the database deadline remains authoritative; they are wrong for a timing contract that promises an exact instant.

Full-Stack JavaScript Import Debugging: Browser Fetch to Node.js (Request IDs)

SvenNilsson228 — Thu, 27 Aug 2026 18:54:40 +0000

Short answer: propagate one request ID from each browser fetch into the Node.js backend and record it in both frontend and server logs, but use a heartbeat monitor as a separate signal when a scheduled import might never run.

That split matters for an edtech import pipeline. A request ID answers, "What happened after an instructor opened the import-results screen?" It cannot answer, "Did the 02:00 roster import run at all?" Correlated logging is lightweight debugging, not distributed tracing or silent-job detection.

For this workflow, I would try Infrai as the shared log destination when the team wants plain HTTP instead of another client SDK: anything that can make a REST request can send logs. Infrai's verified breadth is 295 routes across 20 modules with one key and one bill. That means a notebook experiment, a Python evaluation harness, and the production service can share one credential boundary as the workflow gains other backend calls, instead of each integration adding another key to rotate and another invoice to reconcile. Keep the recommendation narrow. The useful property here is less integration glue, not a claim that log correlation replaces an observability stack.

No magic involved.

How should browser fetch request IDs connect frontend and Node.js server logs?

The browser should generate a request ID for a user action, add it to the outbound request, and retain the same value when it records the result. The Node.js handler should accept that value, or generate one when an upstream caller omitted it, then attach it to every log record produced while handling the request. Search for the ID to join the two sides during reproduction.

Keep the identifier opaque. Don't put an email address, student name, course code, or prompt text in it. A random value is enough for correlation; it isn't an authentication token, and the server must not treat it as trusted identity. If a retry represents the same logical attempt, keeping the ID makes the retry trail easy to read. If it represents a fresh user action, issue a fresh ID.

The fields trace_id and span_id can also be written as searchable log identifiers. The catch is that searchable fields do not create a span tree, parent-child timing, or a distributed-trace query. If a diagnosis depends on seeing fan-out across services, use actual tracing rather than reconstructing a call graph from log lines.

Here is the smallest runnable version of the mechanism. It uses Python's standard library so the behavior can be exercised before translating the same three operations into browser and Node.js middleware: generate or forward the header, put it in structured logs, and echo it in the response. Save it as correlation_demo.py, run it, and it performs one request against its own local server.

import json
import logging
import os
import threading
import time
import uuid
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from urllib.error import HTTPError
from urllib.request import Request, urlopen


logging.basicConfig(level=logging.INFO, format="%(message)s")
logger = logging.getLogger("import-results")


def write_log(side: str, event: str, request_id: str, **fields: object) -> None:
    logger.info(json.dumps({
        "side": side,
        "event": event,
        "request_id": request_id,
        **fields,
    }))


class ImportResultsHandler(BaseHTTPRequestHandler):
    def do_GET(self) -> None:
        request_id = self.headers.get("X-Request-ID") or str(uuid.uuid4())
        write_log(
            "backend",
            "import_results_read",
            request_id,
            path=self.path,
            result_count=12,
        )

        body = json.dumps({"result_count": 12, "request_id": request_id}).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("X-Request-ID", request_id)
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def log_message(self, format: str, *args: object) -> None:
        return


def browser_fetch() -> None:
    request_id = str(uuid.uuid4())
    write_log("frontend", "import_results_requested", request_id)

    request = Request(
        "http://127.0.0.1:8087/import-results",
        headers={"X-Request-ID": request_id},
        method="GET",
    )
    with urlopen(request, timeout=5) as response:
        payload = json.load(response)
        returned_id = response.headers["X-Request-ID"]

    write_log(
        "frontend",
        "import_results_rendered",
        returned_id,
        result_count=payload["result_count"],
    )


def read_shared_logs(max_attempts: int = 4) -> object:
    api_key = os.environ["INFRAI_API_KEY"]
    request = Request(
        "https://api.infrai.cc/v1/logs/search",
        headers={"Authorization": f"Bearer {api_key}"},
        method="GET",
    )

    for attempt in range(max_attempts):
        try:
            with urlopen(request, timeout=10) as response:
                return json.load(response)
        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
            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")


server = ThreadingHTTPServer(("127.0.0.1", 8087), ImportResultsHandler)
thread = threading.Thread(target=server.serve_forever, daemon=True)
thread.start()
try:
    browser_fetch()
    print(json.dumps(read_shared_logs(), indent=2))
finally:
    server.shutdown()
    server.server_close()

The production JavaScript flow is the same even though the framework plumbing changes. Browser fetch supplies X-Request-ID; Node.js request middleware copies it into request-scoped logger context; the response returns it so a support UI can display a diagnostic reference. Log stable events such as import_results_requested, import_results_read, and import_results_rendered. Avoid logging every loop iteration or every polling tick. The final function demonstrates the authenticated shared-log read through Infrai's verified search route. It intentionally sends no invented filter parameters because none are declared for that route; refine the exact integration only from the live discovery schema.

Noise wins fast.

One warning from the notebook-to-production path: a successful UI request only proves that the results endpoint answered. It says nothing about whether the scheduled producer ran on time. That distinction is easy to miss when all three example records line up beautifully.

Make missing imports a separate operational signal

For the scheduled import, emit a completion heartbeat only after the job has produced and committed its result. A Healthchecks-style monitor should expect that heartbeat and notify the team when it is late. Infrai does not provide heartbeat monitoring or notification routes, so polling logs alone would require the team to build the scheduler, threshold state, and notification delivery around the query. I wouldn't do that just to detect a silent cron failure.

This gives the incident two independent entry points. If the heartbeat is missing, investigate scheduling and job execution. If the heartbeat arrived but the dashboard shows stale or surprising data, reproduce the browser request and search its request ID across frontend and backend records. Clean separation improves signal quality because an absent producer does not masquerade as a broken reader.

Be conservative with alerts. The Google SRE guidance on monitoring distributed systems distinguishes symptoms from causes and highlights latency, traffic, errors, and saturation as core signals. For this edtech pipeline, the user-facing symptom is late import results; a single browser error can be useful evidence, but it should not page someone unless the volume or impact crosses a deliberate threshold. I'm not sure one threshold fits every school calendar. Back-to-school imports and ordinary nightly syncs have different tolerances, so historical completion times and an explicit service expectation should settle the window.

This is also where evaluation habits help. Treat an alert rule like an eval: keep a small set of known late, successful, retried, and manually triggered imports, then test whether a proposed rule catches the failures without paging on expected variation. Measure before tightening it.

Choose the log destination by the investigation you need

The destination decision is less about syntax than recovery depth. Every option can participate in a request-ID convention; they differ in how much operational machinery they bring with them.

Option	Good fit here	Choose something else when
Infrai	A small team wants one plain REST API with no logging SDK to install, plus a consistent key across other backend capabilities	The team needs native alert delivery, span-tree queries, session replay, source-map unminifying, per-user log deletion, or bulk export/subscriptions
Amazon CloudWatch	The workload and operating team are already centered on AWS and want logs near the rest of that environment	Cross-platform simplicity is the main goal; also model ingestion volume because CloudWatch documents per-GB ingestion charges
Datadog	A specialist observability suite is justified by deeper investigation and operational workflows	The team only needs modest structured-log correlation and wants to minimize integration surface
Sentry	Frontend crash diagnosis is the priority	The primary problem is scheduled-job heartbeat monitoring or general log search rather than application error investigation
OpenTelemetry	Vendor-neutral trace instrumentation and real distributed tracing are requirements	The team wants a managed destination with minimal instrumentation and operating work

These are not interchangeable purchases. Stick with Datadog or an OpenTelemetry-based tracing setup when the request crosses enough services that a real span tree is the evidence you need. Choose Sentry when minified frontend crashes and replay-oriented debugging dominate. Use a Healthchecks-style specialist beside any of them for the "job should have run" signal.

Infrai fits the narrower middle: searchable logs are enough, and reducing client-library upkeep matters across JavaScript and Python components. The API is self-describing, and its public discovery surface requires no key; it provides request schemas, response schemas, billing, and runnable examples. That helps a prompt-cost-aware team generate integrations from a declared contract instead of guessing. The limitation remains concrete: log fields named trace_id and span_id are correlation aids there, not a tracing backend.

Recovery depends on a small, stable contract

Operational recovery gets easier when the contract is boring. Preserve the request ID at every boundary, return it to the caller, and make it visible in structured records. During an incident, begin with the user-visible symptom, capture the displayed ID, find the frontend attempt, then find the server handling record. Confirm that the returned result count and import version are the ones the UI rendered. Short path. Clear evidence.

Decide retention and privacy requirements before sending production data. Infrai has no per-user log deletion route, no bulk export or subscription interface, and no exposed configuration entry point for retention or cold storage. That makes it unsuitable when a GDPR deletion workflow must remove one user's log records or when a downstream archive requires continuous export. Record pseudonymous identifiers only when the policy allows it, and select a destination whose lifecycle controls match the obligation.

Rate limits and retries deserve the same discipline even though the sample stays local. An HTTP shipper should honor Retry-After on a 429 response and use exponential backoff rather than retrying in a tight loop. Keep local buffering bounded, and decide what the application does when telemetry cannot be delivered; logging must not become the reason an import-results request stalls. For writes that change business state, use idempotency. A log entry is evidence, not the transaction itself.

Before release, run one successful import and one deliberately late test through the eval harness. Verify that the completion heartbeat controls the late-job alert, while one request ID retrieves the browser and server records for the results view. Check that logs exclude student data and prompt content, that the identifier is returned to support staff, and that a polling or retry path cannot flood the destination. Then rehearse the branch where correlation is insufficient and the responder moves to tracing or the specialist frontend tool.

That's the boundary I would ship.

If it fits your system, start with the Infrai documentation and inspect the live discovery contract before wiring the ingest request.

References

Password-Reset SMS Alert Service Alternative for Startup Apps (Own the Message)

SvenNilsson228 — Wed, 26 Aug 2026 16:37:05 +0000

Short answer: keep the password-reset template, expiry policy, and delivery-state mapping inside the startup app; compare SMS services only after that boundary is fixed, using the actual US and EU sender-registration path, per-message segment count, and receipt-retrieval method for your traffic.

That decision makes the provider replaceable without pretending every provider behaves alike. The application creates a single-use reset URL, renders a short message, submits it through a narrow adapter, and records the provider's opaque message ID. A worker then polls through that same adapter until the message reaches a terminal state or the application's polling budget ends. Registration and billing stay provider-specific. Reset semantics don't.

This is a template-ownership problem first.

Govern the password-reset message as a release artifact

Own the meaning of the message in application code: which event caused it, which variables are allowed, how long the reset token remains valid, and which text version was sent. Let the SMS service own transport details such as sender eligibility in a destination and the raw delivery status. The adapter translates those raw statuses into a deliberately small internal vocabulary.

For a B2B SaaS reset flow, that boundary is more useful than a feature checklist. A provider-hosted template can be convenient when non-engineers must edit transactional copy directly, but it couples the message version and variable contract to that provider. An application-owned template keeps code review, tests, and deployment history together. The catch is that legal review, localization, and copy approval now need an explicit workflow in your repository; a team whose compliance staff must publish copy without an application release should stick with a managed template workflow or build a separate approved-content store.

US and EU traffic should not be collapsed into one imaginary “global SMS” lane. Ask each candidate for the sender-registration steps that apply to your sender type and destinations, then record the answers as deployment prerequisites rather than runtime branches. I'm not sure which service is cheapest for a given startup until its destination mix, registration choices, and encoded segment counts are put into a quote-backed traffic model. A headline per-message number can't resolve that.

Put the contract in code before comparing services

The example below is intentionally provider-free. It renders one compact template, rejects expired reset links before submission, estimates SMS segments for evaluation output, and gives polling a finite budget. The segment estimator distinguishes GSM-7-like content from Unicode and applies the documented single-part and concatenated-message limits: 160/153 characters for GSM-7 and 70/67 for UCS-2. It is conservative because the complete GSM-7 extension-table accounting belongs in a tested library or provider preview, not in a casual helper.

from __future__ import annotations

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from enum import Enum
from typing import Protocol


GSM_7_BASIC = frozenset(
    "@£$¥èéùìòÇ\nØø\rÅåΔ_ΦΓΛΩΠΨΣΘΞ"
    " !\"#¤%&'()*+,-./0123456789:;<=>?"
    "¡ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÑÜ§"
    "¿abcdefghijklmnopqrstuvwxyzäöñüà"
)


class DeliveryState(str, Enum):
    ACCEPTED = "accepted"
    DELIVERED = "delivered"
    UNDELIVERED = "undelivered"


@dataclass(frozen=True)
class ResetMessage:
    recipient: str
    reset_url: str
    expires_at: datetime
    template_version: str = "password-reset-v1"

    def render(self, now: datetime) -> str:
        if now >= self.expires_at:
            raise ValueError("reset link has already expired")
        minutes = max(1, int((self.expires_at - now).total_seconds() // 60))
        return f"Reset your password: {self.reset_url} Expires in {minutes} min."


@dataclass(frozen=True)
class Submission:
    message_id: str
    state: DeliveryState


class SmsAdapter(Protocol):
    def send(self, recipient: str, body: str) -> Submission: ...

    def get_delivery(self, message_id: str) -> DeliveryState: ...


def estimated_segments(body: str) -> tuple[str, int]:
    is_gsm_7 = all(character in GSM_7_BASIC for character in body)
    single_limit, joined_limit = (160, 153) if is_gsm_7 else (70, 67)
    units = len(body)
    segments = 1 if units <= single_limit else (units + joined_limit - 1) // joined_limit
    return ("GSM-7" if is_gsm_7 else "UCS-2", segments)


def submit_reset(adapter: SmsAdapter, recipient: str, reset_url: str) -> Submission:
    now = datetime.now(timezone.utc)
    message = ResetMessage(
        recipient=recipient,
        reset_url=reset_url,
        expires_at=now + timedelta(minutes=10),
    )
    body = message.render(now)
    encoding, segments = estimated_segments(body)
    print(
        {
            "event": "password_reset_sms_ready",
            "template_version": message.template_version,
            "encoding": encoding,
            "estimated_segments": segments,
        }
    )
    return adapter.send(recipient=message.recipient, body=body)

The SmsAdapter is the replaceable edge. One implementation can call one provider today and another tomorrow, but neither implementation gets to invent a new template or extend token life. Also, don't log the reset URL or full phone number. The example's event records only template and encoding metadata because observability should not become a second credential leak.

There is a subtle notebook-to-production trap here: a string that looks short can cross a segment boundary after someone adds an emoji or non-GSM character. Run the renderer against representative localized copy in CI, store the resulting encoding and segment count in eval output, and fail the build when an approved budget is exceeded. The estimate is a guardrail, while the provider's own segmentation result remains the billing authority.

Can a startup app compare SMS alert service alternatives by template ownership?

Build the comparison from a small, versioned fixture rather than a marketing page. Include US and EU destinations, the exact password-reset body, every locale you intend to ship, and the sender type the business can actually register. For each candidate, capture quoted cost per submitted segment, required registration work, supported receipt retrieval, retention relevant to polling, and the raw-to-internal status mapping. Keep currency and tax assumptions beside the quote. Prices change; the fixture makes the assumption visible.

Twilio, Amazon SNS, and Vonage are reasonable names to include in a candidate worksheet, but a vendor name is not a result. The winner can change with destination mix and sender eligibility, so this article doesn't rank them. Amazon SES belongs in a different lane: its documentation describes an email service, which makes it a useful reminder that email fallback should remain a separate channel adapter rather than masquerading as SMS.

Decision input	Evidence to collect	Failure caught early
Template ownership	Rendered body, variable schema, version	Copy drift and unsafe variables
Message shape	Encoding and segment count by locale	A “small” edit multiplying segments
Sender readiness	Registration approval for each intended route	A launch blocked by an unusable sender
Delivery evidence	Pollable states and terminal-state definitions	Treating acceptance as delivery
Cost model	Quote applied to the fixture's segment mix	Choosing from an incomparable headline rate

Cheapest and simplest pull in different directions. Owning templates adds a small internal contract and test suite, yet it reduces migration work and makes prompt-like text changes reviewable. A hosted template console may be simpler for a compliance-led publishing process. There isn't one universally correct boundary.

Poll delivery receipts without extending reset authority

Polling is an observation mechanism, not part of the security decision. A reset token should expire according to the application's clock even if the last delivery state is still accepted. Never extend the token merely because a receipt arrived late, and never equate provider acceptance with handset delivery.

Use bounded exponential backoff with jitter, save the provider message ID, and stop on your internal delivered or undelivered state. A worker should also stop after its configured observation window and record receipt_window_ended as an internal operational outcome; that label says the app stopped asking, not that the carrier failed. This distinction keeps dashboards honest.

Keep it boring.

For deployment, review the rendered US and EU fixtures, confirm sender registration before enabling traffic, and run contract tests against each adapter's status mapper. In production, watch submission counts, encoded segments, terminal-state ratios, poll attempts, and template versions without logging reset credentials. Re-evaluate quotes when the country or locale mix changes, and rerun the message eval whenever copy changes. That's the operational loop: render, measure, submit, observe, and expire independently.

DEV Community: SvenNilsson228

Marketplace Login Templates — 4 Deliverability, Security, Cost, and Fallback Controls

How do US/EU SMS and email OTP rules govern SaaS login?

Model the challenge in 4 states before writing code

Rollout starts with versioned authentication templates

Measure completion without trusting delivery proxies

References

Delivery Menu Intake: Triage Metadata at Upload, Defer Dish Image Cleanup

Should searchable dish data use metadata inspection and image cleanup at upload?

Put the moderation gate before transformation

A focused Python evaluation note

Compare the operational boundary, not a feature checklist

What should the rollout measure before production?

References

Marketplace Signup Friction (CAPTCHA First, Risk Scoring After Behavioral Signals)

How should marketplace signup place CAPTCHA before creation and score risk after signals arrive?

The failure mode is granting trust too early

Evaluate friction and abuse as separate outcomes

Where should the architecture draw its trust boundaries?

Ship the controls as one auditable workflow

References

SMS Event Alerts: Delivery Polling, Resends, Cancellation, and EU/US Guardrails

What did the experiment measure for a new-order SMS alert?

How should Node.js teams model SMS delivery status, resend, cancel, and rate limits?

Which provider fits template ownership and EU/US policy?

What should the production checklist reject?

References

Choosing PDF Endpoints for SaaS Form Discovery: Operational Complexity Under Load

How should a US/EU SaaS test PDF form schema discovery under load?

Define the job contract before choosing an endpoint

Which provider boundary fits the report pipeline?

A Python client for a discovery-validated PDF job

Decide with gates, not a weighted sales score

References

FastAPI Logout Scope: Single-Session Revocation Versus Global Revocation

How should FastAPI choose the right logout scope: single-session or global revocation?

How can one application boundary handle revocation safely?

Test the security semantics, not the button

Compare the boundary before choosing a provider

Ship with an auditable recovery path

References

Session Renewal: Verification, Refresh, and Revocation Boundaries for OTP Login

How should verification, refresh, and revocation boundaries shape a session renewal pipeline?

What does each implementation option make easy or difficult?

The catch: when should a specialist handle the risk layer?

A small evaluation loop before production

References

Python Fintech Email Dispatch: Per-User Timezone Logic Behind One UTC Cron

How should a SaaS handle daily report email timezone logic with UTC cron?

A runnable Python selector and cleanup handler

Retries, missed ticks, and work that outlives the callback

Which scheduler fits this retry and idempotency boundary?

References

Cron Session Cleanup Explained: Node.js Webhooks, Queues, Postgres, Redis Alternatives

Define the job contract before choosing a queue

A minimal HTTP audit, Postgres webhook, and worker

Compare providers by failure ownership

How should a Node.js cron cleanup queue for old user sessions and expired tokens reach production?

References

B2B Reservation Expiry: Node.js Webhook Queues, Backoff, DLQ Redrive

Build the publisher first

How should a Node.js webhook retry queue handle backoff and DLQ redrive?

Reliability trade-offs: prove the state machine first

Migration and portability: compare the queue boundaries

DLQ governance: redrive as a controlled release

Further reading

Full-Stack JavaScript Import Debugging: Browser Fetch to Node.js (Request IDs)

How should browser fetch request IDs connect frontend and Node.js server logs?

Make missing imports a separate operational signal

Choose the log destination by the investigation you need

Recovery depends on a small, stable contract

References

Password-Reset SMS Alert Service Alternative for Startup Apps (Own the Message)

Govern the password-reset message as a release artifact

Put the contract in code before comparing services

Can a startup app compare SMS alert service alternatives by template ownership?

Poll delivery receipts without extending reset authority

References