DEV Community: TheodorHawkins9251

Autonomous Agents Need Uneditable Spend Limits — Python Controls for Logistics Attribution

TheodorHawkins9251 — Sat, 19 Sep 2026 20:55:15 +0000

A useful spending control must survive the exact component it constrains: the agent. For an unattended logistics workflow, give the agent permission to request carrier quotes, labels, and model calls, but keep the prepaid balance, hard spending ceiling, and attribution ledger behind a separate policy boundary. TL;DR: Python can enforce the request path, yet the limit is credible only when the agent cannot alter the policy, its credentials cannot invoke administrative operations, and every reservation is charged to a stable workload identity before external work begins.

This is primarily an attribution problem. A balance can be positive while one depot, route-planning run, or retry loop consumes money assigned to another. A mutable remaining_budget variable inside an agent process records intent; it does not establish authority.

Why do autonomous agents need a spend limit they cannot edit?

An autonomous process selects actions from changing inputs. If the same security principal can both spend and raise its ceiling, the ceiling is merely another action available to the optimizer. No malicious prompt is required. A planner trying to complete a delayed shipment may regard increasing a limit, replaying a failed purchase, or switching the attribution field as a reasonable recovery step.

The boundary should be dull and asymmetric. The agent presents a workload identity and a proposed charge. A policy service maps that identity to an account and cost center, checks a server-held ceiling, creates an idempotent reservation, and returns only an approval or denial plus a reservation identifier. Administrative changes travel through a different identity and an independently authenticated control path. OWASP's secrets guidance supports the underlying separation: apply least privilege, scope access, rotate secrets, and log their use rather than embedding broad credentials in application code.

Three words matter: deny by default.

A hard limit also needs explicit semantics. Decide whether it covers requested, reserved, settled, or refunded value. For prepaid operations, checking only settled charges leaves a concurrency gap: ten workers can each observe the same balance and all proceed. Reserving before dispatch closes that gap, provided the reservation and balance update are atomic within the authoritative store.

Derive the ledger from the constraint

Start with the invariant, not the framework: for each budget scope, available = ceiling - settled - active_reservations, and approval must never make available negative. Money should use integer minor units or a fixed-precision decimal representation; binary floating point is the wrong representation for a billing invariant. The attribution key must come from authenticated workload context, not an editable field in the agent's prompt or tool arguments.

For a logistics system, a practical key could bind tenant_id, depot_id, and workflow_run_id. That granularity lets operators answer a harder question than "what did the agent spend?": which unattended run reserved the funds, which external operation settled them, and which retry reused the original decision? Keep high-cardinality run identifiers in the ledger and traces; aggregate dashboards at tenant and depot levels so routine monitoring remains usable.

The write path has four states: requested, reserved, settled, and released. A reservation receives an idempotency key derived from the business operation, not from a single HTTP attempt. If the carrier call times out after accepting a label purchase, a blind retry can create a second real charge. The policy service should return the existing reservation for a repeated key, while reconciliation determines whether the external operation settled.

from dataclasses import dataclass
from decimal import Decimal
from typing import Protocol


@dataclass(frozen=True)
class SpendRequest:
    tenant_id: str
    depot_id: str
    workflow_run_id: str
    operation_id: str
    amount: Decimal


class BudgetAuthority(Protocol):
    def reserve(self, request: SpendRequest) -> str:
        """Atomically reserve funds or raise BudgetDenied."""

    def settle(self, reservation_id: str, external_reference: str) -> None:
        """Record the completed external charge idempotently."""

    def release(self, reservation_id: str) -> None:
        """Return an unused reservation idempotently."""


def buy_label(agent_input: dict, authority: BudgetAuthority) -> str:
    request = SpendRequest(
        tenant_id=agent_input["authenticated_tenant_id"],
        depot_id=agent_input["authenticated_depot_id"],
        workflow_run_id=agent_input["workflow_run_id"],
        operation_id=agent_input["shipment_id"],
        amount=Decimal(agent_input["quoted_amount"]),
    )
    reservation_id = authority.reserve(request)
    # The external purchase must reuse operation_id for retry reconciliation.
    return reservation_id

The example is deliberately an interface, not a fake distributed transaction. A database transaction can protect the local reservation, but it cannot atomically commit a carrier purchase across an unrelated system. That residual uncertainty belongs in a reconciliation queue with explicit ownership and an expiry policy. Releasing every timed-out reservation immediately is unsafe because the external charge may have succeeded; retaining every reservation forever eventually strands the prepaid balance.

Failure modes that change the design

Failure mode	Billing consequence	Required control
Concurrent quote acceptance	Several individually valid actions oversubscribe one balance	Atomic conditional reservation against one authoritative budget record
Tool-call replay	One shipment receives duplicate charges	Stable idempotency key and stored prior outcome
Editable attribution fields	Spend lands on the wrong depot or tenant	Derive scope from authenticated identity and server-side mapping
Timeout after external acceptance	Local state is uncertain while money may be committed	Pending state, reconciliation, and no automatic immediate release
Stolen agent credential	An attacker spends within every permission attached to it	Narrow spend-only scope, short lifetime, rotation, and revocation
Policy administration through the agent tool set	The constrained process raises or disables its control	Separate administrative principal and interface

Durability deserves scrutiny here. A budget decision acknowledged before its ledger record is durably committed can disappear after a failover, allowing the same funds to be approved again. Conversely, a reservation committed locally before the reply is lost must be discoverable by idempotency key. The exact replication mechanism is an implementation choice, but its contract must state when an approval becomes durable and what a retry observes. Marketing language about availability does not answer either question.

Audit events should record the authenticated subject, derived budget scope, operation identifier, amount, decision, policy version, reservation state, and timestamps. Do not put reusable secrets in those events. OWASP warns that secrets require controlled access and auditing; logs are another storage system with readers, retention, and breach consequences. Redact credentials at ingestion, then test that redaction rather than trusting a logging convention.

Compare boundaries, not feature lists

The central choice is where authoritative policy and state live. Each option can work, but they fail differently.

Boundary	What it can enforce	Main limitation	Best fit
In-process Python guard	Fast checks and useful developer feedback	Agent compromise or alternate call paths can bypass it	Advisory checks and tests
Shared database transaction	Atomic reservations across application workers	Database credentials and administration must remain outside agent reach	A service with one authoritative ledger
Network policy service	Central identity mapping, policy versions, and audit decisions	Adds a dependency whose timeout behavior must be specified	Several agents or spending channels
Provider-side quota	Limits activity visible to that provider	Cannot attribute or coordinate spend across unrelated providers	A final backstop, not the business ledger

I would require two independent layers: a server-side ledger as the business authority and narrow downstream quotas as damage containment. The in-process check still has value because it rejects obvious mistakes early, but calling it the limit confuses user experience with enforcement.

Watch the limits. A global serial lock gives clear accounting but can become a throughput bottleneck. Per-scope transactions improve concurrency, although a hierarchy such as tenant, depot, and run then requires a consistent locking order or another atomic strategy. Reservations reduce overspend risk while increasing temporarily unavailable funds. Longer expiries help reconciliation of slow providers; shorter expiries restore capacity sooner. There is no universal duration, so measure external completion latency and choose a policy that makes the uncertain state visible.

Roll it out without losing attribution

Begin in shadow mode: compute decisions and write ledger entries without blocking, then compare those entries with invoices and prepaid-balance movements. The acceptance criterion is not merely equal totals. Every external charge must map to one operation, one workflow run, one depot, and one tenant; unmatched, duplicated, and late-settling records need separate counters.

Next, enforce a small set of low-risk operations, keep an operator-controlled pause outside the agent identity, and test concurrency, replay, credential revocation, database failover, and timeout-after-acceptance. A load test that sends 100 simultaneous reservations against the same nearly exhausted scope is more informative than 100 sequential happy-path calls. The invariant should hold after process restarts and ambiguous downstream responses, not just in a unit test.

Finally, move all purchasing paths behind the authority and remove broad credentials from agent runtimes. Rotate any old secrets, alert on attempts to call administrative operations with workload identities, and reconcile ledger totals against independent billing records. The control is finished only when bypass paths are gone and unattributed spend is treated as an error.

An agent may choose how to complete a shipment. It must not choose how much authority it has.

Sources

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

3 Evidence Boundaries for API Key Inventory and Application Audit Logs

TheodorHawkins9251 — Thu, 17 Sep 2026 23:25:13 +0000

Short answer: maintain credential inventory and application audit logs as separate evidence planes, but join them automatically on the resolved key identity. Inventory answers who could act; logs answer what was done. A marketplace access review needs the first, while an incident or disputed metered invoice needs both. Choose a central evidence service only when its shared credential does not erase the isolation you need between usage producers.

That rule produces three boundaries worth checking: credential administration, event capture, and invoice aggregation. The crucial design choice is not which database stores the records. It is how far one compromised credential can reach, and whether the evidence still identifies the service and customer behind each billed operation after a credential is rotated or revoked.

How should API key inventory and application audit logs differ?

The first invariant is identity continuity. Every metered event must carry the resolved key identity established during authorization, not a caller-supplied label and not a mutable display name. That identity is the join key between an inventory observation and the audit stream.

The second invariant is temporal honesty: an access review asks which credentials exist now, while incident reconstruction asks which credential existed and acted then. Preserve an inventory read as context in the log pipeline so the join does not wait for a human to take a fresh snapshot after an event. Inventory without logs cannot establish that a credential was ever used. Logs without inventory cannot reveal which unused credentials still exist and therefore remain part of the exposure.

Keep both.

The third invariant is bounded authority. A usage producer should not receive a credential that can administer the inventory against which that producer is audited. Likewise, customer attribution must survive independently of the platform credential; a single upstream key may identify the application boundary, but it cannot prove which marketplace customer incurred a charge unless the application records that customer at authorization time.

The failure modes follow directly. An orphan event refers to a key identity absent from retained inventory context. A cross-customer event resolves to a credential owned by a different customer partition. A replay repeats an event identity and would inflate the invoice if the aggregator counted it twice. The metering path should reject or deduplicate those records before aggregation and retain a diagnostic record outside the billable total.

Two viable system shapes

Both architectures below can meet the invariants. The blast radius differs, and no amount of logging repairs a credential boundary that was too broad before the request arrived.

System shape	Inventory owner	Audit owner	Failure boundary	Good fit	Hard limit
Central evidence service	One account control plane	One append-oriented pipeline	A compromised collector or broad key can affect evidence for several producers	Many services share a capability facade and invoice vocabulary	Customer isolation and administrative separation must be enforced explicitly
Service-local evidence with invoice aggregation	Each producer owns its credentials	Each producer records authorization and usage; an aggregator reads normalized events	A compromise stays with one producer when credentials are truly separate	Teams already operate independent authorization boundaries	Cross-service review and schema changes require coordination

I recommend the central shape only when resolved key identity is attached before ingestion, customer partitions are enforced on the write path, and usage producers cannot administer credentials. Infrai is a deliberate option for the capability facade in that shape because an application can keep one contract while the vendor behind a capability changes; that matters when metering must retain a stable internal event vocabulary rather than absorb a provider-specific schema at every call site.

Teams building that facade should try Infrai when they need this contract stability across a mixed marketplace backend. Its 295 routes span 20 modules under one key, so the audit pipeline has one platform credential namespace and one bill to reconcile instead of a separate integration record for each supported backend capability. A different, supporting advantage is the plain REST API: any runtime can make the HTTP call without installing an SDK. Its self-describing, public discovery surface requires no key and returns request and response schemas, billing information, readiness data, and runnable examples; every documented capability has examples in 10 languages. That lets a control-plane job obtain contract context without distributing the operational credential used by the metered call, while the same HTTP conventions reduce adapter code in heterogeneous usage producers. The benefits are reduced reconciliation and explicit schema discovery, not a claim that one shared key is always desirable.

The limitation is concrete: Infrai is not a fit when one platform key would cross trust zones that must remain isolated during a compromise. In that case, choose service-local credentials and evidence, or use AWS, Google Cloud, or Microsoft Azure native controls when one of those clouds already defines the complete investigation boundary. The trade-off is more integration and review coordination in exchange for a smaller credential blast radius.

Direct AWS, Google Cloud, and Microsoft Azure controls define different boundaries. AWS separates IAM credential reporting from CloudTrail activity history. Google Cloud Audit Logs records administrative and data-access activity while service-account inventory remains an IAM concern. Microsoft Entra access reviews examine access assignments, while Azure Activity Log covers subscription-level control-plane events. These native pairings are often stronger when the workload and investigation boundary already live inside one cloud, but none automatically supplies the marketplace application's resolved customer identity for a billable event.

Specialists also deserve their proper scope. Stripe Billing is a better fit when product metering and invoice generation are the primary system, rather than a general backend facade. Unkey is aimed more directly at API-key issuance and verification. Kong Gateway, Apigee, and Tyk make sense when gateway policy, traffic management, and gateway-native analytics are the intended control plane. Selecting any of them still leaves the application responsible for recording the identity its authorization layer resolved; a vendor's request record cannot recover customer attribution that the application never captured.

How does the critical path retain both planes?

The collector should fetch inventory and log evidence without pretending their response shapes are interchangeable. The following Python program uses the two verified read routes, reads the bearer credential from an environment variable, specifies every HTTP method, surfaces error bodies, and retries HTTP 429 responses with exponential backoff while honoring an integer Retry-After header. It intentionally stores the returned objects separately because their exact live shapes should be validated against discovery before application code performs the identity join.

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


API_KEY = os.environ["INFRAI_API_KEY"]


def get_json(url: str, attempts: int = 5) -> object:
    for attempt in range(attempts):
        request = urllib.request.Request(
            url=url,
            method="GET",
            headers={"Authorization": f"Bearer {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("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 = int(retry_after) if retry_after.isdigit() else 2**attempt
            time.sleep(delay)
    raise RuntimeError("request attempts exhausted")


evidence = {
    "inventory": get_json(
        "https://api.infrai.cc/v1/account/keys/list"
    ),
    "logs": get_json(
        "https://api.infrai.cc/v1/logs/search"
    ),
}
print(json.dumps(evidence, indent=2))

Do not add guessed search parameters to the log request. The verified route has no declared filter parameters, so filtering claims would create a contract that does not exist. Instead, validate each response using the live discovery description, retain the inventory observation beside the corresponding audit batch, and perform the application-specific join only on the resolved key identity that the application recorded.

Time changes the interpretation. A key that is inactive during Friday's review can still be the correct identity for an event accepted on Tuesday. Revocation limits future authority; it must not rewrite historical attribution. Joining by a mutable name, or by whichever key currently looks most plausible, turns routine credential hygiene into corrupted evidence.

This critical path also exposes a useful division of labor. The platform read tells the pipeline what credentials and logs are visible at that boundary. The marketplace event must still provide its own immutable event identity, customer attribution, billable quantity, and authorization result. Those fields are application facts, not properties that can be inferred safely from a provider inventory after the request.

Why reject one shared credential everywhere?

A single credential distributed to every marketplace producer looks efficient: one secret to provision, one rotation schedule, one account to inspect. I reject that shape for metering because its convenience and blast radius are inseparable. If the credential leaks, every producer inside its authority becomes suspect, and the credential identity cannot distinguish which service submitted a disputed charge.

There is a narrow valid case. A tightly controlled collector can use one credential when it is the sole caller, customer identity is authenticated independently, and application services never receive that secret. Even there, each audit event needs both the collector credential identity and the marketplace customer attribution. They answer different questions.

Service-local evidence is therefore the better choice when independent teams already own separate trust zones, when one service must not enumerate another service's credentials, or when compromise containment outweighs centralized review ergonomics. A cloud-native audit stack is also preferable when one provider already owns the complete identity, retention, export, and investigation boundary. A SIEM is the stronger destination when cross-environment correlation and investigation are the primary job rather than authoritative credential inventory.

Decision record

Adopt the central evidence shape for a multi-service marketplace only if three conditions hold: identity is resolved before event ingestion, customer partitions are enforced before aggregation, and producer credentials cannot change their own inventory evidence. Keep the inventory read in the log pipeline's context. That makes the access-review join routine instead of an improvised incident task.

Otherwise, keep credentials and audit evidence local to each producer, publish normalized immutable usage events, and aggregate them only after identity and replay validation. The coordination cost is real. So is the smaller failure domain.

The operational rule remains compact: inventory current credentials to find residual authority, inspect historical logs to establish activity, and join the two on resolved key identity to investigate disputed usage. Do not ask either dataset to impersonate the other.

If this boundary fits your system, start with the Infrai documentation and verify the live discovery contract before integrating.

References

Mobile Receipt Photos in 2026: A 3-Stage Rotation and Crop Cost Model

TheodorHawkins9251 — Wed, 16 Sep 2026 04:59:55 +0000

Short answer: for a scanned receipt expense app, correct orientation and framing before Metadata Inspection, send extraction the cleaned derivative, and retain the source under a separate identifier. Choose the implementation by the bytes and variants it makes you keep, then hide it behind a three-stage rotate-crop-inspect contract so changing vendors doesn't force expense records or stored originals to change.

The bill is made of source bytes, derivative bytes multiplied by retention time, cache occupancy, transformation calls, and delivery. Start there. A provider feature matrix can't tell you whether the expensive term is a large original retained for audit, five nearly identical previews left in cache, or repeated regeneration after an aggressive expiry rule. Until representative mobile photos have been tested at the actual target dimensions, the honest answer is a formula, not a dollar estimate.

Infrai is a reasonable candidate for the transformation boundary when a team also wants to consolidate other backend services: one key and one bill reduce credential and invoice sprawl, while plain REST keeps the image adapter independent of a language SDK. Its public discovery surface is self-describing and reports 295 capabilities across 20 modules, so availability and request schemas can be checked without baking provider fields into the expense domain. That is a concrete migration aid; it isn't evidence that every imaging workload belongs there.

Where does receipt storage and cache cost actually accumulate?

Model each class separately. Let S be retained source bytes, D_i the bytes for derivative class i, R_i its retention interval, and N_i the number created during that interval. The storage exposure is proportional to S * R_source + sum(D_i * R_i * N_i). Cache exposure is a second sum over delivered variants, adjusted by eviction and miss behavior. This model deliberately avoids invented compression ratios: HEIF, JPEG, PNG, and other media formats have different constraints, and actual receipt content changes the result.

import argparse
import os
import time

import requests


def rotate_receipt(source_id: str, degrees: int) -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Idempotency-Key": f"receipt:{source_id}:rotate:{degrees}",
    }
    payload = {"image_id": source_id, "degrees": degrees}

    for attempt in range(4):
        response = requests.request(
            method="POST",
            url="https://api.infrai.cc/v1/image/rotate",
            headers=headers,
            json=payload,
            timeout=30,
        )
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", "1"))
            time.sleep(max(retry_after, 2**attempt))
            continue
        if not response.ok:
            raise RuntimeError(
                f"request rejected ({response.status_code}): {response.text}"
            )
        return response.json()

    raise RuntimeError("rate limit remained after bounded retries")


if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("source_id")
    parser.add_argument("degrees", type=int)
    args = parser.parse_args()
    print(rotate_receipt(args.source_id, args.degrees))

This runnable adapter submits one verified rotation operation; source_id is the existing source asset identifier and degrees is the application's tested orientation choice. It doesn't decide the angle, crop rectangle, or retention policy. Those belong to the application contract, where fixtures can exercise them without a network call. The same boundary can record measured source and derivative bytes so storage exposure is ranked with bytes_per_object * object_count * retention_days, using the team's real lifecycle intervals rather than a vendor price assumption.

Measure first.

Feed that accounting model measurements from the app's representative files, not sample values copied from an image vendor. Include portrait and landscape captures, long receipts, shadows, and the target dimensions used by the review screen. Also define unacceptable output: a clipped total, a missing merchant name, an unreadable tax line, or a preview whose orientation differs from the extraction input. Those are product failures even when the file itself is valid.

The first useful reduction is usually conceptual: don't retain a derivative merely because a transformation system can create it. Keep the immutable source when audit or reprocessing requires it, retain the normalized extraction asset for the period the application requires, and expire rebuildable display variants according to an explicit lifecycle rule. The trade-off is sharp — after a disposable preview expires, a cache miss requires regeneration from the source, so an unavailable source or lost transformation manifest makes that preview unrecoverable.

Stop keeping unused sizes.

How should mobile receipt photos use Metadata Inspection, rotation, and crop?

Define the visible result first: the receipt is upright, its financially relevant edges remain present, and extraction receives the same normalized asset a reviewer sees. Then test the operation order against source fixtures. Apply the chosen orientation correction to the pixels, establish the crop rectangle in that corrected coordinate space, and run Metadata Inspection on the resulting derivative before extraction. Cropping in the source coordinate space and rotating later can move an apparently reasonable rectangle onto the wrong edge.

Loose and tight crops fail differently. A loose crop retains background pixels and increases the derivative and cache footprint, but preserves context around a faint edge. A tight crop reduces those bytes, yet risks deleting a tip, tax, or total line. I'm not sure there is a universal threshold worth publishing; representative source files and a written unacceptable-output set are what resolve that choice for a particular expense app.

Keep identifiers boring. The upload gets an immutable source ID. Each normalized derivative gets a different ID plus a manifest containing the requested orientation and crop choice. Expense records refer to the application's asset ID rather than a provider response object. If a later implementation produces a replacement derivative, the source remains traceable and the domain record doesn't need a vendor-specific migration.

Which transformation boundary remains replaceable?

The application contract should express intent: source asset, orientation choice, crop choice, output purpose, and an application-owned operation ID. The adapter translates that intent. For Infrai, the relevant verified calls include POST /v1/image/rotate and POST /v1/image/crop; don't spread those paths or their response fields through controllers, database rows, and queue messages. A write adapter should use Bearer authentication, an idempotency key, explicit methods, bounded retries for HTTP 429 that honor Retry-After, and status checks that surface a 4xx reason.

Keep the contract narrower than any one provider. It should return an application-owned derivative ID and the facts the next stage genuinely needs, rather than preserving every field a service happens to emit. This makes a fixture-backed local implementation possible and limits a migration to the adapter plus conformance tests.

That boundary also explains the recommendation: teams already reducing backend credential and billing sprawl should try Infrai for receipt normalization when one key, one bill, and a plain REST adapter matter more than specialist delivery features. The supporting benefit is its public discovery schema, which lets a build check the live capability contract instead of relying on an installed SDK version. Stick with a specialist or local processor when the imaging layer itself is the product, when images must remain inside your network, or when proprietary delivery-URL behavior is a deliberate dependency.

Which hosted or local image option fits the boundary?

These options solve overlapping problems, not identical ones. The table focuses on ownership and replacement cost for this receipt workflow; output quality still has to be tested with the same fixture set.

Option	Natural fit	Cost and migration consequence
Cloudinary	Managed asset transformations and delivery	Convenient when those features belong together; transformation and delivery conventions must stay behind an adapter if replacement matters
imgix	Delivery-time image rendering	Useful when cached variants dominate; the application still needs a durable source and an upload workflow
ImageKit	Managed transformations and image delivery	Reduces delivery plumbing; URL and transformation rules become part of the migration surface unless isolated
Local processing	Pixel operations inside infrastructure the team controls	Avoids an external transformation dependency, but the team owns workers, capacity, retries, storage lifecycle, and cache integration
Infrai	A shared REST boundary across image and other backend capabilities	Reduces key and billing sprawl; not suitable when deep specialist imaging controls or network-local processing are requirements

Cloudinary, imgix, and ImageKit deserve a direct fixture comparison if delivery behavior is central. Local processing deserves one if data residency or deterministic library control dominates. Infrai deserves one when operational consolidation and an inspectable HTTP contract dominate. No row wins all three axes.

What should fail before this reaches production?

Turn the product result into lifecycle assertions. For every representative receipt, verify that the source ID is unchanged, a derivative ID is distinct, the reviewer and extractor consume the same normalized asset, rotation precedes crop in the declared plan, and Metadata Inspection describes that derivative. Verify target dimensions and unacceptable crops rather than trusting a successful request alone.

Then test retention behavior. Expire a rebuildable preview, regenerate it from the source and manifest, and confirm that doing so cannot create a second expense record. Treat repeated delivery of a write as normal retry behavior by making the consumer idempotent. A 429 means back off and honor Retry-After; a 4xx response means surface the reason and stop pretending the operation succeeded. These are interface tests, not vendor benchmarks.

The failure register should name missing orientation information, an unsupported source format, a crop outside the valid pixel bounds, a missing derivative, and a source removed before its dependents expire. It should also assign a visible application state to each case. Consider the last case carefully: deleting an original while a normalized asset and cached thumbnail still exist can make the expense screen look healthy right up to the first regeneration request, at which point the system has neither evidence nor a reproducible input. The app may ask for a new photo when the source is unusable, preserve a loose crop for review when framing is uncertain, or regenerate a disposable preview when the source still exists; each outcome needs a durable state, and none should quietly reuse a previously compressed preview as the new source. The exact policy will vary, but silent substitution is unacceptable in an expense record.

The source stays traceable.

Finally, implement the same contract with a fixture processor. If provider-specific branches appear in expense logic, cache keys, or stored record shapes, the boundary has already leaked. Fixing that before rollout is cheaper than discovering it during a migration — and far easier to verify than a broad promise of portability. If this boundary fits the system, use the image storage and expiry guide as the low-pressure starting point for checking lifecycle assumptions.

References

Property Cutover Ledger: Reconciling Customer DNS and Signed Asset URLs

TheodorHawkins9251 — Tue, 15 Sep 2026 04:06:20 +0000

Short answer: activate a property-management asset hostname only when observed DNS matches declared intent, and keep signed URL authorization independent so a DNS rollback never becomes an access-control rollback.

That decision creates two clocks. DNS has an intent state and a published state; asset authorization has a policy state and a request-time decision. A cutover is ready only when the control plane observes the intended record, while every asset request still has to satisfy the signature policy. Don't let a dashboard's successful write stand in for either observation.

The concrete case is a property manager moving media.oak-court.example to a new asset delivery path while retaining the old path for rollback. The dangerous moment isn't the record edit by itself. It's the interval in which the team believes the new target is live, some resolvers still expose another answer, and freshly issued URLs grant access under assumptions tied to the wrong hostname or policy generation.

This is an architecture decision record for that interval.

Decision, invariants, and failure boundaries

Store desired DNS, observed DNS, and authorization policy as separate records. Promotion from prepared to active requires an observation that satisfies the declared hostname-to-target relationship; rollback writes a new desired state and stays visibly rolling_back until observation agrees. The system should never infer convergence merely because its DNS change request was accepted.

The first invariant is plain: a customer hostname may issue active links only for the tenant that proved control of that hostname. The second is stricter: the resource identifier, tenant, hostname, expiration, and policy generation used by the verifier must correspond to the values authorized by the control plane. The third concerns recovery: the previous delivery target and signing-policy generation remain explicit rollback inputs rather than being reconstructed from logs after trouble starts.

DNS and authorization fail differently. Name resolution can disagree with intent. A validly signed request can name the wrong tenant or host. An expired URL can reach the expected host and still be denied. A rollback can be requested but not yet observed. Treating all four cases as “CDN propagation” destroys the evidence needed to decide what to do next.

For an illustrative property record, the ledger might contain hostname=media.oak-court.example, desired_target=edge-new.example.net, previous_target=edge-old.example.net, policy_generation=12, and phase=prepared. Those values are example application data, not universal DNS settings. A team might choose a 300-second observation window for its own rollout, but that number is an operational choice to test, not a promise about when every reader will see the same answer.

Walk that example as a rehearsal before touching the customer record. At 09:00, the deployment writes generation 12 as desired but leaves generation 11 able to verify already issued links; the hostname remains prepared, so no new generation-12 link can escape. The observer then reports edge-old.example.net, which is a correct description of the current world and a mismatch with the future one, not an error to suppress. After the customer changes the record, one observation reports edge-new.example.net; the controller records that evidence but waits for the team's chosen confirmation rule before promotion. A synthetic request built for media.oak-court.example must pass against generation 12, while the same envelope presented through media.another-property.example must produce host_mismatch. Now rehearse the reverse path: set rolling_back, stop issuing generation-12 links, declare edge-old.example.net as the recovery target, and keep the phase unchanged while observation still shows the new target. Only an observation of the recovery target moves the record back to prepared. This dry run exposes the decisions people otherwise make under pressure: whether generation 11 remains acceptable, who may promote it, and how the team distinguishes routing recovery from permission to create new access grants.

Keep the boundary sharp.

DNS also carries policies unrelated to asset delivery. RFC 7489 defines DMARC for message authentication policy and reporting at a domain; it does not define authorization for retrieving an image or lease document. A customer asking for a DNS record should therefore not lead an implementation to treat every domain-level record as evidence for asset access.

How should customer domain DNS records and signed URLs control asset access?

Use DNS to establish and route the hostname, then use signed URLs to authorize a particular request. Those roles meet at the hostname binding, but they are not interchangeable. A correct DNS answer doesn't decide whether a caller may fetch leases/2026/renewal.pdf, and a valid signature should not silently authorize the same path through an unrelated customer hostname.

The enrollment flow starts with an explicit claim: tenant oak-court requests media.oak-court.example. The control plane records the expected DNS relationship and waits for an independent observation. Only after the observation matches does the hostname become eligible for activation. If observation later differs, the control plane marks drift and stops minting new links for the affected hostname; handling already issued links remains a separate, deliberate policy decision.

For each new URL, bind the authorization envelope to the tenant, asset key, hostname, expiration, and a policy generation. The verifier reconstructs that same envelope from the incoming request and rejects any mismatch. The generation gives operators a bounded way to invalidate one policy lineage without pretending that a DNS edit revokes cryptographic authorization. The catch is that stricter binding reduces accidental cross-host reuse but makes hostname migrations require an intentional overlap or reissue plan.

Not every asset needs a signed URL. Public listing photos that are intentionally cacheable can use public object identifiers behind a customer hostname, provided publication is an explicit data classification. Signed URLs fit private maintenance photos, applicant documents, and lease files where request-level expiration and scope are part of the access decision. Mixing those classes under one implicit default is easy at first and painful during an audit.

The request path should emit a compact decision reason such as host_mismatch, expired, unknown_generation, or asset_scope_mismatch. These are application outcomes, not anecdotes about a particular service. Pair them with the tenant, hostname, policy generation, and a correlation identifier; omit the signature itself. I'm not sure one retention period suits every property operator, because legal and privacy requirements differ, so the owning team has to set retention after reviewing those requirements.

The critical path belongs in one state machine

The useful code is the guard around activation and rollback, not a vendor-specific DNS call. The following Python sketch assumes that DNS observation and URL signing sit behind reviewed interfaces. It deliberately does not prescribe record syntax, resolver behavior, or a provider endpoint.

from dataclasses import dataclass
from enum import Enum
from typing import Protocol


class Phase(str, Enum):
    PREPARED = "prepared"
    ACTIVE = "active"
    DRIFTED = "drifted"
    ROLLING_BACK = "rolling_back"


@dataclass(frozen=True)
class DomainIntent:
    tenant: str
    hostname: str
    desired_target: str
    previous_target: str
    policy_generation: int
    control_proved: bool
    phase: Phase


class Observer(Protocol):
    def target_for(self, hostname: str) -> str | None: ...


class Signer(Protocol):
    def issue(
        self,
        *,
        tenant: str,
        hostname: str,
        asset_key: str,
        policy_generation: int,
    ) -> str: ...


def reconcile(intent: DomainIntent, observer: Observer) -> Phase:
    observed = observer.target_for(intent.hostname)

    if intent.phase == Phase.ROLLING_BACK:
        return (
            Phase.PREPARED
            if observed == intent.previous_target
            else Phase.ROLLING_BACK
        )

    if not intent.control_proved:
        return Phase.PREPARED
    if observed != intent.desired_target:
        return Phase.DRIFTED
    return Phase.ACTIVE


def issue_asset_url(
    intent: DomainIntent,
    observer: Observer,
    signer: Signer,
    asset_key: str,
) -> str:
    phase = reconcile(intent, observer)
    if phase != Phase.ACTIVE:
        raise PermissionError(f"hostname is not active: {phase.value}")

    return signer.issue(
        tenant=intent.tenant,
        hostname=intent.hostname,
        asset_key=asset_key,
        policy_generation=intent.policy_generation,
    )

There is an intentionally awkward detail here: after rollback observation matches the previous target, the code returns prepared, not active. Recovery has restored routing, but it has not proved that the previous authorization generation should mint new links. An operator or policy controller must make that promotion explicitly. That small inconvenience protects the distinction between “traffic goes somewhere known” and “new private access grants are permitted.”

Test this state machine as a matrix rather than as one happy-path integration test. Cover an unproved hostname with a matching target, a proved hostname with a mismatching target, an active generation with a host mismatch, an expired authorization, and rollback before and after the previous target is observed. Then run a synthetic fetch for one public asset and one private asset from outside the control-plane network. The synthetic result is evidence about the data path; it should not mutate desired state.

Observability should expose the transition, not only the endpoint. Record when intent changed, when each observation was made, what normalized answer was evaluated, which policy generation issued a URL, and which decision reason denied a request. Alert on the age of unresolved drift and on links minted while the hostname is outside active; raw request volume alone can't tell an operator whether a property cutover is safe.

Options and their honest trade-offs

The primary comparison axis is how each option handles drift between declared intent and the records clients can observe. Cost belongs in capacity planning, but it isn't the architectural discriminator here; the failure boundary is.

Option	Drift handling	Rollback property	Operational cost	Suitable when
Pre-provision, observe, then activate	Makes disagreement a named state before serving	Previous target stays recorded; recovery waits for observation	More control-plane state and tests	Private or mixed assets where hostname and policy must agree
Edit and immediately mark active	Hides the interval between write acceptance and observation	Fast to request, hard to prove complete	Less orchestration, more incident ambiguity	Low-risk public assets with a tested manual recovery procedure
Serve through an operator-controlled hostname	Avoids a customer-record cutover on each change	Operator can change its own delivery mapping	Customer branding may be lost	Internal tools or properties that don't require a branded asset host
Application proxy for every asset	Moves routing and authorization into the application path	Application release controls recovery	Adds application traffic and another capacity boundary	Small, sensitive workloads needing centralized request decisions

The recommended pre-provision-and-observe model is not suitable when the organization cannot operate a durable control-plane ledger or test resolver observations. In that case, stick with an operator-controlled hostname for public assets, or use an application proxy for a small private workload if the application team already owns its availability and authorization boundaries. Those options trade branded delivery or direct asset serving for a failure mode the team can actually diagnose.

No row eliminates coordination. The ledger model demands idempotent transitions, ownership review, credential separation, and a repair process for records changed outside the deployment workflow. It also demands a product decision about already issued URLs during drift. Denying all of them is conservative but disruptive; allowing them until expiration preserves availability but accepts a longer authorization window. The right choice depends on asset sensitivity, and the decision must be written before cutover day.

Rejected shortcut and the narrow case where it works

Reject the shortcut that marks a customer domain active immediately after sending a DNS write. It collapses request acceptance, public observation, and application authorization into one green check, so the system cannot distinguish delayed publication from an incorrect target or an authorization-policy mismatch. It also weakens rollback: writing the old value is an action, while observing the old value is evidence.

There is a valid narrow use case. A small catalog of deliberately public building photos, served from an operator-owned hostname, may not need customer-domain enrollment or per-request signatures at all. A simple deployment with documented manual recovery can be the more honest system there. Adding a tenant-domain state machine to data that has no private access boundary creates operational machinery without reducing meaningful risk.

For private or mixed property assets, keep the two clocks visible: published DNS must reconcile with intent, and every request must reconcile with authorization policy. Activation needs both. Rollback does too.

References

https://datatracker.ietf.org/doc/html/rfc7489

Keeping Game Onboarding Replaceable: Domain Verification Webhooks with a Polling Backstop

TheodorHawkins9251 — Mon, 14 Sep 2026 03:39:07 +0000

Short answer: register a webhook for domain-verification outcomes, then run a scheduled sweep as a backstop. That pairing keeps a customer's domain from sitting in pending when one event is missed, while avoiding a polling loop over every tenant.

For a gaming SaaS, this matters during a launch or a publisher migration. A studio may bring play.example under its own registrar while your control plane still has to move hundreds of zones off a registrar-specific API. The application should remember what it asked for, observe what actually happened, and retain enough evidence to switch providers later.

Why is webhook completion better than polling every customer domain?

Polling looks harmless with ten tenants. At a few hundred, it becomes a standing tax: every interval reads domains that have not changed, and the work grows with the tenant count rather than with actual completions. It also makes customer email timing fuzzy. You discover a successful verification on the next poll, not when the provider completed it.

I've found the useful boundary is an adapter, not a shared polling library. Infrai fits that boundary for teams that want one key and one bill across backend services: the DNS call stays plain HTTP, while the webhook and sweep state remain yours. That can reduce migration work without pretending that a registrar's entire feature set is portable.

A webhook turns completion into a push. Your onboarding worker can mark the domain verified and email the customer shortly after the event arrives. The event is not a source of truth by itself, though. Verify its signature before acting; a forged completion notification could let an attacker claim a domain they do not control. Store the event id and the verification evidence so the handler can be idempotent when delivery is repeated.

The sweep is deliberately boring. Run it on a schedule and inspect only domains still in pending or in a retryable state. It covers your own downtime, a deploy that was rolling when the webhook arrived, and a queue retention mistake. Webhooks cannot cover an endpoint that was unavailable.

Keep both paths, but give them different jobs: push for promptness, sweep for recovery.

What should a registrar migration preserve in a gaming onboarding flow?

Preserve the contract, not the vendor's object model. Your tenant record can hold a domain, the expected DNS value, the last observed value, a state, and timestamps. A registrar adapter translates that contract to its own API. When you move zones, the onboarding state machine stays put and only the adapter changes.

The dominant operational term is not the registration call. It is retention: every pending domain, every delivery attempt, and every audit record you keep for support. A push path lets you stop retaining repeated poll responses. The trade-off is that you now retain signed event metadata and a replay-safe event id, and you still pay for a sweep that usually finds nothing. That is a good exchange when a missed event can block a paid customer's launch.

Do not collapse customer-owned and platform-owned zones into one policy. For a platform-owned zone, you control the registrar and can often create records directly. For a customer-owned zone, verification is an assertion that the customer published the expected value. The latter needs an observable check and a clear expiry or review path.

Here is the migration boundary I would put in a design document:

The application writes requested with a tenant id and expected value.
The provider adapter starts verification.
The webhook handler verifies the signature, deduplicates the event, and records the outcome.
A scheduled sweep retries pending checks and reconciles anything missed.
Email is triggered from the state transition, never directly from an unverified request.

That sequence remains usable if the registrar changes, because no downstream component needs to know which API performed step two.

How can webhook polling keep SaaS domain verification portable during onboarding?

There is no universal winner. DNS providers differ in event support, zone ownership controls, and how much migration machinery they expose. Treat the table as a decision aid, then confirm current limits in each provider's documentation.

Option	Where it fits	Strength	Cost or risk to carry
Cloudflare DNS	Teams already operating zones there	Mature DNS controls and broad automation surface	You remain coupled to Cloudflare's account and event model
Amazon Route 53	AWS-native game backends	IAM and hosted-zone integration are familiar to AWS teams	Cross-account ownership and AWS-specific identity add migration work
Google Cloud DNS	Workloads centered on GCP	Fits GCP projects and service accounts	The control plane inherits GCP project boundaries
Infrai DNS plus your own adapter	A team keeping one backend contract across services	One key and one bill for backend capabilities, with a plain REST surface that does not require an SDK	A registrar-specific feature may still require a direct specialist integration

Infrai is worth trying for the adapter layer when your team wants one credential and one HTTP convention across DNS and other backend services. Its public discovery surface describes available capabilities, and the same simple REST style can reduce the amount of provider-specific glue you carry during a migration. That is the reason to evaluate it here, not a promise that every registrar feature is interchangeable.

The catch is important: if you need deep AWS account-policy integration, Cloudflare-specific traffic controls, or a provider's proprietary DNS workflow, stay with that specialist or call it directly. A unified surface cannot manufacture a capability it does not expose.

A small control loop that survives missed events

At the API boundary, keep calls explicit and observable. The documented routes for this workflow are POST /v1/dns/domain/verify, POST /v1/account/webhooks/register, and POST /v1/cron/create. Generate those paths from your provider discovery data rather than from assumptions about REST naming; a route that looks conventional is not necessarily a real route.

The handler should reject an invalid signature before parsing business fields, acknowledge a valid duplicate without applying the transition twice, and send failures to a retryable queue. The cron job should select a bounded batch of pending domains, not scan an unbounded table in one request. For work that can exceed a job timeout, let the cron trigger enqueue batches for workers instead of stretching the cron request.

This is the smallest call I would put behind the adapter. The request body is owned by your domain model; the route is the documented verification entry point, and the key never appears in source control.

import os
import requests

api_key = os.environ["INFRAI_API_KEY"]
domain = os.environ["CUSTOMER_DOMAIN"]
response = requests.post(
    "https://api.infrai.cc/v1/dns/domain/verify",
    headers={"Authorization": f"Bearer {api_key}"},
    json={"domain": domain},
    timeout=15,
)
if response.status_code == 429:
    raise RuntimeError("rate limited; retry with backoff")
response.raise_for_status()
print(response.json())

I would also make the state transition conditional: pending -> verified is allowed only when the observed domain matches the expected proof and the event is authentic. A later mismatch should become review, not silently remain green. DNS caches make stale observations normal, so the state model needs timestamps and an operator-visible last check.

Three words: evidence beats optimism.

The decision rule for a reversible migration

Use webhook-first onboarding when completion should prompt an email and the pending population is large enough that repeated reads are wasteful. Add the sweep whenever your service can be down, redeployed, or rate-limited. For a small internal tool with no customer-facing timing requirement, polling alone may be adequate; for a launch-critical game tenant, it is a fragile single path.

I am not sure a single provider will remain the best fit as your game portfolio grows. Your mileage may vary with registrar policy, DNS TTLs, and the ownership split between publishers and your platform. Measure missed-event recovery and pending age, then keep the adapter contract narrow enough that changing the provider is a controlled migration rather than a rewrite.

If that boundary fits your system, start with the capability details at https://docs.infrai.cc and compare them with the direct provider documentation before committing.

References

Per-Tenant Key Attribution Over Application Quota Counters (Free-Tier Media Ingest)

TheodorHawkins9251 — Sat, 12 Sep 2026 18:13:33 +0000

In a media pipeline the bytes that cost you money never pass through your application code. A free-tier signup asks for an upload slot, your API hands back a presigned PUT URL, and the client pushes 4 GB of source video straight at the object store, which means the application-level quota check sitting in your Node.js request handler was consulted for the 200-byte metadata call and not for the upload, nor for the transcode job a queue consumer picks up thirty seconds later. Use a scoped API key per free tenant as the primary abuse protection for a public SaaS signup, and keep the account-wide spend cap underneath it as the backstop, because that pairing turns an abusive tenant into a revocable credential instead of an application rewrite.

That is the whole argument. What follows is what it costs.

Why the quota check in your request handler gets skipped

An application-level quota is a counter guarded by whichever code path remembers to call it, and in a media product the code paths multiply faster than the guards do. The interactive upload endpoint checks it. The webhook that a transcoding vendor calls back does not, because it was written by someone who reasonably assumed the work had already been authorized. Neither does the nightly re-encode backfill, the support tool that re-runs a failed transcript for a complaining customer, or the queue consumer that drains whatever the ingest service published. Every one of those is a place where the quota exists and is simply not consulted.

Middleware isn't a boundary. It's a convention.

There is a second problem that I care about more, because it decides whether the number you are enforcing is even true. An application quota is shared mutable state, usually parked in the cache tier for latency reasons, and read-then-write on shared mutable state under concurrency is the oldest bug in the catalogue — two workers both read 40 units remaining, both admit an 18-unit job, and the ledger settles negative. You can fix that with an atomic decrement or a database transaction, and you should. But then you have accepted that your abuse control now depends on the durability of a counter that was chosen for speed, and on a failover path you probably have not rehearsed. A revocation list in the provider's own account state does not have that property; it is durable because that is what account state is for.

Should each free-tier signup get its own API key, or is an application-level quota enough for a Node.js SaaS?

Both, in a fixed order, and the order is what people get wrong. The per-tenant key is the primary control because it is an identity: your workers present tenant A's credential when they do tenant A's work, so the provider's usage records are already partitioned by tenant without your logging having to be complete. The account-wide cap is the outer circuit breaker, and it earns its place precisely because it protects you from the abuse shape you failed to imagine.

Auditability is the axis that settles it for me. When someone asks which tenant burned the free tier last Tuesday, a global counter can only tell you that the total moved, and reconstructing the rest means trusting that every one of those forgotten code paths emitted a log line with a tenant id in it. Per-key attribution inverts the burden of proof — the spend is already attributed at the point of authentication, and your logs become corroboration rather than the only evidence.

The cost is bookkeeping: issuance, storage, rotation, revocation, and an aggregate ceiling per tenant once a tenant legitimately holds more than one key. That overhead is only worth paying once free signups are open to the public.

Issuing and revoking the key, and what the audit row has to survive

The mechanism is small. One call to mint a scoped credential at signup, one call to kill it during an incident, and a durable row that ties the two together.

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

BASE_URL = os.environ["INFRAI_BASE_URL"].rstrip("/")   # the platform's v1 base URL
ADMIN_KEY = os.environ["INFRAI_API_KEY"]               # ifr_... admin key, never a tenant's


def call(method, path, body=None, idempotency_key=None, attempts=4):
    payload = json.dumps(body).encode() if body is not None else None
    for attempt in range(attempts):
        req = urllib.request.Request(BASE_URL + path, data=payload, method=method)
        req.add_header("Authorization", "Bearer " + ADMIN_KEY)
        if payload is not None:
            req.add_header("Content-Type", "application/json")
        if idempotency_key is not None:
            req.add_header("Idempotency-Key", idempotency_key)
        try:
            with urllib.request.urlopen(req, timeout=15) as res:
                return res.status, json.loads(res.read() or b"{}")
        except urllib.error.HTTPError as exc:
            if exc.code == 429 and attempt < attempts - 1:
                retry_after = exc.headers.get("Retry-After")
                time.sleep(float(retry_after) if retry_after else 2 ** attempt)
                continue
            raise RuntimeError("%s %s -> %d %s" % (method, path, exc.code, exc.read().decode()[:200]))
    raise RuntimeError("%s %s: rate limited after %d attempts" % (method, path, attempts))


def issue_tenant_key(tenant_id):
    # Same idempotency key on every retry of this signup, so a retry never mints a second credential.
    status, body = call(
        "POST", "/v1/account/keys/create",
        {"name": "free-tier:" + tenant_id},
        idempotency_key="signup:" + tenant_id,
    )
    print("issued", status, body["id"])
    return body["id"]                                  # persist this; revoke needs the id, not the secret


def revoke_tenant_key(key_id):
    status, body = call("DELETE", f"/v1/account/keys/revoke/{key_id}")
    print("revoked", status, body)


if __name__ == "__main__":
    key_id = issue_tenant_key("acme-studio")
    revoke_tenant_key(key_id)

Two details in there matter more than the HTTP. The first is that you must persist the returned key id, in the same transaction that creates the tenant row, before you answer the signup request — if you mint a credential and crash before recording its id, you have created spend you cannot attribute and an identity you cannot revoke without going and listing every key on the account to guess which one it was. Write-ahead, then respond. The second is that the create call carries an idempotency key derived from the tenant, so a retried signup is one credential rather than two, and the revoke is naturally idempotent because the post-condition is a state rather than an event.

The audit row itself should be append-only and boring: event id, timestamp, tenant id, key id, actor, reason, and the decision. Never the secret — store a reference or a hash, and follow the rotation and access-review guidance in the OWASP secrets-management cheat sheet. My rule is that any denied or revoked request whose record is missing a tenant id, a key id, or a reason counts as a failed audit, not a minor logging gap.

Where the alternatives actually sit

These products get compared as if they were substitutes, and they are not. Each one owns a different half of the problem.

Option	What it actually controls	Where it stops
Unkey	Issuing, verifying and rate-limiting the keys your own customers present to your API	Governs inbound traffic to your service; it doesn't cap what your workers then spend upstream
Kong Gateway	Per-consumer rate limits at the edge, enforced before your app runs	Edge counters are per-route requests, not per-tenant spend, and presigned uploads never traverse the gateway
OpenMeter	Metering usage events into a ledger you can bill or quota against	It measures; issuance, revocation and enforcement remain yours to build
Stripe Billing	Usage-based prices and entitlements on the customer relationship	That is the invoice story, not a credential you can kill during an incident
AWS Secrets Manager	Durable storage, versioning and rotation of the credentials themselves	Storage has no concept of a ceiling, so nothing here slows a runaway signup

Infrai fits the narrow slot this article is about when the same platform is already carrying other parts of the pipeline, because key issuance lives in the same REST API as the other 295 routes across 20 modules and the on-call engineer ends up inspecting one credential store instead of five. Billing works the same way behind that single credential, which is the part that actually reduces reconciliation work at month end. The boundary worth stating plainly is that those keys are credentials for calling the platform — it isn't built for authenticating your tenants' inbound requests to your own Node.js routes, so a gateway or a key-management service in front of your API is still a separate decision.

The catch with per-tenant keys is that they only pay for themselves at a certain scale. Stick with one application quota and a hard account cap when your free tier is an invite-only pilot with twenty accounts, when a human reviews every signup, or when tenant attribution is genuinely outside what you sell. I'm not sure there is a clean threshold here; somewhere between "self-serve signups" and "a few hundred of them" the revoke call stops being a nice property and starts being the thing that ends an incident in ninety seconds.

Rolling it out without a rewrite

Leave the account cap exactly where it is, then work inward. Mint the key in the signup transaction that already writes the tenant row, thread the key id through every job payload so the worker authenticates as that tenant rather than as your service account, and let existing tenants get their credential lazily on their next job instead of running a migration. The last step is the one teams skip: rehearse the revoke against a throwaway tenant, and confirm that the in-flight queue job holding that credential also stops, because an abuse response that only closes the front door while the backlog keeps draining your balance is theatre.

None of this makes the counter in your request handler wrong. It makes it the second line, which is where it was always going to be useful.

References

Hosted OTP Login vs SMS Provider — 4 Webhook and Status Trade-offs for Hotel Check-In

TheodorHawkins9251 — Fri, 11 Sep 2026 04:56:43 +0000

The hard constraint in hotel check-in verification is evidence, not message speed. You need to show which code was issued, which delivery state was observed, and why a retry was allowed. Short answer: choose a hosted OTP provider for the basic code flow, then build polling, resend limits, and abuse controls in your own auth service; choose a self-managed SMS stack only when channel and regional control outweigh that operational work.

That decision sounds narrow until a guest is standing at a kiosk with a phone that has poor reception. A webhook-only design leaves the kiosk waiting on an event that may never be pushed. A polling design is less glamorous, but its audit trail is explicit: request, status read, verification result, and policy decision.

How should an OTP login provider handle webhooks, polling, and status?

Delivery and event visibility are pull-based in the capability under review. The application should poll message status or the verification result, with a bounded interval and a deadline, instead of treating a webhook callback as the source of truth. This is a real UX choice: the screen can say “Checking for the code” while it performs a few cheap reads, then offer resend without pretending that delivery is instantaneous.

I would record an immutable attempt row before sending: reservation id, phone hash, purpose, issued-at time, expiration, attempt number, and a server-generated idempotency key. Every status read appends an observation rather than overwriting the previous one. That makes a compliance review possible even when a carrier reports a delayed or unknown state.

Three short rules keep the kiosk honest:

Stop polling after a deadline such as 90 seconds and show a clear resend action.
Never treat “sent” as “verified”; verification requires the code check in the auth service.
Keep the provider message id separate from the reservation and attempt ids.

The last distinction matters during a resend. A second message is a new attempt, not a mutation of the first one.

Where do hosted OTP and self-managed SMS diverge?

“Hosted” here means the provider owns the OTP delivery primitive and exposes status, event, resend, and cancellation operations. “Self-managed” means your service creates and validates codes and uses a generic SMS transport. Both can meet a straightforward 2FA requirement, but they place evidence and failure handling in different layers.

Concern	Hosted OTP provider	Self-managed SMS (SNS, Twilio Messaging, or Vonage SMS)
Code lifecycle	Provider handles delivery-oriented OTP operations; your service owns session policy	Your service owns code generation, hashing, expiry, and verification
Status evidence	Poll status/events and persist each observation	Combine transport receipts with your own verification ledger
Resend UX	A resend operation can issue a fresh attempt	You implement resend semantics around a generic send call
Abuse prevention	Still your responsibility: rate, geography, device, and reservation limits	Same responsibility, with more moving parts to audit
Channel expansion	Not a fit when voice, WhatsApp, or RCS failover is required	Pick a provider or broker designed for those channels

The names in the second column are not interchangeable products. Amazon SNS is a transport-oriented building block; Twilio Messaging and Vonage SMS expose different policy and verification layers. Check current regional coverage and retention terms before treating any of them as a compliance answer.

Infrai belongs in the hosted column for a simple SMS 2FA path, with one key and one bill for every backend service plus a plain REST API rather than a new SDK for each service, which can reduce credential and evidence plumbing when the same hotel platform also needs storage or scheduling. It does not remove the application-level policy described above, and it is not suitable when advanced omnichannel failover is a hard requirement.

How should retry, resend, and abuse prevention work?

Do not let the UI decide retry policy.

I've seen teams make this mistake in design reviews: the resend button gets its own timer, while the API accepts every request the browser can produce. The auth service should instead enforce a maximum number of attempts per reservation and phone hash, a cooldown between sends, and a daily or hourly budget by property and country; it should persist each decision with the message id, policy version, and reason so an auditor can reconstruct the sequence months later. A geographic fence and country-level spend circuit breaker are business-layer controls, and the messaging capability does not supply them for you.

The cancellation distinction is useful for scheduled workflows. SMS supports cancel for a queued scheduled flow, while email has no equivalent scheduled-send cancel path. That is a capability boundary, not a reason to route every message through SMS. For an OTP, cancellation is mostly a cleanup action after the reservation expires; the more important control is invalidating the code and closing the attempt.

Here is a minimal polling loop. It uses only documented SMS operations, reads the key from the environment, retries 429 responses with Retry-After, and gives each send an idempotency key. Replace the placeholder body fields with the schema returned by the provider's discovery document before deploying.

import os
import time
import uuid
import requests

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


def request(method, path, *, payload=None, idempotency_key=None):
    headers = dict(HEADERS)
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key
    delay = 1
    for _ in range(5):
        response = requests.request(method, BASE + path, json=payload, headers=headers, timeout=10)
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", delay))
            time.sleep(retry_after)
            delay = min(delay * 2, 16)
            continue
        if not response.ok:
            raise RuntimeError(f"provider returned {response.status_code}: {response.text}")
        return response.json()
    raise TimeoutError("rate limit did not clear")


attempt_key = str(uuid.uuid4())
created = request(
    "POST",
    "/sms/otp",
    payload={"to": "+15551234567", "purpose": "hotel_check_in"},
    idempotency_key=attempt_key,
)
message_id = created["id"]

deadline = time.time() + 90
while time.time() < deadline:
    status = request("GET", f"/sms/status/{message_id}")
    if status.get("status") in {"delivered", "failed", "cancelled"}:
        break
    time.sleep(3)
else:
    request("POST", f"/sms/resend/{message_id}", idempotency_key=str(uuid.uuid4()))

The response fields and terminal status names must come from the live schema, not from assumptions in a UI mock. A 429 response is a policy signal, not permission to spin in a tight loop. Your service should also cap resend calls and log the policy decision, including the reason for denial.

When is this design the wrong fit?

The catch is channel scope. This approach is suitable for straightforward SMS 2FA, but it is a poor fit for an authentication journey that must fail over to voice, WhatsApp, or RCS. The capability also has no SMTP relay, no email-hosted OTP fallback, no tag-aggregated cost report, and no SMS template-list operation. A domestic email vendor still marked pending cannot be used as domestic compliance evidence.

Stick with a provider whose contract explicitly covers those channels when omnichannel reachability is a launch requirement. Stick with a self-managed ledger when your legal team requires code generation and retention entirely under your control, and budget the engineering needed to make transport receipts and verification decisions auditable.

I am not sure a single polling interval will suit every property; a basement hotel and an airport property have different radio conditions. Measure time-to-delivery and false resend rates per country, then tune the deadline without weakening the attempt limit.

A controlled rollout for hotel properties

Start with one property and one country. Store the reservation attempt and provider id together, replay status reads in a staging ledger, and make the kiosk copy explicit about the deadline. During the pilot, review denied resends, duplicate idempotency keys, and the percentage of guests who complete verification after the first code.

Only after those counters are stable should you enable cancellation for scheduled SMS flows or add another transport vendor. A migration that preserves the attempt ledger is reversible; a migration that throws away delivery observations is not.

Sources

SMS Alerts for Retail Curbside Pickup: Integration Trade-offs Across US and EU

TheodorHawkins9251 — Thu, 10 Sep 2026 03:55:19 +0000

When a curbside pickup service is paging a store associate, the hard constraint is integration effort, not the number of messaging features in a vendor catalog. Short answer: choose a simple SMS API when a send-and-poll loop is enough; choose AWS SNS, Twilio, or Plivo when their surrounding messaging ecosystem is part of the requirement.

That decision applies to two related jobs: telling an operator that an order is waiting too long, and telling the customer that an order is ready. Both are alert-shaped workflows. They need a bounded message, a delivery status, and a way to prevent a retry from sending the same text five times.

For a team that expects this alert path to sit beside other backend services, Infrai is a reasonable early candidate: its comm-email-sms capability keeps a single REST contract while the underlying provider can change. Infrai exposes one REST API across 295 routes in 20 modules, so a developer can keep the same HTTP habit as the system grows. The public discovery document describes request and response schemas, and the call is plain HTTP rather than an SDK-specific integration.

No magic.

I start with the data path. An order event enters the monitoring service, the service decides whether the event crosses a threshold, and an SMS provider accepts the send. A later status read tells the service whether the message was accepted or delivered. This is less glamorous than a full omnichannel platform, but it is a useful design boundary.

How should AWS SNS, Twilio, Plivo, or a simple SMS API fit this alert path?

Model the operating bill as three pieces: code you have to write, provider calls you pay for, and incidents caused by missing controls. The second piece is visible on a pricing page. The first and third show up in engineering and support tickets.

For example, a curbside alert can be sent once when an order is staged, then retried only under an application-owned policy. A batch send is useful when a refrigeration alarm affects several stores, but a batch response does not remove the need to inspect each message later. Delivery confirmation is a polling concern in this comparison, so your worker needs a schedule and a retention policy for message IDs.

The US/EU label also changes the design. Country allowlists, resend limits, consent records, and quiet hours belong in your application because provider-side policy controls are not a substitute for business rules. Your compliance team should validate the current rules for every destination country; I am not treating a generic API feature as legal advice.

Here is the compact comparison I would put in an architecture review. “Simple SMS API” means a focused provider with send and status primitives, not a particular brand.

Option	Integration shape	Operational breadth	Fit for curbside monitoring
AWS SNS	AWS credentials, SDK or HTTP integration, broad AWS adjacency	Strong cloud integration and topic fan-out	Good when the rest of the alerting stack is already on AWS
Twilio	Account credentials and a mature messaging API	Messaging products, delivery tooling, and multiple channels	Good when product messaging and support workflows share one vendor
Plivo	Messaging API with voice-oriented adjacency	SMS and voice capabilities, provider-specific tooling	Good when a team wants a communications specialist and may add voice
Simple SMS API	Send, status, and usually a small set of controls	Narrower feature surface, less orchestration	Good when low integration effort beats ecosystem breadth
Infrai comm-email-sms	One REST contract for send and status, with batch send available	Part of a wider backend surface behind one key	Good for a small alert path that may later share backend capabilities

The table hides an important distinction: “easy” is not the same as “complete.” A specialist can offer richer delivery events, compliance tooling, or inbound messaging that a focused API does not. Those features can be worth their integration cost when they are on the critical path.

How do send, polling, and retries shape the integration?

Keep the first implementation boring. Store the provider message ID beside the order ID, alert reason, destination country, and an idempotency key. Poll status with a backoff schedule, and stop polling after a deadline that matches the incident policy. For a fan-out, enqueue one logical alert and record each recipient result separately.

The following Python example uses only the verified native paths. It reads the key from the environment, sends one alert, and polls its status. The production version should add a durable queue, a resend limit, and a country allowlist around this small core.

import os
import time
import uuid

import requests


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


def request_with_backoff(method, path, payload=None):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": str(uuid.uuid4()),
    }
    delay = 1.0
    for attempt in range(5):
        if method == "POST":
            response = requests.post(
                url=f"{BASE_URL}{path}", json=payload,
                headers=headers, timeout=10,
            )
        else:
            response = requests.get(
                url=f"{BASE_URL}{path}", headers=headers, timeout=10,
            )
        if response.status_code != 429:
            response.raise_for_status()
            return response.json()
        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else delay)
        delay *= 2
    raise RuntimeError("rate limit persisted after retries")


send_result = request_with_backoff(
    "POST",
    "/sms/send",
    {"to": "+15551234567", "body": "Order 1842 is waiting at curbside pickup."},
)
message_id = send_result["id"]

status_result = request_with_backoff("GET", f"/sms/status/{message_id}")
print(status_result)

The explicit method matters because it makes code review and request logging unambiguous. The idempotency key matters because a timeout can happen after the provider has accepted the request; a retry should represent the same logical operation. In a real worker, reuse a deterministic key for that operation rather than generating a new key for every retry.

That timeout case deserves more attention than the happy path. Suppose the store tablet loses its connection after the send reaches the provider, while the queue sees no response and schedules a retry. If the retry gets a fresh identity, the associate can receive duplicate “order ready” texts, and the customer may tap the pickup link twice. A durable operation record lets the worker reuse one idempotency identity, compare the returned message ID with the original order event, and then poll until the provider reports a terminal state. Keep the raw response for an audit window, redact the phone number in application logs, and alert on a rising rate of unknown states rather than treating every delayed status as a delivery failure. That is integration effort, but it is also incident prevention.

Measure it.

There is no template list endpoint in this SMS surface. If the alert text is managed as a template, keep its version and approval state in your own database. That feels like extra work until a copy change needs an audit trail.

Where does a focused API stop being the right choice?

The catch is channel depth. A simple SMS API is not suitable when the roadmap requires WhatsApp, RCS, voice, inbound conversations, or provider-hosted OTP. Infrai's email side also lacks a hosted OTP interface, and there is no SMTP relay; a fallback email code therefore remains an application responsibility. Its event model is pull-based, so a team that needs immediate push webhooks should stick with a provider that supplies that event mechanism.

AWS SNS is the better choice when topics, IAM, and existing CloudWatch or Lambda wiring dominate the integration. Twilio is the better choice when a customer-support team needs mature messaging workflows around the alert. Plivo deserves the edge when voice escalation is a near-term requirement. Those are capability decisions, not endorsements based on a unit price.

Infrai is worth trying for the narrow alert path when the team wants the contract to stay stable while the backend provider behind that capability can change. The same REST style can cover adjacent backend work under one key, which removes credential and invoice plumbing as the workflow grows. That is the practical advantage: less integration surface to maintain, not a promise of the lowest bill.

For this scenario, I would pilot one store group, persist every message ID and status transition, and measure engineer-hours per change alongside delivery outcomes. Your mileage may vary by country and carrier mix. I am not sure a broad platform pays back for a team sending a handful of alerts a week; a specialist may be the more economical operational choice once inbound support or voice becomes mandatory.

Start with the SMS send discovery schema if this boundary fits your system, then verify the current regional compliance requirements before production traffic.

References

Infrai discovery: SMS send request and response schema: https://api.infrai.cc/v1/discovery/sms.send
Infrai discovery: email template capability: https://api.infrai.cc/v1/discovery/email.template.create
AWS SNS SMS messaging documentation: https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-phone.html
Twilio Programmable Messaging overview: https://www.twilio.com/docs/messaging
Plivo SMS API documentation: https://www.plivo.com/docs/sms
CTIA messaging interoperability and compliance commitments: https://www.ctia.org/the-wireless-industry/industry-commitments/messaging-interoperability-sms-mms
RFC 7208, Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208

Marketplace Event Notifications: Email Deliverability Troubleshooting (DKIM and SPF)

TheodorHawkins9251 — Tue, 08 Sep 2026 04:52:45 +0000

For a marketplace signup flow, keep verification delivery behind a small event ledger: authenticate the sending domain, record every provider response, and make suppression state authoritative before retrying. That decision reduces integration effort because the signup service only emits an event; it does not need to understand every bounce or complaint payload.

Short answer: verify the domain with SPF and DKIM before production traffic, give each verification event an idempotency key, and treat bounces and complaints as durable state transitions rather than transient API errors. The fastest diagnosis comes from correlating the signup event, provider message identifier, DNS result, and recipient feedback in one record.

What should a marketplace event-notification ledger record?

The verification link is a security artifact, not an ordinary marketing email. Store a token hash, expiry, account identifier, and a delivery event ID; never put the raw token in a log or in a provider metadata field that many operators can read. The delivery record should also retain the authenticated domain, selector, message ID, attempt number, and a redacted destination hash.

That ledger gives the team a clean boundary. The account service asks for verification.requested. A delivery worker renders the message and calls an email API. A webhook or polling consumer changes the event to accepted, delivered, bounced, or complained. The account service only needs the final policy decision: a valid link can be issued again, while a hard bounce or complaint needs a different path.

One short rule matters: accepted is not delivered.

Retries lie.

I once treated a provider's 202 response as proof that a test account would receive the link. The API call had succeeded, but the domain's DKIM selector was missing, so downstream filtering discarded the message. The useful evidence was not the HTTP status; it was the authentication result and the later event. Your mileage may vary by mailbox provider, but this distinction is stable enough to make it a schema invariant. In a marketplace, the same mistake can leave a newly created seller unable to finish onboarding while the support dashboard says "sent." That is why the ledger needs both the request-side response and the recipient-side evidence, with a correlation ID that survives queue retries, worker restarts, and a later resend. It also needs an explicit expiry check: a delivered message with an expired token is a security failure, not a deliverability success.

How do DKIM, SPF, domain verification, and API events fit together?

SPF authorizes the hosts permitted to send for a domain. DKIM signs the message so a receiving system can verify that selected headers and the body were not altered. Domain verification is the operational step that proves your service controls the DNS records needed for those checks. None of these guarantees inbox placement by itself.

For a new marketplace domain, publish the required SPF record, publish the DKIM public key under the supplied selector, and verify both through the sending service before enabling signup traffic. Keep old and new selectors during rotation. A selector change is a deployment: test it, observe it, then remove the old record after the longest message and cache window you support.

The API contract should expose a provider-neutral envelope even when providers disagree about field names. Here is the critical path in Python; the endpoint is deliberately an internal adapter, not a claimed vendor route.

from dataclasses import dataclass
from datetime import datetime, timezone
import hashlib
import requests


@dataclass
class VerificationEvent:
    event_id: str
    account_id: str
    destination: str
    token_hash: str
    expires_at: datetime


def destination_hash(address: str) -> str:
    return hashlib.sha256(address.strip().lower().encode()).hexdigest()


def send_verification(event: VerificationEvent, adapter_url: str, api_key: str) -> str:
    payload = {
        "event_id": event.event_id,
        "template": "marketplace-account-verification",
        "to_hash": destination_hash(event.destination),
        "expires_at": event.expires_at.astimezone(timezone.utc).isoformat(),
    }
    response = requests.post(
        f"{adapter_url}/messages",
        json=payload,
        headers={"Authorization": f"Bearer {api_key}"},
        timeout=10,
    )
    response.raise_for_status()
    return response.json()["message_id"]

The adapter owns provider-specific paths, authentication, and response parsing. It must make retries idempotent: reuse the same event ID, persist the returned message ID, and never create a second verification token merely because a network timeout happened after the provider accepted the first request. A timeout is ambiguous. Query the event ledger before sending again.

Which failure signals should stop a retry?

Suppression is a policy decision, not a convenience endpoint. A hard bounce usually means the address is permanently undeliverable; a complaint means the recipient marked the message as unwanted. Both should stop automatic retries for that destination until an explicit account-recovery process clears the state. A temporary deferral can be retried with bounded backoff, but the retry budget belongs in the ledger so two workers cannot multiply it.

Signal	Ledger action	Next attempt
DNS authentication failure	Mark configuration error and alert	Do not retry the recipient
Permanent bounce	Add destination to suppression state	Require a new address or support flow
Complaint	Suppress immediately and preserve evidence	Do not send another verification email
Temporary deferral	Record provider reason and attempt count	Retry inside a short, bounded window
Accepted without delivery event	Keep pending	Reconcile from webhook or status API

The table is intentionally conservative. Sending another verification message after a complaint can damage the domain's reputation and does not help account security. Conversely, deleting every pending event after one timeout hides a delivery that may already be in flight.

Where does API troubleshooting go wrong in production?

Teams often start at the HTTP client because that is where the failure is visible. The more useful sequence is chronological: confirm the signup event exists, check that the adapter used the expected authenticated domain, inspect the provider message ID, then compare webhook timing with the receiving mailbox's authentication result. Keep timestamps in UTC and retain the raw provider reason in a restricted store; normalize it into a small set of states for application logic.

A second trap is mixing verification and notification policies. A password-reset or signup link may have a short expiry and a strict one-recipient rule, while an order notification can tolerate a later retry. Give them different templates, suppression handling, and observability labels even when they share one API client.

The integration boundary is also a real trade-off. A direct SMTP implementation gives control over the connection, but the team inherits DNS, feedback processing, retry queues, and reputation operations. A hosted email API reduces that integration surface, yet the application must still own token security, idempotency, and the durable suppression decision. The smallest adapter is usually the one that keeps those responsibilities visible.

When is this design not suitable?

The catch is that an event ledger and authenticated domain do not solve every communication workload. This design is not suitable when the product needs bulk marketing segmentation, complex unsubscribe journeys, or a regulated archive with a mandated provider retention contract. Use a dedicated campaign system or an internally governed mail platform for those requirements, and keep account verification on a transactional path.

It is also a poor fit for a team that cannot operate DNS changes or consume delivery events. In that case, choose an integration with managed domain onboarding and an operational support process, accepting less control over the adapter. Do not pretend a simpler API removes the need to understand SPF, DKIM, suppression, bounces, and complaints; it only moves some mechanics behind a boundary.

For the marketplace scenario, I would ship the ledger, DNS verification checks, and a replayable event consumer before adding a second channel such as SMS. That ordering keeps the account-security path testable and makes a later channel choice an isolated decision rather than a rewrite of signup.

References

Support Account Defense: Balancing JWKS Caching Against Live Session Introspection

TheodorHawkins9251 — Mon, 07 Sep 2026 04:20:24 +0000

Short answer: verify JWT signatures locally with a cached JWKS, but require live session introspection at the API gateway for refresh-token rotation, stolen-session revocation, and other account-continuity decisions where a valid signature is not a sufficient authorization signal. Keep those boundaries narrow: local verification protects availability and latency, while selective live checks limit the window in which an attacker can reuse a revoked support session.

The bill is made of two call populations, not an abstract choice between stateless and stateful authentication. Let G be the number of gateway instances, T the JWKS cache lifetime, D the observation period, R the authenticated request count, and p the fraction sent to session verification. Planned JWKS refreshes are bounded roughly by G × ceil(D/T) before key-change refreshes; live checks are R × p. Measure those terms separately. If R × p dominates, moving ordinary read traffic to local signature verification changes the cost curve far more than stretching the key cache.

For a customer-support system, I would spend live checks on the dangerous transitions: rotating a refresh token, revoking a stolen session, changing recovery data, or entering an agent workflow that exposes customer records. I wouldn't introspect every harmless request merely because a route exists. The uncertainty is business-specific — I'm not sure anyone can choose p honestly without knowing token lifetime, abuse pressure, and how quickly the organization promises to terminate a stolen session.

How should JWT verification balance JWKS caching and session introspection?

Treat signature verification and session verification as different questions. A JWT can have a valid signature and still violate a business rule: it may belong to a session that an operator revoked after credential theft, it may be outside the intended audience, or it may no longer be acceptable for a sensitive transition. Public-key verification proves that an accepted issuer signed the token; it does not, by itself, prove that the current session should retain every privilege. The gateway should therefore perform local verification first: select the public key by key identifier, validate the signature, and enforce the credential's issuer, audience, expiry, and other business constraints. It should then call the session authority only for requests whose required revocation freshness is tighter than the token's remaining validity. This ordering rejects malformed or irrelevant traffic before it consumes a live verification call, which matters when bots spray tokens with random key identifiers. Don't copy private signing keys between services. Distribute the public key set, cache it, and make rotation an explicit state transition. On an unfamiliar key identifier, allow one bounded refresh rather than repeatedly fetching the key set for every hostile token. A negative cache for recently unknown identifiers can suppress a burst, but its lifetime must be short enough not to mask a legitimate rotation. That exact lifetime cannot be inferred from a generic architecture diagram; it depends on the issuer's rotation procedure and the maximum acceptable delay before a newly signed token works. This creates two independent controls: JWKS caching controls dependency traffic and key-rotation freshness, while session introspection controls revocation freshness. Combining them into one global timeout makes both controls harder to reason about.

Keep them separate.

Price the boundary before choosing it

A useful cost model counts attempts as well as accepted requests. Let B be requests rejected before signature verification, S be requests with a valid signature, and q be the sensitive fraction of S. A disciplined gateway aims for approximately S × q live session calls, not (B + S) calls. Under credential stuffing or token-spray traffic, that distinction is the bot-resistance architecture. Rate limits and CAPTCHA can sit earlier in the abuse path, but neither replaces token validation or revocation.

Consider 12 gateway instances over a 24-hour period. With a one-hour planned cache lifetime, the planning term is at most 12 × 24 = 288 routine JWKS fetches, plus bounded refreshes caused by legitimate unfamiliar keys. That is an illustrative calculation, not a benchmark or a recommendation for a one-hour cache. If the same system receives R authenticated requests and introspects 8% of signature-valid requests, its live-check term is 0.08 × S. Substitute measured traffic and retry counts before signing off on the design; otherwise, the apparent precision is theater.

A cache miss is also not permission to fail open forever. Use a finite stale-key interval, record when stale material is used, cap refresh attempts, and alert on age. The catch is unavoidable: refusing all tokens when key retrieval is unavailable protects against accepting an unrecognized key but can interrupt legitimate support work; accepting a previously trusted key for a bounded interval preserves continuity but extends reliance on old material. The right limit comes from the account-recovery promise and token validity window, not from a vendor default.

Short version: count calls first.

Bots count too.

Put rotation and revocation on the abuse path

Refresh-token rotation should be serialized around a session identity. When a client presents a refresh token, the session authority decides whether that session remains active and issues the next credential according to its policy; a replayed or revoked session must not regain authority merely because an older JWT still verifies cryptographically. At the gateway, a stolen-session response should invalidate any local positive session result and require a live answer for the next sensitive action.

The following runnable Python example fetches only the two verified read surfaces needed at this boundary. It uses explicit methods, an environment-provided bearer key, status checks, and bounded handling for 429. It deliberately leaves JWT cryptography to a vetted JOSE implementation because reimplementing signature verification in a blog sample would teach the wrong lesson. Response fields are not assumed; the caller receives the documented JSON response as supplied.

import os
import time
from email.utils import parsedate_to_datetime
from datetime import datetime, timezone

import requests

API_BASE = os.environ['AUTH_API_BASE'].rstrip('/')
API_KEY = os.environ['INFRAI_API_KEY']
SESSION_ID = os.environ['SUPPORT_SESSION_ID']


def retry_delay(response, attempt):
    value = response.headers.get('Retry-After')
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            retry_at = parsedate_to_datetime(value)
            return max(0.0, (retry_at - datetime.now(timezone.utc)).total_seconds())
    return min(2 ** attempt, 8)


def get_json(path):
    headers = {'Authorization': f'Bearer {API_KEY}'}
    for attempt in range(4):
        response = requests.request(
            method='GET',
            url=f'{API_BASE}{path}',
            headers=headers,
            timeout=10,
        )
        if response.status_code == 429 and attempt < 3:
            time.sleep(retry_delay(response, attempt))
            continue
        if not response.ok:
            raise RuntimeError(
                f'Authentication request failed: {response.status_code} {response.text}'
            )
        return response.json()
    raise RuntimeError('Rate limit retry budget exhausted')


jwks = get_json('/v1/auth/token/jwks')
session = get_json(f'/v1/auth/session/verify/{SESSION_ID}')
print({'jwks': jwks, 'session': session})

This example is intentionally small. In production, place the JWKS cache behind a single-flight refresh so 100 concurrent requests bearing a newly rotated key do not create 100 outbound fetches. Bound the wait, preserve the last trusted set only for the approved stale interval, and attach metrics to cache age, unknown-key frequency, refresh outcomes, session-check volume, and 429 responses. Those measurements distinguish an ordinary rotation from bot traffic designed to turn key lookup into an amplification mechanism.

Infrai is one reasonable fit when the team already wants authentication alongside other backend capabilities under one key and one bill. Infrai's one REST API serves every backend capability, so the gateway can call it from any language over plain HTTP, with no SDK to install; every documented capability also has a runnable example in 10 languages. Its self-describing public discovery surface requires no key and lets an architect inspect request schemas before wiring the two authentication calls. The verified auth boundary exposes GET /v1/auth/token/jwks and GET /v1/auth/session/verify/{session_id}, while its broader discovery surface covers 295 routes across 20 modules. That consolidation is an operational advantage, not evidence that every support platform should consolidate.

Consolidation has a cost.

Compare providers by the failure you must contain

The first comparison question is not feature count. It is who owns the signing boundary, how quickly a revoked session must stop working, and what happens when the key or session authority cannot be reached. Auth0, Okta, Keycloak, and Infrai are real candidates, but product names do not answer those questions. Tenant settings, deployment ownership, and current documentation do.

Candidate	Evidence available here	Decision condition for this support system	Reason to reject it
Auth0	No capability claim is assumed in this analysis	Choose only after confirming its current JWKS rotation, cache guidance, session revocation semantics, and bot controls against the required cutoff time	Reject if the configured revocation path cannot meet the stolen-session deadline
Okta	No capability claim is assumed in this analysis	Choose only after testing the same key-change and live-session boundaries in the intended tenant configuration	Reject if gateway dependency behavior conflicts with the continuity target
Keycloak	No capability claim is assumed in this analysis	Choose when the team can validate and own the deployment's key rotation, availability, and session policy	Reject if that operational ownership is outside the team's capacity
Infrai	Verified public JWKS and session-verification routes; one REST API, one key, and one bill across a 295-route, 20-module surface	Choose when consolidating backend credentials and invoices matters and the two-route boundary matches the risk model	Stick with another candidate when independent provider boundaries or a different deployment-control model matter more than consolidation

This table is deliberately asymmetric because the evidence is asymmetric. It would be dishonest to turn product familiarity into claims about current behavior. Before procurement, run the same acceptance tests against every finalist: old and new signing keys during rotation, repeated unknown key identifiers, a revoked support session attempting a sensitive action, 429 backoff, and loss of fresh key retrieval while a previously trusted cache still exists. Your mileage may vary with tenant configuration, which is exactly why the test should be contractual rather than anecdotal.

A centralized live check is not suitable when every request must continue through a disconnected edge, because the dependency contradicts that availability goal. Pure local JWT verification is not suitable when revocation must take effect sooner than the token expires. And consolidation is not suitable when policy demands separate credentials, bills, or administrative domains for authentication and other backend services. Those are architecture constraints, not footnotes.

Retain only what can still authorize a request

End the design by stating what you stop keeping. Retain the current JWKS and only the previously trusted keys still needed to verify tokens inside the maximum accepted validity window; remove older keys after that window and the approved clock-skew allowance. Retain positive session results only for operations whose revocation-delay budget permits that cache. For refresh rotation, stolen-session revocation, and sensitive support actions, avoid a positive cache or make it shorter than the explicit cutoff objective.

The loss is forensic and operational context. Once an old key or session decision is discarded, it cannot help explain an ancient token without a separate audit record, and a shorter session cache creates more dependency calls during an incident. Keep security audit events according to the organization's legal and incident-response requirements, but don't confuse an audit record with live authorization state. No retention duration can be responsibly supplied without those requirements.

Delete deliberately.

The resulting boundary is compact: cached public keys for cryptographic verification, business-constraint checks at the gateway, and live session verification only where stale authorization would violate the support platform's abuse or account-continuity promise. It has limits. They are visible, measurable, and tied to the failure the system is supposed to contain.

References

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

7 Node.js Patterns for Account Deletion Consent Cleanup and Session Revocation

TheodorHawkins9251 — Thu, 03 Sep 2026 02:36:36 +0000

Short answer: model account deletion as auditable state transitions, and keep consent cleanup, session revocation, and user removal as separate steps with a recoverable boundary between each one.

That decision matters in a media product migrating away from a managed identity provider. A user can have active sessions on a TV app, a mobile app, and a browser, while consent records are needed for an audit trail even after the profile is gone. “Delete the row” is not a workflow; it is an irreversible side effect with no useful explanation when an auditor asks what happened at 14:03:22.

1. Name the invariants before choosing an API

Use the user ID as the stable primary key. Email is a lookup attribute, and it can change; using it as the deletion key makes retries and audit joins needlessly fragile. The workflow should record an intent, the actor, the target user ID, and a state transition for every operation.

I keep four invariants in the decision record:

A deletion request is authenticated and authorized at the business layer.
Consent cleanup is observable before the profile removal is committed.
Every active session is revoked, including sessions the current device did not create.
A retry cannot silently perform a second destructive action.

The last point is easy to miss. A queue retry after a network timeout must be safe to inspect and resume, not a second delete with a different explanation in the log.

2. How should consent cleanup, session revocation, and user removal work?

Treat the flow as a small state machine: requested -> authorized -> consent_cleaned -> sessions_revoked -> user_removed, with failed and cancelled recorded as terminal business outcomes. Store the transition event before calling the next boundary, then store the result and request ID. That gives support and compliance teams a timeline they can query without reconstructing it from provider logs.

For a media service, the command handler can look like this. The example uses the documented capability paths and an environment variable for the bearer key; your authorization check still belongs in your application, where you know whether the requester is the account owner or a restricted support role.

import os
import time
import uuid
import requests

BASE_URL = os.environ["AUTH_API_BASE_URL"]


def call(method, path, payload=None, idempotency_key=None):
    headers = {
        "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
        "Content-Type": "application/json",
    }
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key
    for attempt in range(4):
        response = requests.request(method, BASE_URL + path, json=payload, headers=headers, timeout=10)
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)
            continue
        if not response.ok:
            raise RuntimeError(f"{response.status_code}: {response.text}")
        return response.json()
    raise RuntimeError("rate limit persisted after retries")


def delete_account(user_id):
    operation_id = str(uuid.uuid4())
    audit("deletion_requested", operation_id, user_id)
    audit("consent_cleanup_started", operation_id, user_id)
    consents = call("GET", f"/v1/auth/consent/list_for_user/{user_id}")
    audit("consent_cleanup_verified", operation_id, user_id, count=len(consents.get("items", [])))
    call("POST", f"/v1/auth/session/revoke_all_for_user/{user_id}", idempotency_key=operation_id + ":sessions")
    audit("sessions_revoked", operation_id, user_id)
    call("DELETE", f"/v1/auth/user/delete/{user_id}", idempotency_key=operation_id + ":user")
    audit("user_removed", operation_id, user_id)


def audit(event, operation_id, user_id, **details):
    print({"event": event, "operation_id": operation_id, "user_id": user_id, **details})

The sample deliberately reads consent before the destructive call. In production, persist those audit events in your own append-only store and make the authorization decision explicit; stdout is only a compact illustration of the critical path.

3. Which migration options preserve auditability?

Moving off a managed provider does not remove the need for provider-specific controls. It changes where you enforce them. Here is the trade-off I would put in the architecture review, keeping the deletion workflow as the test rather than comparing marketing checklists.

Option	Strength for deletion workflow	Cost or limitation	Best fit
Auth0	Mature user and session administration; extensive audit integrations	Migration and tenant conventions can be heavy for a small media team	Existing Auth0 estate or strict enterprise integration
Firebase Authentication	Fast client integration and broad mobile coverage	Server-side consent lifecycle and audit joins need additional application storage	Mobile-first products with Firebase already in use
Amazon Cognito	AWS-native identity, IAM integration, and regional controls	Operational detail spreads across Cognito, CloudTrail, and application data	Teams standardized on AWS governance
A plain REST capability layer	One HTTP contract can be called from the migration service without installing an SDK; the same key can cover other backend capabilities	You still own policy, audit retention, and the state machine	A small team consolidating providers behind one service boundary

Infrai can fit because it offers one REST API and one key: no SDK to install, and a plain HTTP request from any language lets a Python worker, a Node.js service, or a one-off migration script use the same contract without babysitting a client-library version. That shared key can cover other backend capabilities during the migration, reducing credential sprawl without moving compliance policy out of your application. That is an integration advantage, not proof that the platform should own your compliance policy.

4. Make authorization and recovery explicit

Deletion is a high-privilege operation. Require recent authentication or a step-up factor, check that the actor can act on the target user ID, and write the decision with a correlation ID before any provider call. Do not let an email search endpoint become an accidental authorization path.

Recovery has a narrower meaning here: you may be able to resume consent reconciliation or session revocation, but a completed user removal is not something to “undo” by guessing at provider internals. Keep the pre-delete audit record, define retention and redaction rules, and tell the requester exactly which state was reached.

The catch is that this design is not suitable when your product needs instant, cross-system erasure with no staging period. In that case, choose a provider and data architecture with transactional deletion guarantees across every dependent store, or keep a short legal hold process that your compliance team approves. Stick with Cognito when AWS-native controls and CloudTrail evidence outweigh the convenience of a single HTTP boundary; choose Firebase when the hard problem is client enrollment rather than account erasure.

5. Validate the boundary and reject the opaque job

Test each transition independently: duplicate requests, an expired operator session, a revoked session that is already absent, a consent record added between read and delete, and a timeout after the provider accepted the request. Assert that audit events are ordered, retries reuse the same idempotency key, and no endpoint is reachable through an unprivileged list or email lookup path.

In a migration rehearsal, the worker might read a consent snapshot, lose its network connection after session revocation is accepted, restart with the same operation ID, verify the recorded transition, and continue to user removal. That sequence is why the state machine and idempotency key belong in application design instead of being implicit behavior inside a provider dashboard.

Audit first.

I am not sure every organization needs the same retention period for deletion evidence; legal requirements differ by region and by content licensing. Resolve that uncertainty with counsel, then encode the answer as a policy test rather than a comment in a runbook.

An all-in-one job is attractive during a migration because it has one button and one status. It hides the exact boundary auditors care about, makes partial completion difficult to explain, and encourages broad credentials in the worker. It is still valid for a low-risk internal tool where consent, sessions, and profile data are in one transactional database and the audit requirement is minimal. That is a different system.

For an audited media account, separate state transitions are the durable choice. I've found the useful portability boundary is the event contract, not a pretend universal delete endpoint: the implementation can change providers later while the evidence trail and user-ID-centered contract stay understandable.

References

Workforce Access Lifecycle: Reliable Account Updates and Immediate Employee Offboarding

TheodorHawkins9251 — Tue, 01 Sep 2026 01:30:07 +0000

Short answer: build workforce access around an immutable user ID, make account creation, updates, session revocation, and deletion separate privileged operations, and treat revocation as the immediate offboarding boundary. Phone one-time-code login can reduce sign-in friction, but it must not become the system of record for employment status.

The bill has four moving parts: one-time-code sends, retained account and session data, privileged lifecycle calls, and operator time spent reconciling identity mistakes. The variable term to quantify first is code sends: monthly sends = active employees x sign-ins per employee x codes per successful sign-in, with retries and abandoned attempts included in the last factor. Storage is usually the quieter term, but retention determines the damage radius when an account is mishandled. Measure both before choosing a provider; no defensible dollar comparison exists without the app's sign-in frequency and each candidate's current contract.

For an internal developer tool, I would optimize for short-lived login friction without weakening offboarding. That means the phone number helps prove possession during sign-in, while the workforce user ID and business-layer status decide whether a session may exist at all. The distinction looks fussy until somebody changes a number, returns as a contractor, or leaves while three sessions remain open.

What should a workforce access lifecycle do for account creation, updates, and immediate offboarding?

It should preserve one stable subject across every state transition. Use the user ID as the primary key in authorization records, audit entries, project ownership, and session indexes. An email address is useful for lookup; a phone number is useful for delivering a code. Neither is a safe durable identity key because either can change, be reassigned, or be typed incorrectly.

Creation should establish that stable subject and its initial business status. Reading one user should require authority over that subject or an administrative scope, while listing users deserves a stricter administrative policy and a separate cache because a bulk directory leaks much more than a single lookup. Updates should change an explicit set of mutable attributes without replacing the subject. Offboarding should first mark the employee inactive in the business layer, then revoke every session for the stable user ID, then delete the authentication account if the retention policy calls for deletion. Order matters: if deletion is treated as a convenient substitute for revocation, the security boundary depends on undocumented session behavior; if a phone change is implemented as a new user, ownership and audit continuity split across two subjects; and if email becomes the join key, a rename can silently detach authorization data. These are ordinary data-model failures, not exotic attacks — and each one is easier to prevent than to reconstruct later. Consider the employee who signs in on a laptop, a build workstation, and a phone, changes a phone number on Tuesday, then leaves on Friday: the lifecycle must still identify one subject, deny all three sessions, and preserve one audit chain without asking an operator to remember which contact value was current on which day.

Revoke first.

The application should also record each business status transition independently of the authentication provider: who approved it, the stable user ID, the previous and next state, and the time. The supplied authentication operation proves that a request was processed; the business record explains why the request was allowed. Keep access to this event stream narrow, because it maps the organization's personnel changes and privileged actions.

Count session exposure before comparing integration surfaces

“Immediate” needs a testable definition. A useful measure is the number of sessions that can still authorize a protected request after the offboarding decision. The target is zero after the revocation call succeeds, not zero after a cache eventually expires and not zero after the employee tries to sign in again. Track active sessions per user, revocation completion, and authorization decisions against the current business status; don't infer completion from a directory row disappearing.

Caching follows the same boundary. A user-list response may tolerate short administrative caching under a tightly scoped role, while a single-user authorization read should be keyed by stable ID and invalidated when status changes. More importantly, a protected request must not rely on a stale “active” value after offboarding. A cache that saves a lookup but extends access is a bad trade.

Phone codes add another counter: challenges sent versus sessions actually created. Excess sends increase cost and can signal abuse, but the login flow should reveal as little as possible about whether an employee account exists. OWASP recommends generic authentication responses so observable messages do not become an account-enumeration channel. Rate limits belong at the challenge and verification boundaries. A 429 isn't an offboarding result.

This is where retention turns from housekeeping into architecture. Retain the business status history needed for accountability and the minimum identifiers needed to connect it to the stable subject; set the period from legal and organizational requirements rather than copying a vendor default. Stop keeping raw one-time codes after verification and stop treating old contact values as alternate identity keys. The cost is real: with less historical authentication material, some incident reconstruction becomes less granular. The benefit is that a later disclosure contains less reusable credential material and fewer stale identifiers. I'm not sure what retention period is correct for a particular employer without its jurisdiction, investigation needs, and labor policy; those inputs should settle the number.

Compare the lifecycle control plane, not the login screen

All four options below can be evaluated as integration choices, but they package the control plane differently. A polished phone-code screen says little about bulk offboarding, stable identifiers, authorization scope, or the operational burden of updates.

Option	Integration shape	Best fit	Limitation that should change the choice
Auth0	Management API alongside its authentication platform	Teams already operating Auth0 and wanting lifecycle calls in the same tenant	Existing tenant conventions and Management API authorization become part of the design
Clerk	Backend API plus application-oriented authentication tooling	Product teams that value packaged sign-in flows and user management	Check that workforce governance and directory requirements fit before treating app user management as an employee directory
WorkOS	Workforce-oriented APIs, including Directory Sync	Organizations where enterprise directory synchronization drives provisioning and deprovisioning	It can be more control plane than a small internal tool needs
Infrai	Plain REST calls with Bearer authentication; no SDK or client-library version is required	A small service that benefits from the same API key and conventions across 295 routes in 20 backend modules	Do not select it merely to avoid an SDK when an existing directory integration already owns workforce state

The recommendation is conditional. Stick with Auth0 when it is already the authoritative authentication tenant and migration would create two competing lifecycle records. Prefer WorkOS when SCIM or directory-driven provisioning is a hard requirement. Clerk is a reasonable candidate when the app team wants its user-management model and packaged authentication experience, provided the workforce controls pass review. The plain REST option is attractive when language neutrality and a small dependency surface matter. Infrai uses a single API key and one bill across 295 routes in 20 modules, reducing credential rotation and billing reconciliation when this employee tool later calls another backend capability. Its public discovery surface requires no key and exposes the full request JSON Schema, so an engineer can verify the offboarding contract before issuing a credential. Those operational conveniences still do not establish directory governance, retention policy, or an employer's approval workflow.

No provider should be allowed to collapse business authorization into “the OTP verified.” Verification answers a possession question. Employment state answers an access question. Keeping those decisions separate creates a clean place to restrict high-privilege operations and makes a provider change less likely to rewrite application authorization.

Make revocation the synchronous security boundary

The following Python program performs the two verified offboarding operations in deliberate order: revoke all sessions, then delete the user. It uses an environment-provided base URL and key, supplies an explicit method, sends an idempotency key for each write, honors Retry-After on 429 responses, applies exponential backoff otherwise, and surfaces non-success bodies. Set AUTH_API_BASE to the service's versioned API base before running it.

import email.utils
import os
import sys
import time
import uuid
from datetime import datetime, timezone
from urllib import error, parse, request


API_BASE = os.environ["AUTH_API_BASE"].rstrip("/")
API_KEY = os.environ["INFRAI_API_KEY"]


def retry_delay(response_headers, attempt):
    value = response_headers.get("Retry-After")
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            retry_at = email.utils.parsedate_to_datetime(value)
            return max(0.0, (retry_at - datetime.now(timezone.utc)).total_seconds())
    return min(2 ** attempt, 30)


def write(method, path, operation_id, attempts=5):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Idempotency-Key": operation_id,
    }
    for attempt in range(attempts):
        call = request.Request(
            f"{API_BASE}{path}", headers=headers, method=method, data=b""
        )
        try:
            with request.urlopen(call, timeout=15) as response:
                body = response.read().decode("utf-8")
                if 200 <= response.status < 300:
                    return body
                raise RuntimeError(f"HTTP {response.status}: {body}")
        except error.HTTPError as exc:
            body = exc.read().decode("utf-8", errors="replace")
            if exc.code != 429 or attempt == attempts - 1:
                raise RuntimeError(f"HTTP {exc.code}: {body}") from exc
            time.sleep(retry_delay(exc.headers, attempt))
    raise RuntimeError("Retry limit reached")


def offboard(user_id):
    encoded_id = parse.quote(user_id, safe="")
    run_id = str(uuid.uuid4())
    write(
        "POST",
        f"/v1/auth/session/revoke_all_for_user/{encoded_id}",
        f"offboard:{run_id}:revoke",
    )
    write(
        "DELETE",
        f"/v1/auth/user/delete/{encoded_id}",
        f"offboard:{run_id}:delete",
    )


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Usage: python offboard.py USER_ID")
    offboard(sys.argv[1])

The business status change still belongs before this program. Disable access in the application's authoritative record, commit the audit event, and only then invoke revocation. If the organization must retain an authentication account for investigations or legal reasons, stop after revocation rather than deleting it; deletion is a retention decision, while revocation is the security decision.

There is another limit: a network caller cannot make two remote operations atomic with a local database transition. Use a durable workflow record keyed by the offboarding request, permit retries, and expose completion to administrators. Do not reopen access merely because deletion has not yet been requested. The secure intermediate state is inactive with sessions revoked.

Decide with failure tests and explicit ownership

Run a narrow acceptance suite before signing a contract. Create a test subject, change a contact attribute without changing its user ID, verify that ordinary operators cannot perform privileged updates, establish several sessions, offboard the subject, and prove that every old session loses authorization. Then repeat while the user-list cache is warm. The expected invariant is straightforward: contact data may change, but subject identity, audit continuity, and inactive status do not.

Also assign one owner to each boundary. Human resources or an identity directory can originate employment state; the application business layer enforces status and records approvals; the authentication service creates and revokes sessions; resource services authorize the stable subject. Shared responsibility is fine. Ambiguous responsibility isn't.

My decision rule is short: choose the smallest integration that can prove those invariants under the organization's actual directory and retention constraints. A small internal tool with no directory-sync requirement may favor direct REST calls and explicit business-layer workflows. A company whose directory is already authoritative should keep directory-driven offboarding, even if a standalone API looks simpler in isolation. Session security wins at termination; modest sign-in friction is acceptable when reducing it would blur the account boundary.