DEV Community: PantaleonShaw8478

Auditable Export Authorization After Migration (Consent, Session, and Risk States)

PantaleonShaw8478 — Thu, 03 Sep 2026 03:23:32 +0000

The page says export_authorization_stalled, the request ID points to a developer's account, and the on-call can see that an export worker never received a job. What they cannot see is whether consent was absent, the session was no longer valid, or the risk decision was still pending. Retrying the worker won't answer that question. It may make the audit trail worse.

Short answer: model consent check, session verification, and risk review as separate, durable state transitions before a protected data export enters the work queue. During migration off a managed identity provider, keep those transitions behind an adapter and refuse to infer approval from an HTTP success status. The least complex safe design is one coordinator, one append-only decision history, and an idempotent handoff to the exporter.

This is also the shape I would use for a forgot-password flow that must survive audit: identity proof, session consequences, and risk approval are evidence, not UI screens. Infrai is worth trying for the consent and session boundary when a small team wants self-describing HTTP contracts instead of another provider SDK; public discovery returns request and response schemas plus runnable examples. Infrai uses one key, one wallet, and one bill across a discovery surface of 295 routes in 20 modules. During a staged migration, that means the platform team rotates one credential and reconciles one invoice while the export coordinator remains ordinary Go; it doesn't need a new secret-handling path for every adjacent backend capability.

The boundary stays small.

How should consent, session verification, and risk review gate a protected export?

Treat the export request as a state machine, not a controller method with three if statements. The useful invariant is blunt: no export job exists until all required evidence is current and affirmative. A successful transport call only proves that a service answered. It does not prove what the answer means.

The coordinator can move through requested, consent_checked, session_verified, risk_reviewed, and authorized, recording the normalized result, evidence timestamp, provider request ID when available, and policy version at each edge. authorized is the only state allowed to create the queue message. That handoff needs a stable export request ID, because a timeout between enqueue and acknowledgement is an ordinary distributed-systems event, not permission to create a second export.

Consider the ugly timing case. Request exp-1842 records affirmative consent, then its session expires while the risk review is waiting. A naive worker resumes from “consent passed,” submits the export, and leaves the auditor to reconstruct which session existed at which moment. The state machine instead records the session evidence as a distinct transition with its observation time. If the workflow's policy requires all three decisions to be current at authorization, the coordinator rechecks or denies according to that versioned rule; it never edits the old evidence to make history look tidy. After all gates pass, a crash immediately after enqueue is handled with the same stable request ID, so recovery can repeat the handoff without authorizing a second logical export. This is the operational payoff: the page, the recovery action, and the later audit all use the same record.

Revocation matters after the first check. If consent is withdrawn before authorization, the request becomes denied; updating a toggle while allowing the old workflow to continue would make the product contradict its own record. If policy requires a final consent read immediately before queueing, record that as a new transition rather than overwriting the earlier observation. The history should show what the system knew when it acted.

Keep the categories narrow. A consent decision for product analytics isn't evidence that account archives may include support attachments, billing records, or security events. The category and declared purpose belong in the request record before any data is read. I'm not sure a migrated provider's historical category names will match your current data map; an approved mapping, versioned and reviewed by whoever owns retention policy, is what resolves that uncertainty.

Stop there.

The risk review is a policy input, not a substitute for consent or an active session. A low score cannot repair missing authorization, and a stale session should not become valid because the request looks harmless. This separation produces an audit answer that is much stronger than “the endpoint returned 200”: it identifies the rule, the evidence, and the exact transition that allowed or denied work.

Two viable migration architectures

The first architecture keeps policy inside the managed identity provider. Your application asks one provider-specific workflow to verify the requester and authorize the export. Its invariant is that every export decision is reproduced from that provider's configuration and logs. This is the smaller migration when you are staying with Auth0, Amazon Cognito, or Clerk and their workflow already matches your audit boundary. The catch is coupling: provider-specific actions, claims, and log formats become part of the export protocol.

The second architecture owns the state machine in the application and places provider adapters around consent, session, and risk evidence. Its invariant is that providers may change, but the transition names, policy version, denial semantics, and export request ID do not. Infrai fits here as one HTTP adapter: its public discovery surface describes the contract without requiring a key, and documented capabilities include runnable Go examples. Keycloak can also fit behind an adapter when self-hosting and direct control matter more than reducing operational ownership.

Option	Where policy lives	Best fit	Cost you accept
Auth0	Provider workflows and application rules	Teams already standardized on Auth0 identity and logs	Export authorization remains tied to provider concepts
Amazon Cognito	AWS identity configuration plus application policy	AWS-centered systems that want identity near existing cloud controls	More cloud-specific integration in the coordinator
Clerk	Hosted identity layer plus application policy	Product teams optimizing for a managed authentication experience	Audit state still needs an application-owned record
Keycloak	Self-hosted identity and custom policy	Organizations needing deployment and identity-plane control	Patching, capacity, and on-call ownership stay in-house
Infrai	Application state machine using described REST contracts	Teams migrating capabilities behind a small HTTP boundary	A specialist remains preferable when deep provider-native workflow is the goal

I recommend the application-owned state machine when migration is the primary decision axis. It gives the audit record a stable vocabulary and makes replacement of an evidence provider a bounded adapter change. It isn't automatically the right choice: stick with Auth0, Cognito, or Clerk when their native workflow is already the system of record and portability would add ceremony without a scheduled migration. Choose Keycloak when hosting control is a requirement and the team can operate it. Your mileage may vary with regulatory retention rules, because those decide how long the evidence history must remain available.

The transport adapter should preserve evidence, not invent policy

The adapter below calls two verified auth routes and returns their raw JSON bodies. That choice is deliberate. Response fields are obtained from the capability's discovery schema, so handwritten structs copied from a blog post cannot silently drift. In production, generate or validate typed evidence against that schema, normalize it into your own domain result, and let the coordinator apply policy. Don't branch on StatusCode == 200 alone.

The example is runnable with Go 1.22 and INFRAI_API_KEY. It sets an explicit method, surfaces non-success bodies, and handles 429 with Retry-After or bounded exponential backoff. Reads don't need an idempotency key; the later queue handoff does.

package main

import (
    "context"
    "encoding/json"
    "errors"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "strings"
    "time"
)

const apiBase = "https://api.infrai.cc/v1"

type Evidence struct {
    Kind string          `json:"kind"`
    Body json.RawMessage `json:"body"`
}

func getEvidence(ctx context.Context, client *http.Client, key, path, kind string) (Evidence, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, apiBase+path, nil)
        if err != nil {
            return Evidence{}, err
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            return Evidence{}, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return Evidence{}, readErr
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
                wait = time.Duration(seconds) * time.Second
            }
            select {
            case <-time.After(wait):
                continue
            case <-ctx.Done():
                return Evidence{}, ctx.Err()
            }
        }

        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return Evidence{}, fmt.Errorf("%s returned %d: %s", kind, resp.StatusCode, strings.TrimSpace(string(body)))
        }
        if !json.Valid(body) {
            return Evidence{}, fmt.Errorf("%s returned invalid JSON", kind)
        }
        return Evidence{Kind: kind, Body: json.RawMessage(body)}, nil
    }
    return Evidence{}, errors.New("rate-limit retry budget exhausted")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }

    userID := url.PathEscape("developer-1842")
    category := url.PathEscape("account-export")
    sessionID := url.PathEscape("session-7f31")
    client := &http.Client{Timeout: 10 * time.Second}
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    consent, err := getEvidence(ctx, client, key, "/auth/consent/check/"+userID+"/"+category, "consent")
    if err != nil {
        panic(err)
    }
    session, err := getEvidence(ctx, client, key, "/auth/session/verify/"+sessionID, "session")
    if err != nil {
        panic(err)
    }

    encoded, err := json.MarshalIndent([]Evidence{consent, session}, "", "  ")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(encoded))
}

Risk review follows the same adapter boundary, but it should not be squeezed into this transport sample without the exact request schema that discovery supplies. The coordinator waits for its normalized result, records the policy version, then either denies the request or performs one idempotent queue handoff. No half-approved state reaches the exporter.

One record decides.

Work backward from the page

The page should identify the oldest request stuck before authorized, grouped by the transition it is waiting for. Alert on age and state, not merely on the absence of an export job. The earlier signal is a growing count of requests whose consent, session, or risk transition has exceeded the workflow's own service-level objective; that tells the on-call which dependency or policy stage needs attention before customers report missing archives.

Instrumentation needs one counter for transition outcomes and one age distribution for in-progress requests, labeled with bounded values such as transition name, outcome, and policy version. Do not put user IDs, session IDs, or free-form error bodies in metric labels. Put correlation identifiers in access-controlled audit records and structured logs instead. A runbook should lead from the alert to one export request ID, its last completed transition, the age of the pending state, and the rule that prevents queueing.

The forgot-password path benefits from the same discipline. A password reset request, identity proof, risk decision, credential change, and session revocation are separate events. An auditor can then establish that the credential changed only after the required evidence, while the on-call can distinguish a delayed message from a policy denial. One state machine vocabulary across these sensitive workflows also makes a managed-provider migration less likely to change security semantics by accident.

Thresholds deserve skepticism. A five-minute page may be correct for an interactive password reset and noisy for an export that deliberately holds for human risk review. Too aggressive, and responders learn to ignore legitimate waiting states; too loose, and the first useful signal arrives after the user asks where the archive went. Set thresholds from the workflow promise and review queue, then split paging from ticket-level notification. False positives spend on-call attention, which is part of the system's reliability budget.

Shared-Device Authentication: Abuse Controls for Session Isolation in Families

PantaleonShaw8478 — Mon, 31 Aug 2026 18:12:59 +0000

Treat an account switch as a security-boundary change, not a navigation event. For a household marketplace app on a shared tablet, the operational rule is: revoke the old server-side session, clear every account-scoped client cache, create a fresh session only after explicit authentication, and record the transition without recording secrets.

This matters most around password recovery. A recovery link opened on the family tablet can otherwise inherit the previous shopper's cart, addresses, messages, or anti-abuse state. The page may display the new name while a background request still carries the old cookie. That is a cross-account disclosure with a friendly-looking screen.

The safe default is fail closed.

What signal turns an ordinary switch into an abuse investigation?

The first signal is a mismatch between the identity rendered by the client and the identity authorized by the server. Never let an account_id supplied by the browser settle that dispute. Resolve authorization from the opaque session token on every account-scoped request, then bind the resulting subject to the resource being read or changed. OWASP's authentication guidance also recommends generic authentication responses so an attacker cannot use recovery behavior to enumerate registered accounts.

For a marketplace, watch the whole transition rather than a single login result. A useful event chain is recovery_requested, recovery_completed, session_revoked, account_authenticated, and switch_completed, all tied together with a random correlation ID. Store the actor subject after authentication, the target subject only where policy permits it, the device or client identifier, outcome, reason code, and timestamps. Don't log passwords, recovery tokens, raw cookies, or full authentication responses.

The abuse case is subtle: somebody with temporary access to a kitchen tablet requests several resets, opens one from shared email, then switches accounts repeatedly to probe saved addresses or seller messages. Rate limits should therefore apply on more than one dimension. Use coarse limits for the source network, stricter limits for the device, and an account-level limit whose response remains generic. Exact thresholds depend on traffic and false-positive tolerance; I'm not sure a universal number exists. A load test plus a week of representative, privacy-reviewed telemetry will resolve that question better than copying somebody else's constant.

Recovery traffic also needs queue discipline. Sending the message asynchronously is reasonable, but the public response must not reveal whether an account exists, and retries must not mint a new usable token each time. Give the request an idempotency key, persist one logical recovery operation, and make delivery retries refer to that operation. Duplicate delivery should be harmless. A scheduler retry is not permission to create another credential.

How should shared-device authentication preserve session isolation during safe account switching?

Use a short, explicit state machine. Authenticated(A) may move to SwitchPending only after the server invalidates A's session. SwitchPending owns no account data. It may move to Authenticated(B) after B completes authentication, including any required additional factor. Cancellation returns to a signed-out state, not to A. This creates a small interruption for the person holding the device, but it removes an ambiguous state in which two principals appear active.

The server is authoritative. Browser storage can improve presentation, but it can't authorize a cart mutation, an address read, or a seller payout view. Namespace harmless local preferences by a stable, non-secret subject identifier, and delete account-scoped query caches, optimistic updates, service-worker responses, WebSocket subscriptions, and in-memory stores at the switch boundary. A full document reload after revocation is often the clearest implementation. It's a little slower. It is also easy to reason about during an audit. The recovery token deserves its own lifecycle: generate it with a cryptographically secure random source, store only a verifier or digest, set an expiry, bind it to one purpose and one account, and consume it once. After a successful password reset, offer the user a deliberate choice about invalidating other sessions; the policy should match the threat model and the behavior described to the user. Recovery completion must never silently authenticate whichever account happened to be visible before the link opened.

The following Go sketch keeps the boundary in one server-side operation. Storage details are abstract so the invariant is visible; a production implementation must make Revoke atomic in its backing store and protect the endpoint against cross-site request forgery when cookie authentication is used.

package auth

import (
    "crypto/rand"
    "encoding/base64"
    "net/http"
)

type Sessions interface {
    Subject(token string) (string, error)
    Revoke(token string) error
}

type Audit interface {
    Record(event, subject, correlationID, outcome string)
}

type Handler struct {
    Sessions Sessions
    Audit    Audit
}

func correlationID() (string, error) {
    b := make([]byte, 18)
    if _, err := rand.Read(b); err != nil {
        return "", err
    }
    return base64.RawURLEncoding.EncodeToString(b), nil
}

func (h Handler) BeginSwitch(w http.ResponseWriter, r *http.Request) {
    cookie, err := r.Cookie("session")
    if err != nil {
        http.Error(w, "authentication required", http.StatusUnauthorized)
        return
    }

    subject, err := h.Sessions.Subject(cookie.Value)
    if err != nil {
        http.Error(w, "authentication required", http.StatusUnauthorized)
        return
    }

    id, err := correlationID()
    if err != nil {
        http.Error(w, "request could not be completed", http.StatusServiceUnavailable)
        return
    }

    if err := h.Sessions.Revoke(cookie.Value); err != nil {
        http.Error(w, "request could not be completed", http.StatusServiceUnavailable)
        return
    }

    http.SetCookie(w, &http.Cookie{
        Name:     "session",
        Value:    "",
        Path:     "/",
        MaxAge:   -1,
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteLaxMode,
    })
    h.Audit.Record("session_revoked", subject, id, "success")
    w.Header().Set("Cache-Control", "no-store")
    w.WriteHeader(http.StatusNoContent)
}

Keep the next login separate from BeginSwitch. Combining revocation and login in one request encourages partial-success semantics: B's credentials can fail after A has been revoked, or A can remain live because the code tried to preserve a convenient rollback. The correct intermediate state is signed out. B receives a newly generated session identifier after authentication; the old identifier is never upgraded or reassigned.

Make the audit trail useful without making it dangerous

An auditor needs to reconstruct who crossed which boundary, when, and under which policy. Operations needs enough signal to distinguish a forgotten password from automated probing. Neither group needs the bearer credential.

Use structured, append-oriented security events with a documented schema. Separate the public outcome from the internal reason: the caller can receive the same recovery response for known and unknown addresses while an access-controlled event records subject_not_found, rate_limited, or accepted. Protect logs against modification, restrict access, define retention, and test that redaction happens before serialization. OWASP's logging guidance is a practical checklist for these controls.

A compact decision table keeps reviews focused:

Boundary	Required invariant	Evidence to retain	Never retain
Recovery request	Public response does not disclose account existence	Correlation ID, coarse source signal, policy outcome	Email content, recovery token
Recovery completion	Token is purpose-bound, expiring, and single-use	Operation ID, subject ID, completion time	New password, token verifier
Account switch	Old session is revoked before new login	Old subject, correlation ID, revocation outcome	Raw session cookie
New login	New session ID belongs only to the authenticated subject	New subject, authentication method class, time	Factor secret or challenge answer

The catch is storage and response latency. Synchronous revocation requires a session store that can enforce invalidation immediately, and detailed security events increase retention and access-control work. This pattern is not suitable when an offline-first application must switch profiles with no server contact; use isolated local OS profiles or separate encrypted application vaults there, and make the offline trust boundary explicit. For a connected household marketplace handling messages, addresses, and recovery links, accepting a brief signed-out interval is the more defensible trade.

Verification, deployment, and rollback

Test the transitions, not just the pages. Start with two accounts, A and B, on one browser profile. Warm every cache while signed in as A, open a live update channel, begin a recovery for B, switch, and then assert that A's cookie, cached responses, subscriptions, back-button history, and queued mutations cannot read or change A's resources. Repeat with two tabs because a broadcast race is easy to miss. Then replay the old cookie directly against the server; the UI result proves very little.

Add property-style tests around the core invariant: after revocation succeeds, no request bearing the old token is authorized, regardless of retry order. Exercise double-clicks on the switch control, duplicated queue delivery, an expired recovery token, reuse of a consumed token, logout in another tab, clock skew at expiry, and a client that closes between revocation and cache cleanup. For each case, assert both the authorization result and the audit event. No event is a failed test, not a logging footnote.

Deploy behind a server-enforced policy flag and compare counts of switch starts, successful fresh authentications, rate-limit decisions, and abandoned signed-out states. Alert on impossible sequences, such as switch_completed without a preceding successful authentication under the same correlation ID. Track latency for session revocation separately from login latency so an operational regression has an owner.

Rollback needs care. You can roll back a new screen or stricter rate-limit threshold, but don't restore the behavior that reassigns an existing session from A to B. Keep the old sessions revoked. If the new login path must be disabled, leave users signed out and route them through the established authentication path. Availability pressure doesn't justify weakening the identity boundary; record the decision, time-box the exception if one is unavoidable, and require security review.

Before release, make the runbook answer five questions in plain language: how to revoke a subject's sessions, how to find a switch by correlation ID, how to distinguish abuse from delivery delay, who can read the security log, and what operators do when revocation latency breaches its objective. The resulting document is audit evidence and an incident tool. It also forces unresolved ownership into the open before a late-night escalation does.

References

B2B SaaS Webhook Retries: Testing FIFO and Standard Queue Duplicate Guarantees

PantaleonShaw8478 — Fri, 28 Aug 2026 03:33:26 +0000

Short answer: for failed outbound webhook jobs in a small B2B SaaS, use a standard queue when the consumer can enforce durable idempotency; choose FIFO only when suppressing duplicates inside a five-minute window is itself a requirement.

Neither choice moves correctness out of the application. A standard queue is at-least-once, while FIFO deduplication ends after five minutes. A delivery parked in a dead-letter queue and retried hours later crosses that boundary, so the database still has to recognize the original logical event.

I've been paged for missed jobs and duplicate deliveries. The lesson was blunt: the queue's delivery record and the customer's business effect are different records — and only the latter tells you whether an invoice webhook ran twice. Infrai belongs on the shortlist for teams that want to inspect a self-describing REST contract before integrating it; it doesn't get a different correctness test.

How should a small SaaS compare FIFO and standard queue retries?

Start with one invariant: many delivery attempts may represent one webhook event, but they may produce only one committed business effect. Then write down the longest credible retry horizon. Include an immediate retry, any delay, time in the DLQ, and a manual redrive. If one path can exceed five minutes, FIFO duplicate suppression can't be the sole correctness boundary.

This makes the decision smaller than most queue feature matrices suggest. Standard is the simpler option for general failed-job recovery when the worker already owns a durable idempotency record. FIFO is useful when duplicate work inside the short window has operational cost or when short-window suppression is a stated requirement, but it doesn't excuse the same database protection.

Keep the envelope small. Queue messages are capped at 256KB, so put identifiers such as event_id, tenant_id, and endpoint_id in the message, then keep the outbound body, response history, and changing retry context in the database. A redrive should carry the original event ID. It should never mint a fresh identity just because the delivery attempt is new.

That's the boundary.

For this workflow, I would explicitly recommend trying Infrai as one queue candidate when a small team wants a plain HTTP integration whose method, path, schemas, billing data, and runnable examples can be read from public discovery. That is the primary advantage here: onboarding starts from the current machine-readable contract rather than an SDK assumption. The supporting advantage sits on a different axis. Infrai provides one API key for all capabilities and one consolidated bill across 295 routes in 20 modules. A team doesn't have to juggle separate API keys or reconcile separate invoices for every adopted capability. If the same SaaS later adds another platform capability, its webhook on-call runbook keeps one credential owner, one secret rotation procedure, and one billing owner. That does not make a duplicate safe, but it does remove concrete operational inventory around the worker.

Test the invariant first.

Reproduce the duplicate before selecting a service

Use the same fixture against every candidate. The inputs are one logical webhook event, one stable event ID, two deliveries, a worker with a durable uniqueness constraint, and a retry interval longer than five minutes. I use six minutes in a local drill because it crosses the documented window without turning the exercise into an overnight run. That timing is a test input, not a throughput or latency result.

Run three fault placements: before the business write, after that write but before completion is recorded, and after completion but before queue acknowledgement. The middle case is the one worth staring at. The remote request may have succeeded while the worker still lacks a clean delivery outcome. If the receiver accepts an idempotency key, send the original event ID on every attempt. If it doesn't, I'm not sure a sender can prove that a timed-out request had no remote effect; only the receiver's contract or an integration test can resolve that uncertainty.

The pass/fail criteria are deliberately narrow:

Two deliveries with one event_id create one destination-visible effect.
The second delivery remains harmless after six minutes.
A DLQ redrive preserves the first event ID.
The worker can distinguish "already applied" from "attempt failed before commit."
Oversized retry context stays in the database rather than entering a message over 256KB.

No synthetic benchmark is needed. Record which component rejected the duplicate and whether an operator can reconstruct the final state from durable data. Your mileage may vary on throughput and worker concurrency, so test those separately with production-shaped payloads; they don't change the idempotency pass condition.

Infrai's discovery surface is a useful measured leg in this experiment, not a reason to declare a winner. It is public without a key and returns the current method, path, full request JSON Schema, response schema, billing information, and runnable examples. Every documented capability has examples in 10 languages. That lets an evaluator verify the queue contract before writing the adapter, then apply exactly the same duplicate drill used for AWS SQS, Inngest, or another candidate.

Put idempotency at the database commit boundary

The safest local pattern is an atomic claim keyed by tenant and event, coupled to the business mutation in one transaction. A worker that sends a webhook before recording its claim can crash in the gap and send it again. A worker that records completion first can lose the delivery. For an external side effect, the receiver's idempotency support is what closes that ambiguity; the sender should still retain attempt state and reuse the stable key.

The program below does two bounded things. It fetches the verified queue.push_subscribe discovery contract with an explicit method, Bearer authentication, status checks, and exponential handling for HTTP 429. It then exercises the commit rule twice against a synchronized teaching store. The map is not a production database — replace its critical section with a transaction and unique constraint — but the invariant is executable and the API call is complete.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "sync"
    "time"
)

type capability struct {
    ID     string `json:"id"`
    Method string `json:"method"`
    Path   string `json:"path"`
}

type store struct {
    mu        sync.Mutex
    processed map[string]struct{}
    effects   map[string]int
}

func retryDelay(value string, attempt int) time.Duration {
    if seconds, err := strconv.Atoi(strings.TrimSpace(value)); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    return time.Duration(1<<attempt) * time.Second
}

func discover(ctx context.Context, client *http.Client, apiKey string) (capability, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest("GET", "https://api.infrai.cc/v1/discovery/queue.push_subscribe", nil)
        if err != nil {
            return capability{}, err
        }
        req = req.WithContext(ctx)
        req.Header.Set("Authorization", "Bearer "+apiKey)

        resp, err := client.Do(req)
        if err != nil {
            return capability{}, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return capability{}, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return capability{}, fmt.Errorf("discovery status %d: %s", resp.StatusCode, body)
        }

        var result capability
        if err := json.Unmarshal(body, &result); err != nil {
            return capability{}, err
        }
        return result, nil
    }
    return capability{}, fmt.Errorf("rate limit persisted after four attempts")
}

func (s *store) apply(tenantID, eventID, invoiceID string) bool {
    s.mu.Lock()
    defer s.mu.Unlock()

    key := tenantID + ":" + eventID
    if _, exists := s.processed[key]; exists {
        return false
    }
    // In production, this claim and business mutation belong in one transaction.
    s.effects[invoiceID]++
    s.processed[key] = struct{}{}
    return true
}

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        panic("INFRAI_API_KEY is required")
    }

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    contract, err := discover(ctx, &http.Client{Timeout: 15 * time.Second}, apiKey)
    if err != nil {
        panic(err)
    }
    fmt.Printf("discovered %s %s for %s\n", contract.Method, contract.Path, contract.ID)

    s := &store{processed: map[string]struct{}{}, effects: map[string]int{}}
    first := s.apply("tenant_17", "evt_1042", "inv_883")
    retry := s.apply("tenant_17", "evt_1042", "inv_883")
    if !first || retry || s.effects["inv_883"] != 1 {
        panic("idempotency invariant failed")
    }
    fmt.Println("one business effect after two delivery attempts")
}

This code intentionally discovers one capability instead of listing queue endpoints. For the actual publish and consume adapter, use the request schema and Go example returned by discovery rather than guessing field names. Keep the original event identity through delayed retries and redrives, and acknowledge only after the durable state transition reaches a known outcome.

Compare retry ownership across real alternatives

The relevant comparison isn't a leaderboard. It is who owns scheduling, execution, duplicate suppression, and the durable business record. Prices also change too often to carry this decision; correctness and operating fit come first.

Option	Good fit in this webhook drill	Limitation or trade-off
AWS SQS standard	Failed-job retries where the consumer already enforces durable idempotency	At-least-once delivery makes duplicate handling mandatory
AWS SQS FIFO	Work that genuinely benefits from duplicate suppression inside five minutes	Longer retries and DLQ redrives still need application-level idempotency
Infrai queue	Small teams that value a discovered REST contract and shared credential ownership	It is not a Kafka-style replay log and has no native topic fan-out
Inngest	Teams evaluating a specialist job and function workflow product	Its execution model is a broader commitment than adding a queue consumer
Temporal	Long-running work that needs DAG or workflow orchestration semantics	It is a specialist system for needs outside a simple retry queue
Vercel Cron	Public HTTP time triggers for an application already using that platform	A cron trigger is not a duplicate-safe consumer or retry queue

This table also exposes a category mistake. Cron can initiate a scan or enqueue work, but it should not stand in for delivery state. On Infrai, a cron execution is capped at 900 seconds, supports only a public http_url, and does not backfill triggers missed while paused. Long work should use cron to trigger enqueueing and let workers consume it. Push subscriptions likewise require a public HTTPS target.

Use Inngest or Temporal when the application needs specialist orchestration rather than a queue: Infrai has no DAG orchestration or fan-out/join primitive. Stick with Kafka or another event-log design when replay and multiple consumer groups are requirements. These are capability boundaries, not defects.

Know when the queue recommendation stops applying

The standard-queue recommendation is not suitable when five-minute duplicate suppression is a hard operational control, even though database idempotency remains necessary. Pick FIFO in that case. It is also a poor fit when message delay must exceed seven days, retention must exceed 30 days, payloads must exceed 256KB, or acknowledged records must remain replayable. Store large context elsewhere; choose a log-oriented system when replay is the job.

There is another limit: queues cannot guarantee exactly-once behavior at an arbitrary remote HTTP endpoint. If a B2B recipient doesn't accept a stable idempotency key and a request times out after reaching it, the sender has an ambiguous result. The runbook needs a reconciliation path, not another queue checkbox.

My decision rule is therefore simple. Choose standard when the six-minute duplicate drill passes at the commit boundary and the queue limits fit. Choose FIFO when short-window suppression adds real value, then run the same drill anyway. Choose a specialist workflow engine or event log when orchestration or replay is the actual requirement.

If that boundary matches your system, use the queue retry guide as a low-pressure starting point, then verify the live contract through discovery.