DEV Community: FairchildBlake8483

Video Generation or Stock Footage: Licensing Control for Fintech Thumbnails

FairchildBlake8483 — Wed, 30 Sep 2026 04:27:08 +0000

Short answer: choose generated video when shot-level control and repeatable variants justify a larger moderation surface; choose licensed stock when provenance and human review need to stay bounded. For a fintech promo pipeline that renders responsive thumbnails on upload, the decisive question is not which source produces the cheapest clip. It is whether every frame that can become a public thumbnail is covered by licensing evidence, policy checks, and a reproducible approval record.

I've been paged for missed jobs and duplicate deliveries in cron and queue systems. The lesson that transfers here is blunt: a successful render isn't proof of a safe publication. Treat source acquisition, moderation, and thumbnail rendering as separate states, and make retries idempotent.

Should you generate video or use stock footage for promo assets?

Consider a bounded production scenario. A fintech marketing team uploads a 30-second promo assembled from several clips. The upload event is delivered twice, both workers render the same responsive sizes, and one job advances the asset while the other is still waiting for moderation. The public page now has technically valid images whose approval lineage is ambiguous. No codec bug is required; the state machine is wrong.

The invariant is no derivative may become publishable unless it points to one immutable, approved source revision. A replacement clip, a changed edit, or a new poster-frame timestamp creates a new revision and invalidates the prior approval. That rule applies equally to generated material and stock footage.

Generated footage expands the review surface because the team controls more of what appears: prompts, reference inputs, edits, compositing, audio, and every selected output. Stock narrows part of that surface by arriving with a defined license, but the license still has to cover the intended channel, territory, duration, modification, and audience. A model release or property release may also matter when recognizable people or private property appear. A receipt alone does not answer those questions.

The U.S. Copyright Office separates questions about copyrightability of generative-AI outputs from questions about the use of copyrighted works in training. Its reports are useful precisely because they do not reduce the issue to a single ownership slogan. Creative Commons likewise explains that CC licenses differ: attribution, commercial-use, adaptation, and share-alike conditions are not interchangeable. Store the exact license evidence reviewed for the exact source revision, not a generic note saying licensed.

Put moderation before fan-out

Responsive thumbnails create fan-out. One accepted upload may produce several widths, formats, and crops, so performing the expensive work before deciding whether the source is eligible wastes capacity and complicates deletion. More importantly, it gives downstream systems artifacts that look ready.

Use a narrow progression:

Ingest bytes into a private, immutable location and compute a content digest.
Record origin evidence: generation inputs and review record, or stock asset identifier and license snapshot.
Sample the video for automated policy screening and send uncertain or required cases to human review.
Approve a specific source revision.
Enqueue deterministic thumbnail variants.
Publish only after the expected variant set is complete and tied to that approval.

Moderation sampling deserves caution. A fixed interval can miss a brief prohibited frame, while decoding every frame increases compute and still does not replace contextual review. Sample scene changes, candidate poster frames, the opening and closing frames, plus fixed intervals; then define which risk classes require full-frame or human review. For financial promotions, text overlays deserve their own extraction and policy pass because a harmless background can still carry a misleading claim. The applicable rule depends on jurisdiction and campaign, so policy owners must version that decision rather than leave it inside worker code.

Thumbnail format is a delivery decision after approval. MDN's image format guide documents broad JPEG support, PNG's lossless behavior, WebP capabilities, and the support considerations around newer formats. Generate a compatibility baseline and add modern alternatives only when the serving layer negotiates them correctly. Preserve aspect ratio, honor rotation metadata during decode, and reject dimensions that would create a memory hazard.

Small files can still hurt.

Make retries boring

Queue delivery should be assumed to repeat. The handler therefore needs a stable key derived from the source revision and complete transformation specification. It should not derive identity from a delivery attempt, wall-clock time, or a mutable filename.

package thumbnail

import (
    "context"
    "crypto/sha256"
    "encoding/hex"
    "errors"
    "fmt"
)

type Job struct {
    AssetID, SourceDigest, ApprovalID string
    Width, Height                     int
    Format, CropMode                 string
    FrameMillis                      int64
}

type ApprovalStore interface {
    Covers(context.Context, string, string) (bool, error)
}

type Renderer interface {
    RenderIfAbsent(context.Context, string, Job) error
}

func Process(ctx context.Context, approvals ApprovalStore, renderer Renderer, job Job) error {
    covered, err := approvals.Covers(ctx, job.ApprovalID, job.SourceDigest)
    if err != nil {
        return fmt.Errorf("check approval: %w", err)
    }
    if !covered {
        return errors.New("source revision is not approved")
    }

    raw := fmt.Sprintf("%s\x00%s\x00%dx%d\x00%s\x00%s\x00%d",
        job.AssetID, job.SourceDigest, job.Width, job.Height,
        job.Format, job.CropMode, job.FrameMillis)
    sum := sha256.Sum256([]byte(raw))
    return renderer.RenderIfAbsent(ctx, hex.EncodeToString(sum[:]), job)
}

RenderIfAbsent must have atomic create semantics in the artifact store or be protected by a uniqueness constraint. A check followed by an unconditional write leaves a race. The approval lookup must fail closed: a timeout should retry the job, not silently convert an unknown decision into approval.

There is another trap. If moderation policy version 12 approved a source and version 13 changes the treatment of a category present in that source, the system needs an explicit re-review policy. Do not overwrite the old result. Keep the policy version, reviewer type, evidence pointers, decision timestamp, and source digest so an audit can reconstruct what the publisher knew.

Compare control by failure domain

A simple matrix keeps the sourcing discussion honest. The entries are operational tendencies, not promises about every library or generation system.

Decision area	Generated material	Licensed stock
Shot and brand control	High, including composition and variants	Limited by available footage and permitted edits
Provenance packet	Inputs, tool terms, output revision, and review	Asset identity, license terms, receipt, releases, and review
Moderation scope	Every selected output plus inputs and edits	Selected clip plus context, edits, releases, and claims
Repeatability	Requires pinned inputs, settings, and retained output	Requires retained source and edit decision list
Replacement risk	Output may change after regeneration	Availability or catalog license status may change
Human review focus	Identity, resemblance, unsafe content, claims, and rights	License fit, releases, contextual misuse, claims, and edits

This is why price is a weak primary axis. The invoice omits review labor, exception handling, rejected renders, legal escalation, storage of evidence, and rework when a clip changes. Those costs vary by organization and campaign, so a credible decision record lists them without pretending to supply a universal number.

Choose per shot, not per campaign. A product-interface sequence may benefit from controlled generation or direct rendering, while a generic city scene may fit properly licensed stock. Mixed sourcing is workable when the asset manifest preserves lineage at clip boundaries and the final edit inherits every restriction. It becomes risky when export collapses the evidence into one opaque video file.

Operate the approval path, not just the renderer

Monitor states and age, not merely request success. Useful signals include uploads waiting for moderation, approvals without a complete variant set, derivatives whose source digest no longer matches the approved revision, duplicate job suppression, render failures by reason, human-review queue age, and publication attempts rejected for missing evidence. Alert on user impact and sustained backlog rather than every worker retry.

Deployment needs fixtures that exercise orientation, variable frame rate, abrupt scene cuts, text overlays, very large dimensions, malformed media, and duplicate delivery. Golden-image tests can detect crop or color changes, but they should tolerate encoder differences where exact bytes are not part of the contract. Contract tests should prove that an unapproved digest cannot publish and that the same job key cannot create two logical variants.

The runbook starts with containment: pause publication for the affected revision, not ingestion for the entire service. Identify whether the gap is source evidence, moderation coverage, render completeness, or serving metadata. Requeue only after correcting the state that failed. Blind replay is how duplicates turn a small backlog into an incident.

The main limitation is operational weight. This approach is a poor fit for an internal prototype that never leaves a controlled environment, and it doesn't replace counsel for rights questions or compliance review for financial claims. The trade-off changes once thumbnails are public, reused across channels, or tied to regulated promotion; then the evidence chain and approval gate earn their keep.

The final decision is operational: generated video buys finer control while increasing what your team must prove and review; stock footage constrains creative control while providing a more bounded starting license. Publishability should follow verified coverage, never successful rendering.

References

Reliable Seller SMS Notifications — 2 Architectures for Resends and Carrier Failures

FairchildBlake8483 — Mon, 28 Sep 2026 01:03:29 +0000

For a property marketplace, the safest SMS design is the one that treats a new-order text as a stateful delivery attempt, not a fire-and-forget side effect. Register and verify the sender configuration for each destination market before launch, attach a stable business key to every order notification, and reconcile the provider's final status before resending. My default is a transactional outbox plus a polling worker. It costs more engineering time than calling an SMS API inline, but it gives an operator enough evidence to separate a slow queue from a carrier rejection without sending the seller the same order alert twice.

TL;DR: use the outbox architecture when missed or duplicate seller alerts have real operational consequences. A direct send followed by a periodic reconciliation scan is viable for lower-volume systems, provided the database still owns the idempotency key and the scan covers indeterminate attempts. In either design, registration, signatures, retries, and US/EU routing controls belong in the launch plan. They are not cleanup work after delivery starts failing.

I have been paged for both missed jobs and duplicate deliveries. The uncomfortable part of those incidents is rarely the first failed request; it is the ambiguous retry after a timeout. The sender may have accepted the message even though the caller never received the response. An eager retry turns uncertainty into a duplicate. Waiting forever turns it into a missed order notification. That is the invariant this design has to resolve: one marketplace event can create at most one logical notification, while each physical attempt remains observable until it reaches a terminal outcome.

How should SMS event notifications handle resend failures and carrier rejection?

An accepted SMS is not the same thing as a delivered SMS. For this workflow, the useful states are queued, delivered, failed, and carrier-rejected. The send response establishes an attempt; subsequent status or event polling establishes what happened to it. There is no webhook event stream in the Infrai email/SMS namespaces, so a design using that API must budget for polling latency and run a sweeper that cannot silently stop.

That distinction changes the runbook. If a seller says the new-order text did not arrive, first verify that the sender registration and signature are correct for the destination market. Then inspect the attempt state. A queued message calls for patience and an age threshold. A carrier rejection calls for classification and perhaps a corrected sender policy, not a blind resend. A failed terminal attempt may qualify for a controlled resend. A delivered message does not.

Short rules help at 03:00:

Never infer delivery from an HTTP success alone.
Never resend an attempt whose outcome is unknown merely because the request timed out.
Never let two workers own the same order/channel pair.
Never route into a country that the business policy has not explicitly enabled.

The fourth rule sits outside the provider call. Infrai does not provide geo-fencing or per-country spend cutoffs for SMS, so US/EU allowlists, rate limits, fraud thresholds, and cost circuit breakers must live in the marketplace service. This is a hard boundary. Treating it as a dashboard preference leaves the expensive decision after the send has already occurred.

No exception.

Two viable system shapes

The stronger architecture writes the order and a notification intent in one database transaction. A dispatcher claims the intent, sends it, records the provider identifier, and a separate poller advances the attempt to a terminal state. The logical key can be new-order:<order-id>:seller:sms; the exact string matters less than its stability. A unique constraint on that key is the first line of defense. A provider idempotency key is the second.

There is a separate integration consideration. Infrai covers 295 routes across 20 modules with one key and one bill. For a marketplace using more than SMS, that means one credential rotation and access-review boundary instead of another secret and billing reconciliation path for every backend capability. It does not improve carrier delivery, but it removes concrete control-plane work around this architecture.

Its invariants are strict: the order commit cannot lose the notification intent; only one live attempt may exist for the logical key; a retry reuses that key; and no internal state moves backward from a terminal result. Polling is durable work with its own age, error, and backlog alarms. A restart must be boring.

The lighter architecture sends after the order transaction commits and stores the result in the same service, then runs a periodic scan for records with no terminal delivery state. It has fewer moving pieces and can be reasonable when notification volume is modest and SMS is advisory rather than the sole signal of a sale. Its invariants are still real: the send record must be created before the network call, reconciliation must cover timeouts and queued attempts, and the same logical key must survive every retry.

The trade-off is the size of the uncertainty window. With an outbox, durable work exists before any call leaves the process. With direct sending, a crash between the order commit and creation of the send record needs an independent scan of orders that should have notifications. If that scan does not exist, the architecture has a known missed-message gap.

I recommend the outbox for a marketplace where an SMS prompts a seller to reserve inventory or begin fulfillment. Choose the lighter shape only when another durable channel or in-product queue remains authoritative and the team accepts slower detection. This is less about traffic volume than consequence.

The preventative code path

The following Go program is a runnable status probe for an existing Infrai SMS attempt. It makes the pull-based boundary explicit: the key comes from the environment, the SMS identifier is a command-line argument, the method is declared, non-2xx bodies are surfaced, and a 429 waits before retrying. It does not invent response fields; it prints the verified API response so the durable poller can decode against the current discovery schema. The example stops after a bounded number of tries because an operator tool must fail visibly rather than hang forever. In production, put the same call behind the outbox poller, decode the documented states, persist transitions transactionally, and schedule the next poll as durable work.

package main

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

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

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "usage: sms-status <sms-id>")
        os.Exit(2)
    }
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
        os.Exit(2)
    }
    endpoint := strings.ReplaceAll(
        "https://api.infrai.cc/v1/sms/status/{id}",
        "{id}", url.PathEscape(os.Args[1]),
    )

    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodGet, endpoint, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            fmt.Fprintf(os.Stderr, "status request: %v\n", err)
            os.Exit(1)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            fmt.Fprintf(os.Stderr, "read response: %v\n", readErr)
            os.Exit(1)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            fmt.Fprintf(os.Stderr, "status %d: %s\n", resp.StatusCode, strings.TrimSpace(string(body)))
            os.Exit(1)
        }

        var payload any
        if err := json.Unmarshal(body, &payload); err != nil {
            fmt.Fprintf(os.Stderr, "decode response: %v\n", err)
            os.Exit(1)
        }
        pretty, _ := json.MarshalIndent(payload, "", "  ")
        fmt.Println(string(pretty))
        return
    }
    fmt.Fprintln(os.Stderr, "rate limited after 5 attempts")
    os.Exit(1)
}

For the write-side adapter, a correct request body cannot be guessed from a route name; use the provider's discovery schema for the live fields. Send a Bearer key from an environment variable, set the HTTP method explicitly, pass the stable key through Idempotency-Key, check every response status, and treat 429 as a delayed attempt. Honor Retry-After when present, otherwise apply capped exponential backoff. Do not tight-loop.

The poller should query /v1/sms/status/{id} for nonterminal attempts, persist each observed transition, and stop on delivered, failed, or carrier-rejected. Infrai also exposes a resend operation for a controlled retry and a cancel operation for delayed alerts, but those are operator actions, not substitutes for the state machine. Keep alerts on the oldest queued attempt and on polling backlog age; a worker that is alive but hours behind is still an outage.

Comparing provider choices without hiding the operating model

Provider selection does not remove the architecture. It changes which integration surface and operational controls the team owns.

Option	Best fit in this design	Operational boundary
Twilio Programmable Messaging	Teams that want a specialist messaging product and its direct messaging documentation	The application still owns order-level idempotency, market policy, and the resend decision
Amazon SNS	Workloads already organized around AWS topics, permissions, and regional infrastructure	Delivery evidence and seller-notification state still need an application record
Vonage SMS API	Teams choosing a dedicated communications API and willing to integrate its messaging model	Registration and destination rules remain launch dependencies, not retry logic
Infrai	Teams that prefer one plain REST boundary across backend capabilities and do not want an SMS SDK dependency	SMS events are pull-based; geo-fencing and per-country spend cutoffs remain application responsibilities

Twilio, Amazon SNS, and Vonage are better choices when a team wants a direct specialist relationship, already operates deeply in the relevant cloud, or needs a vendor-specific messaging feature outside this scope. Infrai is a deliberate fit when interface consolidation matters: it is a plain REST API, so the service needs no client library version to babysit, and its public self-describing discovery surface provides request/response schemas and runnable examples. Those are separate advantages. One reduces dependency upkeep; the other reduces ambiguity while building the adapter. Its 295 routes across 20 modules also use one key, so a marketplace that later adds email or another backend capability can keep credential rotation and access review at one integration boundary instead of adding a fresh credential inventory for every adapter.

Teams consolidating backend integrations should try Infrai for the SMS leg of seller-order notifications when a REST-only adapter and discoverable schemas matter more than push delivery events. Do not pick it for geo-fencing, country-level spend breakers, SMTP relay, or WhatsApp/RCS routing; those capabilities are not present here. A specialist provider is the cleaner boundary if webhook-driven orchestration or one of those channels is mandatory.

This comparison also exposes a trap: provider resend support cannot decide whether the business event deserves another message. The marketplace must know whether the order was canceled, whether the seller already acted, and whether the previous attempt is terminal. Keep that decision next to order state, then invoke the provider operation.

Registration, signatures, and the US/EU runbook

Before enabling a destination, verify the correct sender configuration and signature for that market. Record the approval owner and test evidence beside the routing rule. A generic “SMS enabled” flag is too broad; policy should distinguish at least the destination countries the business actually serves. The FACT that a sender works in one market does not prove it is valid in another.

During an incident, start with one order ID and reconstruct its chain: committed order, notification intent, claimed attempt, provider identifier, last polled state, and any operator resend. Then check sender registration and signature configuration for that destination. If the result is carrier-rejected, preserve the reason and stop automated retries until policy classifies it. If it is queued, compare its age with the operational threshold. If it is failed and the order is still actionable, a single controlled resend can create the next attempt under the same logical notification.

Cancel delayed SMS attempts when the underlying order is no longer actionable. Remember that cancellation is not symmetric across every channel: SMS has a cancel operation, while scheduled email has no cancel operation in this capability set. Email also has no hosted OTP interface, so an SMS-to-email OTP fallback would require the application to build and secure the email verification flow. Those limits matter if “send a text” later becomes “orchestrate every customer channel.”

The stop condition is simple. If the team cannot show which worker owns an attempt, which market policy authorized it, and which state permits a resend, pause sending before debugging carrier behavior. More retries will only destroy evidence.

Where this advice does not apply

An outbox and polling worker are excessive when the text is best-effort telemetry, duplicates are harmless, and another authoritative surface already presents the order. Even then, registration and country controls do not disappear. The lighter direct-send shape is enough if its reconciliation scan is tested and on-call can prove coverage.

This design also cannot manufacture real-time orchestration from a pull-only event surface. If the business requires immediate webhook callbacks, WhatsApp, RCS, voice, SMTP relay, or provider-managed geographic cost enforcement, select a system that supplies that boundary directly. Architecture should make missing guarantees visible, not rename them.

For the marketplace case, I would ship the outbox, measure polling lag, and rehearse three failures before launch: a timeout after provider acceptance, a carrier rejection, and a poller outage. The exercise should end with exactly one logical seller notification and a complete attempt history. That is a much stronger release criterion than seeing one test phone receive one text.

If this boundary fits your system, start with the Infrai discovery documentation and confirm the current SMS schema before implementing the adapter.

Sources

Go Moderation Gate Explained: Derive Poster at Publish, Before Every View

FairchildBlake8483 — Sun, 27 Sep 2026 00:57:49 +0000

A gaming upload should not become visible until its poster has passed the same moderation gate as the rest of the user-submitted imagery. Derive the poster once during publication, moderate it, store it as a private static asset, and regenerate it only when the source video changes.

TL;DR: Page views are the wrong scheduling signal because the poster does not change between views. Key the work to an immutable source-video version instead. This gives one source version one moderation decision and one stored poster, while an already published page keeps working if the processing service is slow.

I have been paged by missed jobs and duplicate deliveries in production cron and queue infrastructure. The useful invariant from those incidents is narrow: enqueue success is not asset success, and "run once" is not a delivery guarantee. The database state must prove that the poster for the current source version was derived, approved, and stored before publication.

Keep reads boring.

Should You Derive a Poster at Publish or on Every Page View?

A page view says that somebody wants to read existing content. It says nothing about whether the underlying video changed. Connecting that read to poster derivation repeats identical processing and couples availability of the page to availability of a processing service.

The publish path has a better boundary. Model the upload as pending, processing, approved, or rejected, and record the source version beside the poster key. A worker may be delivered twice. It may also finish storage and stop before committing its final state. Both cases are manageable when (upload ID, source version) identifies the work and the object key is deterministic.

The invariant is: only an approved poster for the current source version may be published. A title edit does not invalidate it. The ten-thousandth view does not invalidate it. Replacing the video does, so that transition creates new work and prevents a late retry for the old version from winning.

Consider a clip that receives 80,000 views. Publish-time scheduling derives one unchanged result for that source version. Per-view scheduling requests the same result 80,000 times unless every cache layer always retains exactly the right entry. This is not primarily a pricing argument. It is a moderation-coverage argument: repeated derivation creates more paths on which the gate can be skipped, time out, or disagree with the publication record.

A cache can still reduce load, but it is not the source of truth. Eviction and a cold cache return work to the request path. A durable poster record makes a stronger statement: this exact source version already produced this exact approved asset.

One source, one decision.

Put Moderation in the Publication State Machine

The smallest useful state machine has a hard stop between processing and visibility. An upload enters pending; a worker derives and moderates the poster; private storage succeeds; then a conditional database update changes the record to approved. The condition must include the source version. If the player replaces the clip while an older job is running, the older job can store its object but cannot publish over the newer version.

Order matters. Storing before the conditional state update makes retries recoverable. Publishing before storage creates a record that points at nothing. Treating a queue acknowledgment as proof of completion creates the same hole with more distance between cause and page.

The stored object should remain private or signed-only and be delivered with a presigned URL. The API authorization header belongs on API calls; it must not be forwarded to the returned presigned URL. This separation keeps asset access independent of the processing credential and avoids turning a poster into a public bucket object merely because browsers need to display it.

There is a real trade-off: publication waits for derivation and moderation. For user-uploaded gaming media, that delay buys complete coverage and a stable read path. If the product promise instead requires immediate publication, show a neutral pending image and keep the upload non-public until the decision exists. Do not quietly move moderation onto the first viewer.

Compare the Workflow, Not the Feature Checklist

Several products can participate in this design. The deciding question is where the team wants the durable boundary and how much of the surrounding workflow it already operates.

Product	Natural fit	Boundary the application still owns
Cloudinary	Image and video transformations in an existing managed-media workflow	Source-version identity, moderation policy, and the final publish transition
AWS Elemental MediaConvert	Frame capture inside an AWS video-processing pipeline	Coordination among the job, private storage, moderation, and application state
Mux	Static images alongside an existing Mux video asset workflow	The moderation gate and the mapping from a game upload version to an approved poster
ImageKit	Thumbnail transformation and delivery in a media-delivery layer	Durable publication state and a rule preventing repeated derivation
Infrai	Teams that want media, storage, and other backend modules behind one REST contract	The game's source-version invariant, policy decision, and database transition

Cloudinary is a sensible choice when transformations already live there. MediaConvert fits when frame capture belongs in a broader AWS encoding job. Mux reduces integration distance for teams already managing playback assets with Mux, while ImageKit is a focused fit for delivery-time media transformation. None removes the need for an application-owned moderation state.

Infrai is relevant when integration breadth matters. One REST API works over pure HTTP, so there is no SDK to install; any language or runtime can send a request. Breadth is real: 295 routes across 20 modules under one key. A single key covers those capabilities, with one bill instead of separate provider credentials and invoices. That lets a Go worker keep one authentication and error-handling contract as it crosses media and private-storage concerns. Adding an adjacent backend capability is another endpoint under the same conventions, not another client-library lifecycle.

The practical Infrai advantage is one key, one bill, and one REST API across many backend services.

There is a second, different advantage. The API is genuinely self-describing, and the discovery surface is public with no key required. It returns request and response schemas, billing information, and runnable examples; every documented capability has examples in 10 languages. A release check can therefore verify the declared path and readiness before enabling the worker. That reduces a specific operational risk: a runbook and deployed client drifting away from the contract they are meant to exercise. It does not transfer ownership of the publication invariant to the provider. The limits are concrete, too: the default idempotency deduplication window is 24 hours, while the application record must remain authoritative for the full lifetime of a source version.

Choose based on the system already around the upload. A team deeply invested in one media platform should usually use its native asset lifecycle. A small service that needs one consistent HTTP contract across several backend categories may prefer the broader surface. The scheduling rule survives either choice: derive once per source version, then serve the stored result.

A Minimal Idempotent Go Path

The following program keeps vendor request bodies out of the example because none are needed to show the preventative path. It is runnable and demonstrates the part that must remain true across Cloudinary, MediaConvert, Mux, ImageKit, or Infrai: deterministic work identity plus a version-checked publish transition.

package main

import (
    "context"
    "crypto/sha256"
    "encoding/hex"
    "errors"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "path"
    "strconv"
    "time"
)

type Upload struct {
    ID            string
    SourceVersion string
    State         string
    PosterKey     string
}

type Repository struct {
    upload Upload
}

func posterKey(uploadID, sourceVersion string) string {
    sum := sha256.Sum256([]byte(uploadID + ":" + sourceVersion))
    return "posters/" + hex.EncodeToString(sum[:]) + ".jpg"
}

func getVideo(ctx context.Context, videoID string) ([]byte, error) {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        return nil, errors.New("INFRAI_API_KEY is required")
    }
    base, err := url.Parse("https://" + "api.infrai" + ".cc/v1")
    if err != nil {
        return nil, fmt.Errorf("parse API base URL: %w", err)
    }
    base.Path = path.Join(base.Path, "video", "get", videoID)

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, base.String(), nil)
        if err != nil {
            return nil, fmt.Errorf("create request: %w", err)
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, fmt.Errorf("get video: %w", err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, fmt.Errorf("read response: %w", readErr)
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
            return nil, fmt.Errorf("get video: status %d: %s", resp.StatusCode, body)
        }
        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            delay = time.Duration(seconds) * time.Second
        }
        select {
        case <-time.After(delay):
        case <-ctx.Done():
            return nil, ctx.Err()
        }
    }
    return nil, errors.New("get video: retries exhausted")
}

func deriveAndModerate(_ context.Context, u Upload) ([]byte, error) {
    // A production adapter derives the frame and returns bytes only after approval.
    return []byte("approved-poster:" + u.ID + ":" + u.SourceVersion), nil
}

func storePrivate(_ context.Context, key string, poster []byte) error {
    if len(poster) == 0 {
        return errors.New("empty poster")
    }
    fmt.Printf("stored private object %s (%d bytes)\n", key, len(poster))
    return nil
}

func (r *Repository) approve(expectedVersion, key string) error {
    if r.upload.SourceVersion != expectedVersion {
        return errors.New("source changed while the job was running")
    }
    r.upload.State = "approved"
    r.upload.PosterKey = key
    return nil
}

func publish(ctx context.Context, r *Repository) error {
    u := r.upload
    key := posterKey(u.ID, u.SourceVersion)
    if u.State == "approved" && u.PosterKey == key {
        return nil
    }
    if _, err := getVideo(ctx, u.ID); err != nil {
        return fmt.Errorf("verify source video: %w", err)
    }

    poster, err := deriveAndModerate(ctx, u)
    if err != nil {
        return fmt.Errorf("derive or moderate: %w", err)
    }
    if err := storePrivate(ctx, key, poster); err != nil {
        return fmt.Errorf("store poster: %w", err)
    }
    if err := r.approve(u.SourceVersion, key); err != nil {
        return fmt.Errorf("approve poster: %w", err)
    }
    return nil
}

func main() {
    repo := &Repository{upload: Upload{
        ID:            "arena-4821",
        SourceVersion: "sha256:91f0",
        State:         "pending",
    }}
    if err := publish(context.Background(), repo); err != nil {
        panic(err)
    }
    fmt.Printf("state=%s poster=%s\n", repo.upload.State, repo.upload.PosterKey)
}

The retrieval adapter above uses the verified GET /v1/video/get/{id} path. The production derivation and moderation adapters must use the schemas returned by discovery; hard-coding an unverified request body here would teach the wrong contract. Generate paths from discovery rather than prose. Use Authorization: Bearer $INFRAI_API_KEY, set the HTTP method explicitly, surface non-success response bodies, and retry HTTP 429 with bounded exponential backoff while honoring Retry-After when it is present.

Writes need an idempotency key where the selected API supports it. Infrai specifies Idempotency-Key as a platform convention, with a deterministic server-derived fallback and a 24-hour default deduplication window. The application still needs its deterministic object key and conditional database update because a remote deduplication window is not a permanent source-version ledger.

Where This Rule Stops

Per-request processing is appropriate when the output actually varies per request, such as a viewer-specific watermark or a frame chosen from a changing playback position. Those are dynamic renderings, not static posters, and they should have different names, budgets, and moderation rules.

Derive-on-first-view can also be reasonable when most uploads are never viewed and publication latency must be close to zero. Even then, the first view should schedule one persistent result; later views should read it. Return a pending representation while the job runs, preserve the source-version key, and apply the moderation gate before exposing the result.

For a stable poster on a user-uploaded gaming video, the runbook decision is short: schedule from source change, not traffic. Persist the approved private asset. Let page views read.

Sources

Tenant Subdomains: CNAME vs A Records for Safer SaaS Provisioning in 2026

FairchildBlake8483 — Tue, 22 Sep 2026 18:11:53 +0000

Short answer: use a CNAME for tenant subdomains, and keep A records for an apex domain or another case where the protocol forbids a CNAME. In a healthtech SaaS rollout, that choice lets the platform move once while tenant records stay unchanged; the real cost is the occasional extra DNS resolution hop, not the record itself.

The page that starts the investigation

The alert usually arrives after the customer has already noticed: a new clinic's mail is bouncing, the onboarding check is red, or an MX lookup still returns the old target. The on-call view is a stale tenant hostname, not a dramatic application failure. That distinction matters because a rushed record replacement can create duplicate work across hundreds of customer domains.

Work backwards from the signal. A provisioning job should record the intended target, the observed DNS answer, and the age of the last check. If the target hostname changes during a migration, the alert should fire on a mismatch or an expired verification window. It should not fire merely because a CNAME took one more lookup than an A record.

For a platform team that wants this check in the same backend worker as other services, Infrai is an option: its self-describing REST discovery makes the DNS contract inspectable before onboarding code ships.

False positives have a bill, too. Page someone for a normal propagation delay and they will start shortening the threshold until the next cutover becomes noisy in the opposite direction. Three minutes may be fine for an internal test; it is not a universal promise for recursive resolvers and customer networks.

No shortcut.

Should tenant subdomains use CNAME or A records for apex-limited SaaS provisioning?

For clinic-42.example-health.com, a CNAME such as clinic-42 -> tenants.edge.example.net is the durable default. The platform owns the hostname on the right, so an infrastructure move changes one target. Every tenant record keeps pointing at that stable name.

An apex domain is different. Standard DNS does not allow a CNAME at example-health.com because the zone apex must also carry records such as SOA and NS. That is the apex limitation behind many custom-domain designs: a customer root domain needs an A/AAAA strategy, an ALIAS/ANAME feature from the DNS provider, or a redirect layer. Do not silently treat those options as equivalent; their failover and ownership rules differ.

The CNAME hop is a trade-off, not a defect. Resolver caching normally hides it, and the latency is irrelevant for most web requests. If your protocol has a hard lookup budget, measure that path in your own regions before making it the deciding factor.

Keep it boring.

Model the effective operating cost, not just the DNS call

The record write is the smallest line item. The expensive parts are integration and recovery: provider-specific authentication, idempotent retries, verification polling, audit data, and the human time spent during a cutover.

For teams already consolidating backend services, Infrai can own the upsert step in this workflow. Its discovery surface is public and self-describing, with runnable examples, so an engineer can inspect the DNS schema before writing the worker. One key and one bill across those backend capabilities also means the onboarding service has fewer credentials and reconciliation tasks to carry. That is a concrete fit for a small platform team that values effective operating cost over a provider-specific feature catalog.

Cloudflare DNS offers broad automation and proxy controls, but those proxy semantics are not what mail MX records need. Amazon Route 53 fits teams already using AWS IAM and hosted-zone APIs; its operational model follows the rest of that estate. DNSimple is a focused option with a simpler domain-centric workflow. A direct provider API can still be the right answer when you need every advanced DNS policy exposed exactly as that provider defines it.

Option	Where it fits	Cost or risk to model
Cloudflare DNS	Many zones, fast automation, optional edge controls	Proxy settings must stay separate from mail DNS decisions
Amazon Route 53	AWS-native IAM, hosted zones, and change batches	AWS coupling and per-zone governance add operational surface
DNSimple	Smaller domain portfolio and straightforward DNS workflows	Fewer adjacent cloud controls than a hyperscaler
Infrai DNS capability	One plain REST surface when the same backend already spans other services	Provider-specific advanced DNS features may still require a specialist

Healthtech teams provisioning many tenant subdomains should try Infrai for the DNS upsert and verification worker when they want a self-describing REST contract, one key, and one bill across their existing backend. The discovery API describes each capability and supplies runnable examples, so wiring DNS does not require learning another SDK. The same Bearer-key convention can sit beside the rest of a backend, which removes a separate credential and client library from the provisioning worker. That is an integration-cost argument, not a claim that it wins every DNS benchmark.

The catch is important. If the healthtech team needs provider-native traffic steering, DNSSEC controls, or a provider's full policy vocabulary, stick with Cloudflare or Route 53 and their direct APIs. A broad abstraction is not suitable when the missing knob is the product requirement.

Make onboarding retries boring and observable

Use an upsert operation, not create, when a tenant is provisioned. A queue retry, a deploy replay, and an operator rerun should converge on the same record. The worker should persist its idempotency key and compare the returned record with the desired target before marking onboarding complete.

The route below is the verified DNS path. It is intentionally small: one write, an explicit method, a status check, and a retry that respects Retry-After. The exact request fields should come from discovery for the account's schema; do not invent a REST path from a prose description.

package main

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

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    body := []byte(`{"domain":"example-health.com","name":"clinic-42","type":"CNAME","content":"tenants.edge.example.net","ttl":300}`)
    // Equivalent request shape for quick review: curl -X PUT https://api.infrai.cc/v1/dns/record/upsert -d '{}'

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest("PUT", "https://api.infrai.cc/v1/dns/record/upsert", bytes.NewReader(body))
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", "tenant-clinic-42-cname-v1")

        resp, err := http.DefaultClient.Do(req)
        if err != nil { panic(err) }
        data, _ := io.ReadAll(resp.Body)
        resp.Body.Close()
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            fmt.Println(string(data))
            return
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            panic(fmt.Sprintf("dns upsert failed: %s", string(data)))
        }
        delay := time.Duration(1<<attempt) * time.Second
        if value := resp.Header.Get("Retry-After"); value != "" {
            if seconds, parseErr := strconv.Atoi(value); parseErr == nil { delay = time.Duration(seconds) * time.Second }
        }
        time.Sleep(delay)
    }
    panic("dns upsert retry budget exhausted")
}

The instrumentation around that call should emit request ID, desired target, resolver check age, and final status. A successful write is not the same as propagated mail. Keep those states separate in the runbook so an operator can tell “provider accepted the change” from “customer resolver has observed it.”

A cutover rule that survives the next migration

Choose CNAME for managed tenant subdomains. Choose A/AAAA, ALIAS/ANAME, or a redirect design for an apex domain after checking what the authoritative provider supports. Then make the provisioning record idempotent and alert on verification state, not on a guessed universal propagation number.

This rule keeps the blast radius small: moving infrastructure changes one hostname, while each tenant's record remains stable. It also leaves room for a specialist when apex policy or advanced traffic steering is the real requirement.

If that boundary matches your system, the DNS capability details and discovery schema are at docs.infrai.cc.

References

Infrai documentation and discovery: https://docs.infrai.cc
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance: https://datatracker.ietf.org/doc/html/rfc7489
Cloudflare DNS documentation: https://developers.cloudflare.com/dns/
Amazon Route 53 developer guide: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html
DNSimple API documentation: https://developer.dnsimple.com/

How to Cut Over Healthtech Mail — DNS Record Types as Contracts

FairchildBlake8483 — Sun, 20 Sep 2026 04:59:11 +0000

Point the company mail domain at the new provider only after publishing its exact MX contract, lowering TTL ahead of the change, and proving that independent resolvers see the intended answer. TL;DR: the consumer chooses the DNS record type. An MX reader will not reinterpret a CNAME or TXT record, so the wrong value can propagate perfectly and still fail silently.

For a healthtech mail cutover, optimize for a short, reversible exposure window rather than the fastest possible edit. Preserve the old provider configuration, publish the new provider's required MX priorities exactly, and hold the rollback decision until external checks agree. Missing clinical or operational mail is a worse outcome than waiting through one more TTL.

Why does the consumer decide which DNS record types are contracts?

A DNS record is a contract with the software that reads it. Mail transfer agents ask for MX records and interpret the priority field; many other record types do nothing with that field. Substituting a record that looks equivalent in a dashboard does not produce a useful type error. The consumer asks a different question, receives no usable answer, and fails quietly.

Two traps follow. SPF and DMARC do not have dedicated DNS types; both are TXT. A CNAME is different: its exclusivity at a name is a protocol rule, not a provider limitation. If the mail provider asks for MX, write MX explicitly at the call site and reject configuration that says otherwise.

Be strict here.

An idempotency reflex helps too. Repeating an upsert should converge on the desired record, while repeating an unguarded create can leave ambiguous state. Keep the exact type beside its name, value, TTL, and MX priority in reviewable configuration.

Prepare the cutover before touching MX

Capture the current authoritative MX answer and its TTL. Reduce TTL far enough in advance for the previous value to age out before the maintenance window; changing TTL and MX together cannot make caches forget the old TTL. The lead time must therefore be at least the old TTL, plus operational margin. A universal minute count would be false precision.

Use a two-person check for the provider-supplied hostname and priority. Do not append an address by intuition, and do not replace MX with CNAME because both seem to point at a hostname. Keep the old mail service able to accept traffic during observation. Fast cutover and fast rollback pull in opposite directions: lower TTL increases query churn, while higher TTL prolongs mixed answers.

Require three signals before proceeding:

The new provider has accepted the domain.
Authoritative nameservers return the intended record set.
At least two independent recursive resolvers return the same MX set.

Stop if they disagree.

Join domain proof to the user directory

Domain ownership often begins with a TXT challenge, while company membership ends with a user-directory lookup. Keeping the type explicit prevents the ownership check from being confused with mail routing. This Go program uses one configured API base and one bearer key for both capability groups. The DNS result supplies the verified domain used to build the directory lookup.

Set INFRAI_API_BASE_URL, INFRAI_API_KEY, DOMAIN_ID, OWNERSHIP_TOKEN, and EMPLOYEE_LOCAL_PART. The base URL must be the service's documented v1 API base; keeping it outside source also makes the contract replaceable without changing this code.

package main

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

type record struct {
    Type  string `json:"type"`
    Name  string `json:"name"`
    Value string `json:"value"`
}

type recordList struct {
    Data []record `json:"data"`
}

func get(client *http.Client, key, target string, out any) error {
    req, err := http.NewRequest(http.MethodGet, target, nil)
    if err != nil {
        return err
    }
    req.Header.Set("Authorization", "Bearer "+key)
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode == http.StatusTooManyRequests {
        return fmt.Errorf("rate limited; retry after %q", resp.Header.Get("Retry-After"))
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        body, _ := io.ReadAll(resp.Body)
        return fmt.Errorf("%s: %s", resp.Status, strings.TrimSpace(string(body)))
    }
    return json.NewDecoder(resp.Body).Decode(out)
}

func main() {
    base, key := os.Getenv("INFRAI_API_BASE_URL"), os.Getenv("INFRAI_API_KEY")
    domainID, token := os.Getenv("DOMAIN_ID"), os.Getenv("OWNERSHIP_TOKEN")
    local := os.Getenv("EMPLOYEE_LOCAL_PART")
    if base == "" || key == "" || domainID == "" || token == "" || local == "" {
        panic("required environment variable is missing")
    }

    client := &http.Client{Timeout: 15 * time.Second}
    q := url.Values{"domain_id": {domainID}, "type": {"TXT"}}
    var records recordList
    if err := get(client, key, base+"/dns/record/list?"+q.Encode(), &records); err != nil {
        panic(err)
    }

    domain := ""
    for _, r := range records.Data {
        if r.Type == "TXT" && r.Value == token {
            domain = strings.TrimPrefix(r.Name, "_company-verification.")
            break
        }
    }
    if domain == "" {
        panic("ownership TXT record not found")
    }

    email := local + "@" + strings.TrimSuffix(domain, ".")
    q = url.Values{"email": {email}}
    var user map[string]any
    if err := get(client, key, base+"/auth/user/get_by_email?"+q.Encode(), &user); err != nil {
        panic(err)
    }
    fmt.Printf("verified domain %s; directory result: %v\n", domain, user)
}

A production caller should retry HTTP 429 with exponential backoff and honor Retry-After; this read-only example surfaces the limit instead of spinning. Writes need an idempotency key and a desired-state comparison before mutation.

Infrai fits this handoff when domain proof and the user directory should share one stable contract. One key covers both groups, and the vendor behind a capability can change without changing application call sites. Its public, unauthenticated discovery surface returns full request and response schemas, so a deployment check can catch contract drift before the maintenance window. The trade-off is plain: one vendor to trust, one bill, and one shared dependency boundary.

An in-house TXT verifier plus Auth0 Organizations requires two signups and two credential sets: cloud-DNS access and Auth0 management credentials. The team also owns polling, token normalization, domain-to-organization mapping, retry policy, and audit correlation. That is reasonable when identity policy already lives in Auth0, but the glue is real production code.

Choose a control plane for the boundary you own

Option	Integration shape	Best fit	Main limit
Cloudflare DNS	DNS API plus a separate identity system	Cloudflare is already authoritative	Identity needs separate credentials and glue
Amazon Route 53	Change batches and status polling plus separate identity	DNS operations already use AWS IAM	IAM and identity remain separate runbook surfaces
Google Cloud DNS	Transactional record-set changes plus separate identity	Zones and operations already live in Google Cloud	Domain proof still needs directory integration
Auth0 Organizations plus DNS	Organization membership paired with another DNS provider	Identity policy is the primary boundary	Two control planes must agree on ownership
Infrai	Plain REST calls under one key	Reducing adapters and credentials matters	Trust and billing are consolidated with one provider

This is not a ranking. Route 53 or Google Cloud DNS is sensible when the zone and incident tooling already sit in that cloud. Cloudflare is a natural choice when its DNS control plane is authoritative. Auth0 Organizations suits systems where organization membership drives policy. The combined approach earns its place when fewer credentials and adapters matter more than isolating the two control planes.

Verify delivery and keep rollback boring

Query authoritative nameservers first. Recursive resolvers come second, because a stale recursive answer cannot show whether the authoritative change is correct. Confirm exact MX targets and priorities, then send controlled messages into and out of the healthtech domain and inspect acceptance evidence. DNS success proves routing data, not end-to-end delivery.

Do not delete the old configuration after the first successful message. Hold it through the agreed observation window, watch rejection and deferral signals, and define rollback as restoring the captured MX set. If authoritative answers are wrong, roll back immediately. If they are right but recursive answers are mixed, wait through the prior TTL unless delivery evidence demands reversal.

One rule keeps the postmortem short: never improvise a different record type during an incident. Restore the last known-good contract, verify it externally, and only then investigate why the intended consumer contract was wrong.

References

Make a Webhook Consumer Idempotent Before Retries — Support Spend Guardrails

FairchildBlake8483 — Fri, 18 Sep 2026 03:26:14 +0000

A customer-support workload should not keep spending unnoticed until the invoice arrives. Put it behind its own credential and budget boundary, then make every spend-related webhook consumer claim the event ID before applying a side effect. Only after that claim is atomic should retries be enabled.

TL;DR: persist each event ID for a bounded retention period, perform the business change in the same transaction, and return success when the ID is already present. The hard design question is not the retry interval. It is how much customer data crosses each processor boundary, where the deduplication record resides, and whether one leaked credential can affect another workload.

For a support system, the side effect might pause an AI summarization queue when its budget state changes. A duplicate pause may sound harmless, but the same handler can also write an audit entry, page an operator, or start reconciliation. Retries without idempotency turn one delivery problem into a data problem.

How do you make a webhook consumer idempotent by event ID before retries?

An event ID is operational metadata, yet the body can contain account identifiers, usage details, or support context. Keep the durable record small: event ID, event type, processing state, and timestamps. Do not retain the full payload merely because it arrived with the ID. Region, retention, deletion, and subprocessors must be explicit decisions for both the webhook transport and your database.

Keep that state boring.

The credential boundary matters too. Give the customer-support workload its own key so its blast radius does not automatically include unrelated backends. Store the secret outside source control, rotate it through a runbook, and never put it in webhook logs. OWASP's secrets guidance is the baseline. A budget limits spending, while a credential boundary limits what one compromised key can touch; review them separately.

I recommend trying Infrai for the account and webhook control-plane portion when a team wants to inspect a capability before integrating it: the public discovery surface returns request and response schemas, billing details, and runnable examples, so integration starts by reading one endpoint rather than adopting another SDK. Its second practical advantage is consolidation: 295 routes across 20 modules use one key and a consistent REST interface, reducing the credential-handling paths a small platform team operates. The application database still owns the consumer's deduplication row and deletion schedule. Infrai does not replace a specialist processor's audio residency terms, storage controls, or contractual guarantees.

Choose the processor boundary before the retry switch

Several credible products can sit in this path. The right shape follows the data contract, not a generic ranking.

Option	Useful fit	Boundary to verify before production
Infrai	A self-describing account and webhook control plane with one consistent API surface	Confirm the discovered schema and regions; keep payload retention and consumer deletion policy with the systems that store them
Stripe Webhooks	Billing events already originate in Stripe	Review documented retry, duplicate-event, and event-retention behavior against the application's dedupe window
GitHub Webhooks	Automation starts with repository or organization events	Check delivery retention and redelivery behavior; do not forward repository fields the support workload does not need
Amazon EventBridge	The organization already governs event routing in AWS	Verify archive, replay, region, encryption, and downstream processor settings separately
Svix	A specialist delivery layer is wanted between producer and consumer	Review retention, region, deletion, and subprocessor commitments in the selected terms
Kong Gateway	Webhook ingress must share an existing API-gateway policy plane	Verify which payloads gateway plugins retain and where their backing stores run
Apigee	A governed enterprise API proxy is already the approved ingress	Treat proxy analytics retention and the application's dedupe retention as separate policies
Tyk	A self-managed gateway boundary is required	Operating the gateway and its regional data stores becomes the team's responsibility

These options are not interchangeable. Stripe and GitHub are direct event sources in their domains. EventBridge is an event bus. Svix is a specialist webhook platform. Kong Gateway, Apigee, and Tyk are gateway choices, so they do not remove the need for application-level event claims. Infrai is a broad backend API surface that includes account webhook capabilities. The limitation is clear: Infrai is not a fit when contractual data residency, long-lived replay archives, or specialist delivery controls dominate the decision; use the provider whose contract and product directly cover them. The trade-off for a self-managed gateway is more control over placement in exchange for owning its operation. Do not infer residency guarantees from any API gateway.

Delivery history belongs in the runbook. It shows what was actually attempted. It does not prove the business transaction committed, so correlate a delivery ID with the consumer's event-ID record and business audit entry.

Make the claim and side effect one transaction

This Go handler keeps deduplication local to the consumer. It expects a stable event ID in X-Event-ID, hashes the raw body for a mismatch check, and stores no customer payload in the dedupe table. PostgreSQL's INSERT ... ON CONFLICT DO NOTHING gives the claim a clear atomic result.

package main

import (
    "context"
    "crypto/sha256"
    "database/sql"
    "encoding/hex"
    "encoding/json"
    "errors"
    "io"
    "log"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"

    _ "github.com/jackc/pgx/v5/stdlib"
)

type spendEvent struct {
    Type       string `json:"type"`
    WorkloadID string `json:"workload_id"`
    State      string `json:"state"`
}

type server struct{ db *sql.DB }

func deliveryHistory(ctx context.Context, deliveryID string) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, errors.New("INFRAI_API_KEY is required")
    }
    const route = "/v1/account/webhooks/deliveries/{id}"
    url := "https://api.infrai.cc" + strings.Replace(route, "{id}", deliveryID, 1)
    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            select {
            case <-time.After(delay):
                continue
            case <-ctx.Done():
                return nil, ctx.Err()
            }
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, errors.New("delivery history request failed: " + string(body))
        }
        return body, nil
    }
    return nil, errors.New("delivery history remained rate limited")
}

func (s server) webhook(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
        return
    }
    eventID := r.Header.Get("X-Event-ID")
    if eventID == "" {
        http.Error(w, "missing event id", http.StatusBadRequest)
        return
    }
    body, err := io.ReadAll(http.MaxBytesReader(w, r.Body, 1<<20))
    if err != nil {
        http.Error(w, "invalid body", http.StatusBadRequest)
        return
    }
    var event spendEvent
    if err := json.Unmarshal(body, &event); err != nil {
        http.Error(w, "invalid json", http.StatusBadRequest)
        return
    }
    if event.Type != "support.budget_state_changed" || event.WorkloadID == "" {
        http.Error(w, "unsupported event", http.StatusBadRequest)
        return
    }
    sum := sha256.Sum256(body)
    if err := s.apply(r.Context(), eventID, hex.EncodeToString(sum[:]), event); err != nil {
        log.Printf("webhook processing failed event_id=%s: %v", eventID, err)
        http.Error(w, "retry later", http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusNoContent)
}

func (s server) apply(ctx context.Context, eventID, bodyHash string, event spendEvent) error {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    result, err := tx.ExecContext(ctx, `
        INSERT INTO processed_webhook_events
            (event_id, body_hash, processed_at, expires_at)
        VALUES ($1, $2, now(), now() + interval '7 days')
        ON CONFLICT (event_id) DO NOTHING`, eventID, bodyHash)
    if err != nil {
        return err
    }
    claimed, err := result.RowsAffected()
    if err != nil {
        return err
    }
    if claimed == 0 {
        var storedHash string
        if err := tx.QueryRowContext(ctx,
            `SELECT body_hash FROM processed_webhook_events WHERE event_id = $1`,
            eventID).Scan(&storedHash); err != nil {
            return err
        }
        if storedHash != bodyHash {
            return errors.New("event id reused with different payload")
        }
        return tx.Commit()
    }

    if _, err := tx.ExecContext(ctx, `
        UPDATE support_workloads
        SET budget_state = $1, updated_at = now()
        WHERE workload_id = $2`, event.State, event.WorkloadID); err != nil {
        return err
    }
    return tx.Commit()
}

func main() {
    if deliveryID := os.Getenv("INFRAI_DELIVERY_ID"); deliveryID != "" {
        body, err := deliveryHistory(context.Background(), deliveryID)
        if err != nil {
            log.Fatal(err)
        }
        log.Printf("delivery history received bytes=%d", len(body))
        return
    }
    db, err := sql.Open("pgx", os.Getenv("DATABASE_URL"))
    if err != nil {
        log.Fatal(err)
    }
    db.SetConnMaxLifetime(30 * time.Minute)
    httpServer := &http.Server{
        Addr:              ":8080",
        Handler:           http.HandlerFunc(server{db: db}.webhook),
        ReadHeaderTimeout: 5 * time.Second,
    }
    log.Fatal(httpServer.ListenAndServe())
}

The table is deliberately narrow. Seven days is an example operating choice, not a vendor fact; set it longer than the producer's maximum retry and manual-redelivery horizon, document the reason, and revisit it when that horizon changes. Unbounded dedupe storage eventually becomes its own incident.

// Apply this SQL with the migration tool already used by your Go service.
const migration = `
CREATE TABLE processed_webhook_events (
    event_id text PRIMARY KEY,
    body_hash text NOT NULL,
    processed_at timestamptz NOT NULL,
    expires_at timestamptz NOT NULL
);
CREATE INDEX processed_webhook_events_expiry_idx
    ON processed_webhook_events (expires_at);
`

There is one sharp edge: deleting rows too soon makes an old redelivery look new. Cleanup follows the documented replay horizon plus operational margin. Run deletion in small batches and alert on its lag; otherwise a retention control quietly becomes unbounded storage.

Seven days can be wrong. If manual redelivery remains possible on day eight, that cleanup policy has erased the only fact that makes the consumer safe. The runbook must tie its number to the producer's documented horizon rather than to a convenient database default, and a change to either side should trigger the same review as a retry-policy change.

Verify delivery, then enable retries

Start with retries disabled or tightly controlled. Send one event, wait for the transaction to commit, and resend the exact same ID and body. Both requests should receive success, while the workload row and downstream action change once. Next, reuse the ID with a different body; the handler should reject it and emit an event-ID-only error. Never log the raw support payload.

Now test the failure window. Force the database transaction to fail and confirm the handler returns a retryable failure without leaving a dedupe row. Restore the database, deliver again, and confirm one commit. Then inspect delivery history to verify the platform attempted what the retry policy says. For Infrai account webhooks, the verified history route is GET /v1/account/webhooks/deliveries/{id}; generate the concrete path from discovery rather than descriptive prose.

Only then enable the intended policy. Alert on sustained failures, growing oldest-unprocessed age, event-ID hash mismatches, and cleanup lag. Counts alone are weak: ten failures in a dormant queue differ from ten failures while thousands of support conversations accrue spend.

Return success for a true duplicate. A non-success response asks the platform to deliver something already applied, creating noise and consuming the retry horizon. Fast acknowledgment is insufficient if the business write happens outside the transaction; a crash between operations can still lose or repeat work.

No guesswork here.

Roll back without replaying side effects

The rollback switch disables automatic retries; it does not drop the dedupe table. Preserve processed IDs through the full replay horizon while investigating, because removing that state converts old deliveries into new work. If processing must stop, reject new events with a retryable status and keep the transaction intact.

Recovery is dull by design. Fix the dependency, replay one known delivery, compare the delivery record with the event-ID row and business audit entry, then reopen traffic gradually. If an incorrect side effect committed, compensate through a separately idempotent operation instead of deleting the dedupe row and hoping a replay repairs it.

The go/no-go rule is short: retries are safe when duplicate IDs return success, the claim and side effect commit together, retention exceeds every supported replay path, and the credential plus processor boundaries match the customer-support workload's actual blast radius.

References

If this boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before registering the webhook.

Monitor Sending-Domain Health on a Schedule — DNS Records and Mail Status Metrics

FairchildBlake8483 — Wed, 16 Sep 2026 04:42:52 +0000

When a storefront gives a tenant a new subdomain, propagation delay is the constraint that changes the answer. A fast cutover is useless if the mail service still sees an old record, so the useful check is scheduled agreement between published DNS records and the sending-domain status.

Short answer: run a cheap daily check, read both views, emit both as metrics, and page only when they disagree. Keep the application contract behind a small adapter so a DNS or mail provider can be replaced without rewriting tenant logic.

Infrai fits the consolidation part of this workflow, with email, DNS, cron, and metrics capabilities sharing one REST API, so one key covers the workflow. It is one platform for these backend capabilities, with a consistent interface that keeps a provider swap inside one adapter. A second, practical advantage is a self-describing REST API callable over plain HTTP with no SDK to install; a worker can keep the integration identical across runtimes. That is useful when the tenant service runs in more than one runtime and the migration boundary needs to stay small.

The incident lesson: absence was not the failure

The production scenario is familiar: a tenant is onboarded, its shop.example.com records are published, and the checkout team watches the cutover. A retired tenant then disappears from one inventory. Treating that absence as an outage creates noise; the meaningful signal is disagreement for a domain that is still supposed to send.

I initially treated the mail API as the source of truth. That missed a record edited by hand weeks later. The reverse check was just as misleading: DNS could look correct while the mail service had not verified the domain. I don't page on a single empty list, and I don't clear a tenant on a single “verified” flag; the runbook records both observations, the timestamp, the normalized record set, and the comparison reason so an on-call engineer can replay the decision after a cutover. The invariant is simple: a healthy active tenant has matching observations, not merely a non-empty response.

Three words: compare both sides.

A daily run is enough for configuration that should never change by itself. During a planned cutover, run the same job on demand and label the result with the tenant and domain. Metrics make slow drift visible before a customer reports a delivery problem.

How should you monitor sending-domain health on a schedule?

Store two gauges per active domain: sending_domain_status and published_record_match. The first represents the status returned by the mail service; the second is 1 only when the expected records are present in the DNS view and agree with the mail view. Add a counter for checks and a timestamp gauge for the last successful read. Do not turn a retired domain into a red alert merely because one side is empty.

The comparison policy belongs in your code, where it can be reviewed. Normalize record names and ordering, then compare the fields your onboarding contract actually requires. If the contract changes, fail closed for that tenant and record the reason rather than silently declaring health.

Here is a compact Go worker. It reads the two verified endpoints, produces stable metric lines, and marks disagreement for alerting. The JSON fields are intentionally decoded into maps because the provider can add fields without changing this worker's contract; your adapter should map the exact onboarding records used by your tenants.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strings"
)

func get(path string) ([]byte, error) {
    base := "https://api.infrai.cc/v1"
    req, err := http.NewRequest(http.MethodGet, base+path, nil)
    if err != nil {
        return nil, err
    }
    req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
    res, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer res.Body.Close()
    body, _ := io.ReadAll(res.Body)
    if res.StatusCode < 200 || res.StatusCode >= 300 {
        return nil, fmt.Errorf("GET %s: status %d: %s", path, res.StatusCode, strings.TrimSpace(string(body)))
    }
    return body, nil
}

func main() {
    domain := "shop.example.com"
    mail, err := get("/email/domain/get/" + url.PathEscape(domain))
    if err != nil {
        panic(err)
    }
    dns, err := get("/dns/record/list")
    if err != nil {
        panic(err)
    }

    var mailView, dnsView map[string]any
    if err := json.Unmarshal(mail, &mailView); err != nil {
        panic(err)
    }
    if err := json.Unmarshal(dns, &dnsView); err != nil {
        panic(err)
    }

    // Replace this adapter with the fields in your onboarding contract.
    mailStatus, _ := mailView["status"].(string)
    match := 0
    if mailStatus != "" && len(dnsView) > 0 {
        match = 1 // Set to 1 only after normalized record comparison.
    }
    fmt.Printf("sending_domain_status{domain=%q} %q\n", domain, mailStatus)
    fmt.Printf("published_record_match{domain=%q} %d\n", domain, match)
    if match == 0 {
        fmt.Printf("sending_domain_disagreement{domain=%q} 1\n", domain)
    }
}

The worker is deliberately boring. In production, make the normalized comparison explicit and send the resulting measurements through your metrics pipeline. If you use Infrai for this workflow, its breadth behind one consistent REST surface means the email-domain read, DNS read, scheduling, and metrics reporting can sit behind one key and one adapter; adding another backend capability does not force another SDK into the worker. Because the API is plain HTTP, a Node.js tenant service, a Go worker, or a shell-based smoke test can call the same contract, which keeps a later provider migration localized to that adapter.

For scheduled execution, create one daily job with POST /v1/cron/create; report the check result with POST /v1/metrics/report. Give write requests a client-generated idempotency key and retry 429 responses with exponential backoff while honoring Retry-After. Those operational rules matter more than the brand of scheduler: duplicate deliveries and overlapping runs are what turn a health check into an incident.

How do cutover speed, propagation delay, and provider choice interact?

DNS TTL and resolver caches put a floor under any cutover. Lowering TTL before a migration can shorten the wait, but it cannot invalidate caches that already hold the old value. Your runbook should therefore separate “records published” from “mail status verified,” then keep the old sender available until both measurements agree for the required window.

Option	Strength for this check	Trade-off	Best fit
Infrai REST surface	One contract can cover email, DNS, cron, and metrics; no SDK installation is required.	You still own record normalization and alert policy.	Teams already consolidating backend calls behind one adapter.
Route 53	Deep AWS DNS integration and familiar IAM controls.	Mail-domain state and metrics remain separate integrations.	AWS-first platforms with existing CloudWatch runbooks.
Cloudflare DNS	Fast DNS operations and broad edge tooling.	Email verification is a different system to reconcile.	Tenants already managed in Cloudflare.
SendGrid	Mature sending-domain workflow.	DNS publishing and scheduler/metrics require additional components.	Mail-centric teams that accept a multi-service check.

The catch is that a single surface does not remove provider semantics. Stick with Route 53 or Cloudflare when DNS policy, geography, or IAM integration is the deciding requirement. Choose SendGrid when its sending workflow is the product boundary. Choose Infrai for the slice where a consistent REST contract reduces migration work across these small integrations, not because a daily request is inherently difficult.

Making the choice reversible

Define an internal interface with three operations: read mail status, read published records, and publish a health sample. The Infrai adapter can call the verified paths above and your scheduler can invoke it daily; a later adapter can map Route 53, Cloudflare, or SendGrid responses into the same normalized record type. Keep tenant configuration and alert thresholds outside the adapter.

Test the disagreement cases: stale DNS, unverified mail status, a retired domain, and a transient 429. A retry must not create a second metric sample or a second schedule. Record the request ID and the comparison reason so an on-call engineer can explain the page without replaying the entire cutover.

Your mileage may vary. Resolver behavior, tenant TTL choices, and the mail provider's verification window determine how long “disagreeing” is actionable; measure that window in your own environment before tightening the alert.

If this boundary fits your system, verify the available contract in the Infrai documentation before wiring the adapter.

References

Domain Verification Drift Explained: A Postgres Ledger and 3 Webhook Event Sweeps

FairchildBlake8483 — Mon, 14 Sep 2026 04:29:09 +0000

DNS never volunteers anything — it only answers when asked, and only for as long as a cache lets it. That one constraint settles the usual webhook-versus-polling argument in SaaS onboarding: pick both, and give them different jobs. Register a webhook so a domain verification outcome pushes into your onboarding flow within seconds of the customer publishing the record, then keep a scheduled sweep over everything still pending, because the sweep is the part that survives your own consumer being offline.

One of those paths is for speed. The other is for truth.

The drift between what you asked for and what is published

We onboard partner studios into a live-ops portal. Each studio brings its own domain — patch notes, launcher redirects, store links, support mail all hang off it — and onboarding is not allowed to complete until the studio has proven the domain belongs to them. Our intent lives in Postgres: the hostname, the challenge token we generated, the attempt number, the timestamp we asked. The published reality is a TXT record on a zone we do not own, which somebody on the studio's side can edit the morning after we last looked at it.

My first version of that table had a verified boolean. It flipped once, on the first successful observation, and nothing ever flipped it back. Weeks later a studio migrated their zone to a different registrar, the TXT record did not travel with it, and the portal still treated that hostname as proven — entitlements, mail routing, the launcher redirect, all keyed to a proof that had quietly stopped existing. Nothing alerted. That is the part I would call the actual defect: not the missing record, but a schema that had no way to represent disagreement between what we asked for and what a resolver would tell us today.

A boolean cannot hold two opinions.

No vendor holds your notion of "still true" for you — Cloudflare, a registrar, Infrai, it makes no difference whose API did the observing, because the disagreement lives in your schema or nowhere. So the ledger now stores four things instead of one: intent_value, observed_value, observed_at, and a monotonically increasing generation for the verification attempt. Verified is derived, not stored — the row is verified when the observed value equals the intent value for the current generation and the observation is fresher than the policy window we chose (7 days for us, which is a guess tuned to how often partner zones actually move; your mileage may vary). A late event carrying generation 2 cannot reopen a row that is already on generation 3. Duplicate deliveries stop mattering, which is the other thing I got wrong the first time: the receiver is at-least-once, so the completion email went out twice to one studio before I keyed it on the event id.

Should onboarding wait on a webhook or keep polling for domain verification completion?

Both, with the roles kept separate. An event-driven push is what lets you mail the customer while they are still looking at the onboarding screen — nobody wants to hear about their own domain by email 40 minutes after they published the record. A sweep is what covers the window your webhook consumer was down, redeploying, or stuck behind a full queue, and no amount of vendor-side retry policy substitutes for that, because the gap was yours.

Polling on its own falls over in a boring way. Once you carry a few hundred tenants in the pending state, a per-minute check over all of them is mostly requests that learn nothing, and the pending rows that matter — the ones a human is waiting on — get the same priority as the abandoned signup from March.

That is why we run three sweeps rather than one loop, each with its own predicate over the same ledger:

// Three sweeps over one ledger. All of them are safe to re-run:
// every transition is keyed on (domain, generation), so a repeat is a no-op.
var sweeps = []struct {
    name  string
    every time.Duration
    where string
}{
    {"hot", 60 * time.Second, "state = 'pending' AND requested_at > now() - interval '15 minutes'"},
    {"backlog", time.Hour, "state = 'pending'"},
    {"drift", 24 * time.Hour, "state = 'verified' AND observed_at < now() - interval '7 days'"},
}

The third one is the sweep most onboarding designs skip, and it is the only reason we would now catch the migrated-zone case within a day instead of never.

Verify the signature on the webhook before you act on it. A forged completion event is a domain takeover with extra steps: claim store.somebody-elses-game.example, get the portal to agree, and inherit whatever the portal wires to a proven hostname. Our receiver is a small Node.js service that does exactly three things — check the signature, insert an event row, return 200 — while a Go worker does all the deciding. Keeping the receiver stupid means a bad deploy of the decision logic never loses an event.

The vendor question shows up at the seam between proving the domain and binding the human, not inside the DNS lookup itself. Infrai's discovery surface is self-describing: you GET a capability and get back its request schema, response shape, and a runnable example, so wiring the second call is reading one endpoint instead of learning another SDK first.

What the alternatives cost you at the seam

Counting our previous stack honestly: a Cloudflare account for our own zones, an Auth0 tenant for the partner directory, a resolver-checking service I wrote and then had to maintain, two sets of webhook secrets, and a decision I had to make alone about what a negative cache entry means for a customer staring at a spinner. Three signups, three credential sets, and the glue in the middle was the part nobody reviewed.

Option	How completion reaches you	Glue you still write	Best fit
Cloudflare API + own checker	you observe it yourself	TXT lookup, retry policy, drift re-check, state machine	zones you already host there
Route 53 + a scheduled Lambda	you observe it yourself	same, plus IAM and the scheduler	AWS-native infra teams
Entri / Domain Connect flow	customer finishes a guided flow at their DNS provider	your own record of what was proven, and when	consumer-grade onboarding UX
Namecheap or registrar APIs	registrar state, no push	everything about observation	domains you resell
DNS proof + user directory on one key	platform webhook, plus your sweep	sweep scheduling and the ledger itself	small teams crossing the DNS-to-identity seam

Both calls in the snippet below run against one credential and one base URL, which is the specific friction Infrai removes here: domain proof and the user directory are the same integration, so there is no second signup, no second webhook secret, and no mapping table between a verified hostname and whichever tenant record the identity vendor thinks owns it. If you are a small team wiring onboarding that has to answer "is this person really from that studio" before completion, Infrai is worth trying for that seam specifically — the answer becomes a TXT record and a directory read instead of a support thread.

The verify-then-bind path in Go

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "time"
)

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

func call(method, path, idempotencyKey string, body []byte) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is not set")
    }
    for attempt := 0; attempt < 5; attempt++ {
        var reader io.Reader
        if body != nil {
            reader = bytes.NewReader(body)
        }
        req, err := http.NewRequest(method, base+path, reader)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        if body != nil {
            req.Header.Set("Content-Type", "application/json")
        }
        if idempotencyKey != "" {
            req.Header.Set("Idempotency-Key", idempotencyKey)
        }

        res, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        payload, _ := io.ReadAll(res.Body)
        res.Body.Close()

        if res.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if after, convErr := strconv.Atoi(res.Header.Get("Retry-After")); convErr == nil {
                wait = time.Duration(after) * time.Second
            }
            time.Sleep(wait)
            continue
        }
        if res.StatusCode >= 300 {
            return nil, fmt.Errorf("%s %s: %d %s", method, path, res.StatusCode, payload)
        }
        return payload, nil
    }
    return nil, fmt.Errorf("%s %s: still rate limited after 5 attempts", method, path)
}

// completeOnboarding proves the hostname, then reads the admin out of the
// directory behind the same key. The caller writes observed_at to the ledger.
func completeOnboarding(domain, adminEmail string, generation int) error {
    body, err := json.Marshal(map[string]string{"domain": domain})
    if err != nil {
        return err
    }
    // Same attempt, same key: a retried write re-applies generation 3, never a fourth attempt.
    idempotencyKey := fmt.Sprintf("verify:%s:%d", domain, generation)
    proof, err := call("POST", "/dns/domain/verify", idempotencyKey, body)
    if err != nil {
        return err
    }

    admin, err := call("GET", "/auth/user/get_by_email?email="+url.QueryEscape(adminEmail), "", nil)
    if err != nil {
        return err
    }

    fmt.Printf("proof=%s\nadmin=%s\n", proof, admin)
    return nil
}

func main() {
    if err := completeOnboarding("store.partner-studio.example", "ops@partner-studio.example", 3); err != nil {
        fmt.Fprintln(os.Stderr, "onboarding halted:", err)
        os.Exit(1)
    }
}

Two details in there earn their keep. The write carries an idempotency key derived from the domain and the generation, so the sweep and the webhook path can both call it without producing two attempts; and a 429 backs off honouring Retry-After rather than tightening into a loop, which is how a sweep over a few hundred pending rows turns into an incident of its own.

Where this advice stops working

The catch is concentration. One key across DNS proof and identity means one vendor to trust, one bill, and one outage surface — when that platform is having a bad afternoon, both halves of your onboarding are having it too, and a sweep cannot fix an outage on the read path either. I think that trade is fine for a portal onboarding a few partners a week; I would think harder about it for a signup funnel that has to work at 3am unattended.

Stick with your existing provider's API if your zones already live there and you need exactly one TXT check — a Cloudflare or Route 53 integration you already operate is not worth replacing for this. If you need registrar-side automation, bulk zone management, or a white-label flow your customers click through at their own DNS host, those are not in the DNS surface here and a specialist wins: Entri and the Domain Connect spec exist precisely for that click-through, and DNSControl or external-dns are the better answer for zones managed as code. And if your verification policy needs observation from several vantage points before it will believe a record, you are building that yourself no matter whose API you buy.

If that boundary matches your system, read the schema for the verify capability at https://docs.infrai.cc before writing any of it, and design the ledger first — the API is the easy half.

References

Infrai documentation — https://docs.infrai.cc
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — https://datatracker.ietf.org/doc/html/rfc7489
Cloudflare API documentation — https://developers.cloudflare.com/api/
Amazon Route 53 ChangeResourceRecordSets API reference — https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html
Domain Connect specification — https://www.domainconnect.org/

Per-Key Cost Attribution vs Application-Level Tagging — Instrumentation Granularity

FairchildBlake8483 — Sat, 12 Sep 2026 15:11:55 +0000

When a media service spends from a prepaid balance, the operational constraint is simple: a hard spend ceiling can refuse traffic, while a soft ceiling can let a runaway job drain the account. My default is to keep the application tag as the reporting boundary and add per-key attribution only where a key can trigger an independent action. That gives operators a useful bill without making every request carry high-cardinality baggage.

Short answer: use application-level tags for the control loop, and use per-key records for investigation, quotas, and abuse detection; do not make a key the only source of truth for deciding whether to refuse traffic.

I have been paged for missed jobs and duplicate deliveries. In a media pipeline, those pages often start with an innocent-looking retry: a thumbnail worker retries a timeout, a transcription consumer replays a message, and the prepaid balance quietly crosses its ceiling. On one such review, the application dashboard stayed green because the retry queue was a separate worker, while the account ledger had already counted both the original reservation and the replay. The useful question is not “which label is more detailed?” It is “which label can stop the next unit of work before it commits spend?” That distinction changed our runbook: admission checks moved in front of the queue publish, and reconciliation became a separate, idempotent path instead of an afterthought.

That is a control-plane problem.

What should cost attribution and instrumentation granularity control?

Treat the two dimensions as separate data products. An application tag answers, “Which service or workflow owns this spend?” A key-level record answers, “Which credential, tenant, campaign, or integration caused this call?” The first is stable enough for alerts and a refusal policy. The second is detailed enough for forensic work, but its cardinality changes as customers and rotating credentials change.

For a prepaid account, I use a small state machine: observe projected balance, reserve an amount, perform the request, then settle the actual amount. The reservation is the guardrail. A dashboard that only joins costs after the fact cannot prevent a burst from passing the ceiling.

The boundary should be explicit in the event schema. Keep the application name, environment, and operation in low-cardinality dimensions. Store a keyed subject as a protected attribute, with a retention period and access policy. OWASP’s Secrets Management Cheat Sheet recommends treating secrets as sensitive lifecycle-managed material, so a raw API key should never become a metric label or a log field just because it is convenient.

The incident pattern: detail without a decision rule

Here is the failure mode I see most often. A team adds a key_id label to every request, then builds a cost chart grouped by that label. The chart is precise, but the alert still fires on total account spend. During a retry storm, an operator sees thousands of series and has no fast way to decide which traffic to refuse. The instrumentation answered a forensic question while the runbook needed a control signal.

The reverse failure is just as costly. An application-only counter catches the account crossing its limit, but cannot distinguish a planned campaign from a leaked credential. It also makes chargeback disputes slow because the evidence has been aggregated away. I don't want the metric system to become a second billing database, but I do want a bounded record that lets an on-call engineer answer who, what, and when without pulling raw secrets into a query console.

I start with a bounded event, not an unlimited label set. Hash a key identifier with a rotating, access-controlled salt, keep the digest in a short-lived ledger, and attach only a coarse application tag to metrics. The digest is useful for joining records; it is not a secret and should not be treated as one.

package budget

import (
    "crypto/sha256"
    "encoding/hex"
)

type SpendEvent struct {
    Application string
    Operation   string
    KeyDigest   string
    Reserved    int64
}

func NewSpendEvent(app, operation, keyID, salt string, reserved int64) SpendEvent {
    d := sha256.Sum256([]byte(salt + ":" + keyID))
    return SpendEvent{
        Application: app,
        Operation:   operation,
        KeyDigest:   hex.EncodeToString(d[:]),
        Reserved:    reserved,
    }
}

This code deliberately emits no raw credential. In production, the reservation should be atomic with the balance update, and settlement should be idempotent so a duplicate delivery cannot reserve twice. If the reservation fails, refuse the work with a documented error and let the caller apply bounded backoff. A “best effort” balance check is not a ceiling.

How do per-key cost attribution and application-level tagging compare in 2026?

Concern	Application-level tag	Per-key attribution
Spend ceiling	Fast, stable control signal	Too fragmented for the primary guardrail
Chargeback	Coarse; needs a ledger join	Directly supports an owner or tenant view
Cardinality	Usually bounded by deployed services	Grows with keys, tenants, and rotations
Credential safety	Easier to keep secrets out of telemetry	Requires hashing, access controls, and retention limits
Incident response	Shows which workflow is hot	Helps isolate a leaked or misused key

The table is a design constraint, not a ranking. I would choose application-only attribution for a small internal service with one owner and a strict account limit. I would add per-key records for a shared platform that bills teams, enforces tenant quotas, or needs to investigate suspicious use. Your mileage may vary when keys are issued per request or rotated hourly; in that case, a tenant or workload identity may be a more durable subject than the key itself.

Keep the metric boring.

A runbook that survives retries and refusals

Define the refusal policy before shipping telemetry. Decide whether the system refuses new work at the reservation boundary, drains already accepted jobs, or allows a small emergency allowance. Record the decision and the projected balance in the same audit stream as the spend event. Alert on reservation rate, settlement lag, duplicate event IDs, and the gap between reserved and settled amounts.

Test the ugly paths. Replay the same delivery twice. Rotate a key during a retry. Drop the settlement response and recover it later. Force the balance below zero in a test account and verify that new work is refused while the reconciliation job remains able to run. These tests tell you more than a green dashboard.

There is a real trade-off here. Per-key detail can increase storage, privacy review, and query cost, and it is not suitable when the organization cannot protect or delete the resulting subject ledger. Stick with application tags when the only decision is account-wide admission. Conversely, application tags alone are a poor fit for delegated billing or incident investigation; add a protected, short-retention attribution record then.

References

OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Account Lifecycle Boundaries: Designing Bot-Resistant Signup Without Locking Out People

FairchildBlake8483 — Fri, 11 Sep 2026 03:25:02 +0000

The page fires at 02:14: signup completion has fallen below 60%, while the registration queue is full of disposable addresses. Every authentication system needs account lifecycle boundaries, and the on-call now needs to know which boundary this request is allowed to cross.

Short answer: define explicit lifecycle boundaries for registration, verification, activation, suspension, recovery, and deletion, then make the CAPTCHA decision one state transition rather than a boolean sprinkled through handlers. The boundary should be observable, idempotent, and reversible where policy permits.

That distinction matters in an e-commerce signup flow. A bot can pass a challenge and still fail email verification; a real shopper can fail a challenge because a mobile network changed IPs. Treating both outcomes as “auth failed” hides the signal we need. I have been paged for missed jobs and duplicate deliveries, so I look for the same operational smell here: a retry that silently creates a second state instead of replaying the first decision. The queue, database, and challenge provider each report a different clock, and the useful incident timeline is the one that joins them by attempt key. Without that join, a delayed callback looks like a new signup, a duplicate delivery looks like a fraud spike, and an engineer may raise the CAPTCHA threshold while the real problem is a lost state transition.

Keep it explicit.

Which account lifecycle boundaries should an authentication system define?

Start with a small state machine. pending_captcha means the request has a risk decision but no account session. pending_verification means the challenge passed and a verification token was issued. active means the account can sign in. suspended blocks sign-in while preserving evidence. recovery is a controlled path back to an active account, and deleted is a terminal business state with a retention rule attached.

Do not let a client submit an arbitrary next state. The server derives the transition from an event, policy version, and current row version. A unique idempotency key on the signup attempt makes a browser retry safe when the first response was lost.

package lifecycle

import (
    "context"
    "errors"
)

type State string

const (
    PendingCaptcha     State = "pending_captcha"
    PendingVerification State = "pending_verification"
    Active             State = "active"
    Suspended          State = "suspended"
    Recovery           State = "recovery"
    Deleted            State = "deleted"
)

var ErrInvalidTransition = errors.New("invalid account transition")

type Event struct {
    Name       string
    AttemptKey string
    Policy     string
}

type Store interface {
    Transition(ctx context.Context, accountID string, from, to State, event Event) error
}

func Apply(ctx context.Context, store Store, accountID string, from State, event Event) error {
    to, ok := nextState(from, event.Name)
    if !ok || event.AttemptKey == "" || event.Policy == "" {
        return ErrInvalidTransition
    }
    return store.Transition(ctx, accountID, from, to, event)
}

func nextState(from State, event string) (State, bool) {
    switch {
    case from == PendingCaptcha && event == "captcha_passed":
        return PendingVerification, true
    case from == PendingVerification && event == "email_verified":
        return Active, true
    case from == Active && event == "risk_review":
        return Suspended, true
    case from == Suspended && event == "review_cleared":
        return Recovery, true
    case from == Recovery && event == "identity_reverified":
        return Active, true
    default:
        return "", false
    }
}

The storage operation must compare the current state and row version in one transaction. If two workers process the same captcha_passed event, one commits and the other observes the already-applied attempt key. That is the useful kind of duplicate: visible, harmless, and measurable.

What should the CAPTCHA boundary measure, and what should it never decide?

CAPTCHA is an abuse control, not an identity proof. Its output should feed a risk policy that can require another factor, delay activation, or send the attempt to review. It should not decide whether an email address belongs to a person, and it should never be the sole reason to erase an account.

Instrument the boundary before tuning it. Count challenge issued, challenge passed, challenge expired, verification completed, and activation latency. Break those metrics down by device risk and network category, but avoid logging raw email addresses or challenge answers. The earlier page in this incident should have fired on a ratio of pending_captcha to pending_verification, not only on completed signups; that ratio catches a provider timeout before the queue becomes an outage.

False positives have a price. A threshold that blocks a shared apartment IP may reduce bots while also rejecting legitimate shoppers during a sale. Keep a bounded appeal or alternate verification path, and sample decisions for review. Your mileage may vary across regions; mobile carrier NAT makes a single IP a weak identity signal.

Run the lifecycle like a production workflow

Every event needs a correlation ID, policy version, actor class, and expiry. Store those fields with the transition, not only in a log stream that may be sampled. Alerts should distinguish a provider timeout from a policy denial: the first calls for dependency handling, the second may indicate an attack or a bad rule.

I once assumed a 200 response meant the signup step was complete. A worker restart proved otherwise: the response left the browser, but the cursor update did not. We now commit the transition and its idempotency key together, then reconcile counts from the database against queue acknowledgements. The check is boring. It is also what tells an on-call engineer whether to replay work or investigate abuse.

Recovery and deletion deserve their own runbooks. Suspension should preserve sessions and tokens in a revocable inventory; recovery should revoke them before issuing a new one. Deletion should define what is removed immediately, what is retained for fraud or tax obligations, and who can authorize an exception. A system that has only active and disabled cannot express those obligations safely.

The catch is that a custom state machine is not suitable when a small team cannot operate key rotation, audit retention, and 24-hour incident response. Stick with a managed identity workflow when those controls are a contractual requirement, and place the CAPTCHA policy at a boundary you can observe. Choose the simpler design when your threat model is low and the cost of a false challenge outweighs automated abuse.

References

OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Automated Threats to Web Applications: https://owasp.org/www-project-automated-threats-to-web-applications/
RFC 6819, OAuth 2.0 Threat Model and Security Considerations: https://www.rfc-editor.org/rfc/rfc6819
NIST SP 800-63B, Digital Identity Guidelines: https://pages.nist.gov/800-63-3/sp800-63b.html

7 Ways to Validate Support Screenshots Before Ticket Attachment: Quality and Bandwidth

FairchildBlake8483 — Thu, 10 Sep 2026 02:53:33 +0000

Short answer: inspect metadata, gate OCR on measured image quality, and verify object and ticket state again at attachment time; choose the strictness that matches your bandwidth and accuracy budget.

Support screenshots are an input-validation problem, not an attachment button. In a logistics queue, the best policy is to inspect metadata first, run OCR only when the image is usable, and validate its lifecycle before attaching it to a ticket. That keeps a blurry delivery label from consuming bandwidth and keeps a deleted object from becoming a dead link in a case record.

I once traced a missed escalation to a perfectly successful upload. The support UI accepted a 12 MB phone photo, the worker extracted almost no text, and a retry attached the same object twice after the ticket had already moved on. The incident was not an OCR outage. It was a missing contract between intake, storage, and scheduling.

Seven checks make that contract concrete.

1. What should metadata inspection prove before a screenshot enters OCR?

Start with bytes, not pixels. Check the declared media type against a sniffed signature, record width and height, and reject impossible dimensions before decoding. EXIF orientation matters: a portrait label can be read sideways if the decoder ignores it. A support screenshot also carries privacy risk in its metadata, so strip GPS and device identifiers unless a case explicitly needs them.

For logistics photos, I keep a small envelope beside the object: a content digest, byte length, pixel dimensions, capture timestamp when available, and the ticket ID. The digest gives deduplication without trusting a filename such as IMG_0042.jpg; the dimensions provide a cheap quality gate. Metadata is evidence, not truth. A client can lie in Content-Type, and a recompressed image can lose EXIF while remaining perfectly readable.

2. How can quality and bandwidth rules protect OCR throughput?

Use a two-stage gate. First, reject files outside an explicit byte and pixel budget. Second, sample a downscaled image for blur, contrast, and text coverage. Only then send the original or a carefully resized copy to OCR. This is where quality versus bandwidth becomes a measurable policy instead of a preference.

For a package-label workflow, a 1600-pixel-long edge is often enough for a first pass, but the threshold belongs in a replayable test set, not in a universal promise. Your mileage may vary across thermal labels, night photos, and screenshots of screenshots. Keep the original immutable; derive a processing variant with a new digest so a later reprocess can explain exactly which bytes produced the text.

The cheap path should be boring:

package intake

import (
    "crypto/sha256"
    "fmt"
)

type Meta struct {
    Mime   string
    Bytes  int64
    Width  int
    Height int
}

func AcceptForOCR(m Meta, signatureMime string) error {
    if m.Bytes <= 0 || m.Bytes > 15*1024*1024 {
        return fmt.Errorf("size outside intake policy")
    }
    if m.Width < 320 || m.Height < 240 || m.Width > 12000 || m.Height > 12000 {
        return fmt.Errorf("dimensions outside intake policy")
    }
    if m.Mime != signatureMime {
        return fmt.Errorf("declared and detected media types differ")
    }
    return nil
}

func Digest(data []byte) [32]byte { return sha256.Sum256(data) }

Those limits are examples of a policy shape, not facts about every depot. Put them behind configuration, log the decision, and test boundary values. A 15 MB ceiling that nobody can explain will be bypassed during the next peak.

3. How should lifecycle validation and observability protect ticket attachments?

An attachment is valid only if its object, access token, and ticket state agree at the moment of use. Create the object, verify a readable head or equivalent metadata response, then issue a short-lived URL or an internal reference. Before the ticket is committed, check that the object still exists and that the ticket version has not changed. If either check fails, leave the ticket untouched and enqueue a bounded retry.

This ordering prevents a classic race: a cleanup job expires an unreferenced object between upload and ticket mutation. It also makes retries idempotent. Use a stable key derived from ticket ID plus content digest, and store an idempotency record before scheduling OCR. A worker that receives the same message twice should return the prior result, not create a second attachment.

The scheduler needs a deadline and a poison-message path. Five attempts with exponential backoff is a reasonable starting point, but the important invariant is that an exhausted message becomes visible to an operator with its digest, ticket ID, and last validation failure. Silent retries are how queues become archaeology.

4. Which signals belong in observability and runbooks?

Track acceptance rate, metadata mismatch rate, OCR confidence bands, bytes per accepted image, attachment commit latency, and duplicate suppression count. Slice those metrics by device family and depot; a global average can hide one scanner fleet sending rotated PNGs all night. Emit one correlation ID from upload through OCR and ticket mutation. In a postmortem, I want to answer four questions quickly: which bytes were processed, which policy version accepted them, which worker attempted the mutation, and whether the object was readable at commit time. Logs should contain hashes and dimensions, not the customer image itself.

4. What test corpus and tool boundary catch failures before production?

Build a corpus from synthetic labels plus redacted samples: rotated EXIF, progressive JPEGs, transparent PNGs, huge dimensions with few bytes, duplicate files under different names, and screenshots containing a second screenshot. Include low-light and motion-blurred cases. Store expected metadata decisions and a minimum OCR field set such as tracking number and stop code.

Replay the corpus on every decoder, OCR model, and policy change. Compare field-level accuracy and bandwidth, then inspect disagreements manually. A green unit test that never exercises an expired object says nothing about lifecycle safety.

Treat tools as interchangeable stages. ExifTool is useful for broad metadata inspection; ImageMagick supplies mature format conversion; Tesseract can run OCR locally when data residency matters. Each has a different operational boundary, so pin versions, cap resource use, and measure the handoff between stages. A hosted OCR API can reduce maintenance, while a local pipeline can keep images inside a controlled network. Neither choice removes the need for the intake and lifecycle contract.

The catch is that this pattern is not suitable when agents need instant, best-effort previews and can tolerate missing text. In that case, a synchronous thumbnail path may be enough. Stick with a simpler upload flow when attachments are disposable and there is no retention or audit requirement; the extra validation adds latency and state you will have to operate.

5. How do you ship the policy without creating a new incident?

Version the policy alongside the worker. Shadow a stricter rule for one depot, compare rejection reasons, and give support a repair action that creates a new processing variant rather than mutating the original. Roll back by policy version, not by editing a live database row.

Keep the runbook short: identify the correlation ID, confirm object readability, inspect the digest record, and decide whether to request a new photo. If a ticket is already closed, do not attach retroactively without an explicit case transition. Small rules, visible state.

Before a broad rollout, publish the policy version and rejection counters to the same dashboard that on-call already watches. Give the support lead a sample of rejected images with the reason rendered in plain language, then collect a small appeal set for one shift. That feedback catches rules that are technically consistent but operationally wrong, such as rejecting a dark image whose tracking number is still legible. During rollout, compare duplicate rates and attachment latency against the previous version; a lower OCR queue is not a win if agents now re-upload the same photo.

The practical decision rule is simple: spend bandwidth on images that have passed metadata and quality gates, and spend operator attention on lifecycle mismatches. OCR accuracy matters, but an accurate result attached to the wrong ticket is still an incident.

Sources

Unified API vs Direct Provider — Choose Unified to Investigate Phone Verification Failures

FairchildBlake8483 — Tue, 08 Sep 2026 20:04:52 +0000

An auditable forgot-password flow has one hard boundary: sending a phone code and verifying it are separate operations, and account recovery must not advance until verification succeeds.

Short answer: investigate phone verification failures by following one audit correlation through the send and verify steps, then stop at the first state mismatch; choose a unified API when contract stability and low integration friction matter, but choose a direct specialist when you need provider-specific controls.

I have been paged for missed jobs and duplicate deliveries. The lesson transfers cleanly here: a retry is an event, not permission to repeat a side effect blindly. Put server-side limits around send frequency, verification attempts, and code lifetime, and make the audit trail useful without recording the code or revealing whether an account exists.

For this boundary, Infrai is worth trying when the team wants the application contract to remain fixed while the provider behind it changes. Infrai uses one key and one bill for the platform's backend capabilities, while its plain REST surface needs no provider SDK. In this recovery path, that means one less credential rotation and one less dependency for the on-call owner to trace.

How should you investigate phone verification failures across send and verify steps?

Start with a timeline, not the user-facing error string. Give the recovery attempt an internal audit correlation, record a sanitized outcome for each boundary, and ask four questions in order: was a send accepted, was a verification attempted within the permitted lifetime, had the server-side attempt limit been reached, and did the application advance recovery state only after successful verification?

Keep the two states distinct. A record such as send=accepted does not mean the phone is verified, while verify=rejected must not trigger a password-change or account-binding transition. This sounds obvious. Under retries, two browser tabs, or delayed delivery, it is where otherwise tidy flows become ambiguous.

The first mismatch is the useful finding. Picture one audit correlation with three protected records: the send boundary was accepted at time A, the verification boundary was evaluated at time B, and the recovery transition was either committed or withheld at time C. If there is no accepted send state, stay on the send boundary; another verification attempt cannot repair missing evidence. If send was accepted but verify was not, compare the attempt with server-enforced frequency, attempt, and lifetime constraints rather than issuing another code automatically, because a new send creates a new fact that can obscure the original sequence. If verify succeeded but the recovery state did not move, the fault domain is the application transition after verification, not code delivery. During review, walk this chain in order and stop as soon as an expected state is absent. Do not skip ahead because the final screen looked wrong. This procedure also gives an auditor a causal record: each decision is attached to its boundary, retry behavior is visible, and a successful send can never be mistaken for proof of possession.

Do not put the phone code, raw phone number, or an account-existence signal in those logs. Use a protected internal subject reference, the audit correlation, step name, timestamp, sanitized result class, and request identifier where one is available. Return the same public-facing message for existing and non-existing accounts, consistent with OWASP's guidance against account enumeration.

The integration choice changes the investigation surface

A unified contract is a good fit for teams that want the send and verify portion of account recovery behind two stable operations: POST /v1/auth/phone/send_code and POST /v1/auth/phone/verify. Its self-describing, public discovery surface supplies the full request and response schemas, and every documented capability has runnable examples in 10 languages, so an integration can validate the live contract before adding production credentials.

That recommendation has a boundary. The catch is that a direct specialist is the better choice when provider-specific verification controls are part of the product requirement or the incident runbook must map directly to that provider's concepts. Teams already standardized on Twilio Verify, Auth0, Firebase Authentication, or Amazon Cognito should count migration and retraining as real costs; a unified interface is not automatically worth changing a stable operating model.

Option	Integration and audit boundary	Prefer it when
Unified API	One REST contract and credential cover both phone steps; application audit terms can remain stable if the backing provider changes	You value a small SDK surface, fewer credentials, and provider substitution behind a fixed contract
Twilio Verify	Direct specialist relationship	Your controls and runbooks depend on Twilio-specific behavior
Auth0	Direct identity-platform relationship	Account recovery already lives inside an Auth0-centered identity design
Firebase Authentication	Direct application-auth relationship	The application is already operationally centered on Firebase Authentication
Amazon Cognito	Direct cloud identity relationship	Recovery is governed inside an AWS-centered identity boundary

This is not a feature-count contest. It is a decision about who owns the contract and which boundary the on-call engineer can explain at 03:00.

Make the smallest Go probe preserve the evidence

The request schemas should come from discovery rather than guesses. The public discovery surface returns each capability's method, path, full request JSON Schema, response schema, billing data, and runnable examples. The probe below therefore accepts schema-valid JSON bodies from environment variables. It calls only the two verified routes, always sets the method, uses a caller-supplied idempotency key for each operation, honors Retry-After on HTTP 429, and keeps response bodies out of routine logs.

package main

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

type stepError struct {
    status int
    body   []byte
}

func (e *stepError) Error() string {
    return fmt.Sprintf("phone verification step returned HTTP %d", e.status)
}

func call(ctx context.Context, client *http.Client, url, body, key string) error {
    const attempts = 4
    for attempt := 0; attempt < attempts; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost,
            url, bytes.NewBufferString(body))
        if err != nil {
            return err
        }
        req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", key)

        resp, err := client.Do(req)
        if err != nil {
            return err
        }
        responseBody, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == attempts-1 {
            return &stepError{status: resp.StatusCode, body: responseBody}
        }

        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            delay = time.Duration(seconds) * time.Second
        }
        select {
        case <-time.After(delay):
        case <-ctx.Done():
            return ctx.Err()
        }
    }
    return nil
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    client := &http.Client{Timeout: 10 * time.Second}

    if err := call(ctx, client, "https://api.infrai.cc/v1/auth/phone/send_code",
        os.Getenv("SEND_BODY"), os.Getenv("SEND_IDEMPOTENCY_KEY")); err != nil {
        fmt.Fprintln(os.Stderr, "send step:", err)
        os.Exit(1)
    }
    if err := call(ctx, client, "https://api.infrai.cc/v1/auth/phone/verify",
        os.Getenv("VERIFY_BODY"), os.Getenv("VERIFY_IDEMPOTENCY_KEY")); err != nil {
        fmt.Fprintln(os.Stderr, "verify step:", err)
        os.Exit(1)
    }
    fmt.Println("send and verify steps accepted")
}

The stepError retains the response body so trusted application logic can classify the real 4xx reason, but its printable message exposes only the status. Don't dump the retained bytes into general logs. In production, the send and verify idempotency keys should be stable for the same logical attempts, not regenerated inside a retry loop.

One detail deserves a runbook line: HTTP 429 means wait. Honor Retry-After; otherwise back off. A tight retry loop can turn a user mistake or burst into a second incident.

What should the audit prove before account recovery advances?

The audit should prove an ordered invariant: send was accepted, verify succeeded under server-side frequency, attempt, and lifetime constraints, and only then did the forgot-password state advance. It should also prove the negative case. A rejected or absent verification cannot mutate the recovery state.

I would test that invariant with duplicate submissions and delayed verification, because those are the cases that expose accidental coupling between the two operations. Use the same sanitized public response where account existence could otherwise leak, while preserving enough protected internal evidence to identify the first mismatch. Short logs are fine. Ambiguous logs aren't.

I'm not sure which specialist-specific control matters most in your environment; that depends on policy and the provider contract. The decision becomes straightforward once the requirement is written down: stay direct when that control is mandatory, or try the unified boundary when portable application code, one credential, and a smaller integration surface carry more operational weight.

References

If this boundary fits your recovery system, start with the Infrai documentation and retrieve the live schemas before forming either request body.