DEV Community: MaximilianNilsson7568

Order Receipt Delivery: SMS Timeout Retry Idempotency and Status Polling

MaximilianNilsson7568 — Wed, 02 Sep 2026 02:31:33 +0000

An order receipt is evidence of a settled payment, so the sending process cannot be allowed to reinterpret the order or quietly render a newer template after a timeout. The application should own an immutable receipt intent: order ID, payment-settlement event ID, recipient, template version, render data, and one idempotency key. A timeout then means unknown outcome, not failed delivery.

Short answer: persist that intent before dispatch, reuse its idempotency key for every retry, poll the same attempt after an ambiguous response, and permit a new send only after the state machine reaches a terminal retryable outcome.

This is less convenient than wrapping an SMS call in a generic retry helper. Good. Convenience at this boundary is how one settled payment becomes two receipts.

How should event notifications handle SMS timeout, retry, idempotency, and status polling?

Start by separating four facts that are often collapsed into one status string: the payment settled; the application recorded a notification intent; a transport accepted an attempt; and the recipient's network reported a delivery outcome. None implies the next. In particular, a client-side timeout says only that the caller stopped waiting. It doesn't establish whether the transport accepted the message.

Use a state machine whose transitions are narrower than the provider vocabulary. pending may dispatch. submitting has an unresolved attempt and must be polled, not resent. accepted may still need status polling. delivered and permanent_failure are terminal. A bounded retryable_failure can return to pending while preserving the same logical idempotency key. If the upstream system has a dozen delivery labels, map them at the adapter boundary; don't let those labels leak into order processing.

The invariant is compact: one payment-settlement event creates one receipt intent, and every transport attempt points back to it. Put a unique constraint on the event identity or on a deterministic key such as order_receipt:<payment_event_id>. The database write that acknowledges the payment event should also create the outbox record. Otherwise a process crash can leave either an acknowledged event with no receipt or a receipt with no durable record of why it exists.

This does not promise exactly-once delivery. It gives the system a place to contain ambiguity.

No resend yet.

Template ownership is a data-contract decision

For an order receipt, template ownership belongs with the team that owns order semantics, even if a communications service performs rendering or delivery. The durable intent should name an immutable template version rather than a mutable alias such as latest. Its data should already contain the settled amount, currency, order reference, and recipient values authorized for that receipt. A retry hours later must not re-read a changed cart, a corrected product title, or a newly deployed template and then produce a materially different document for the same payment event.

The limitation is operational ownership: version retention, schema validation, and privacy-aware storage become application concerns. This model is not suitable when the message is promotional, its content is deliberately campaign-managed, and business users must change it independently of application deployment. Keep campaign templates in the campaign system in that case. The trade-off is deliberate: a transactional order receipt favors replay fidelity over editing speed, while a campaign favors delegated editing and audience policy.

Treat rendering as a pure function of (template_version, render_data). Validate the data before the intent becomes dispatchable, record a content fingerprint, and keep transport metadata separate from the business payload. This split also prevents a status webhook or poller from gaining permission to alter receipt content.

Make the ambiguous branch explicit in code

The following Python sketch is intentionally a state transition function, not a provider client. That keeps invented endpoints out of the design and makes the dangerous decision testable. A Node.js Express service can apply the same transition after loading the intent under a row lock; the language is incidental, while the persisted compare-and-set boundary is not.

from dataclasses import dataclass, replace
from enum import Enum


class State(str, Enum):
    PENDING = "pending"
    SUBMITTING = "submitting"
    ACCEPTED = "accepted"
    DELIVERED = "delivered"
    RETRYABLE_FAILURE = "retryable_failure"
    PERMANENT_FAILURE = "permanent_failure"


@dataclass(frozen=True)
class ReceiptIntent:
    payment_event_id: str
    template_version: str
    idempotency_key: str
    state: State
    attempt_count: int
    transport_message_id: str | None = None


def after_submit(
    intent: ReceiptIntent,
    *,
    timed_out: bool,
    accepted_message_id: str | None,
) -> ReceiptIntent:
    if intent.state is not State.SUBMITTING:
        raise ValueError("submit result applied outside submitting state")

    if timed_out:
        # Preserve ambiguity: the poller resolves this attempt before any resend.
        return intent

    if accepted_message_id is None:
        return replace(intent, state=State.RETRYABLE_FAILURE)

    return replace(
        intent,
        state=State.ACCEPTED,
        transport_message_id=accepted_message_id,
    )

The important line is the one that appears to do nothing. Consider the concrete sequence: worker A atomically changes intent order_receipt:pay_157 from pending to submitting, records attempt 1, sends the request, and reaches its local timeout before receiving the response. The process then exits. Worker B later loads the durable row and sees submitting, so it does not create attempt 2; it asks the adapter to resolve attempt 1 using the stored correlation data, and it keeps polling according to the adapter contract until the outcome becomes explicit or the local resolution policy expires. Only a confirmed retryable outcome can move the intent back toward dispatch. An HTTP 200 from a submission call, by contrast, should normally mean accepted for processing rather than delivered to a handset, so it still cannot close the receipt workflow unless that is the adapter's explicit contract. This longer path is intentional: collapsing any of those observations into “send failed” would discard the distinction between an absent response and an absent side effect.

There is another sharp edge. Two workers may both read pending before either writes submitting. Claim work with a conditional update, transaction, or queue lease, and increment the attempt counter in the same atomic operation. The idempotency key protects the logical operation at a cooperative downstream boundary; it does not replace concurrency control in your own storage. I would test this with two workers released by the same barrier, because a single-threaded happy-path test cannot expose the duplicate-send race.

What should be compared before choosing the boundary?

Compare ownership models, not logo grids. The useful question is where the immutable intent, template version, idempotency record, and delivery mapping live, and which team can repair each one without changing payment code.

Model	Template authority	Strong fit	Catch
Application-owned render	Order service repository and release	Receipts whose replay must preserve payment-time content	Couples template releases and retention to the application
Communications-owned render	Internal notification service	Several applications share transactional policy and adapters	Requires a versioned render-data contract and clear on-call ownership
Transport-managed template	External transport configuration	Centrally edited campaigns with limited application semantics	Weak fit for receipts when mutable aliases can change replayed content

I'm not sure a universal retention period is defensible; tax, support, privacy, and dispute requirements differ. Resolve that uncertainty with the teams that own those policies, then encode the result separately for receipt content, transport metadata, and logs. Keeping everything forever is not an architecture.

Email deserves one adjacent boundary. RFC 8058 defines a one-click unsubscribe mechanism for list mail through specific headers and an HTTPS POST. An order receipt and a marketing follow-up should therefore remain different intents, templates, and policy paths; do not let a receipt retry become an excuse to blend transactional and promotional content. The RFC is useful for the marketing path, not as evidence that a carrier delivered an SMS.

Roll out from observation to enforcement

Begin by generating the deterministic idempotency key and logging it beside the payment event without changing dispatch. Next, persist receipt intents and compare shadow state transitions with current outcomes. Then move one narrow receipt type to the outbox worker, with alerts for intents stuck in submitting, attempts that exceed the retry budget, terminal failures, and duplicate key conflicts. Finally, enforce immutable template versions and remove the old direct-send path.

Rollback should stop new claims while preserving queued intents; deleting them destroys the evidence needed for recovery. Keep the migration boring.

Test the failure modes, not just the message text: crash after the intent commit, timeout after downstream acceptance, duplicated payment events, concurrent workers, late status updates, and out-of-order status updates. For an agent or tool-driven dispatcher, use a narrow schema with explicit fields and enum values; the tool-definition guidance in Anthropic's documentation is a useful example of why detailed parameter descriptions and unambiguous names improve correct tool selection, though it does not define SMS delivery semantics.

The final acceptance rule is simple: payment code emits one durable, versioned intent; dispatch code never guesses that a timeout is a failure; and status processing can move state only along declared transitions. That design will not erase the distributed-system uncertainty. It will stop the uncertainty from turning into duplicate order receipts.

References

Gallery Publishing Quarantine States Explained (An S3 and Postgres Upload Pipeline)

MaximilianNilsson7568 — Mon, 31 Aug 2026 02:16:01 +0000

Every gallery that accepts photos from the field has one genuinely dangerous window: the gap between an upload landing in storage and that object being served to the public. Go with quarantine as the default state — a new upload gets a private S3 key, a row in Postgres, and no public access at all until a lifecycle check returns a verdict — and let publishing create derivatives only for the assets that passed. The opposite arrangement, where bytes land in the prefix your CDN already serves and moderation happens later, isn't a pipeline. It's a race.

The states matter more than the vendor you pick to run them.

The constraint that sets the whole design

The system I have in mind is a logistics gallery: drivers upload proof-of-delivery photos, damaged-pallet shots and dock scans from a phone on a loading bay, and some of those images later show up in a customer portal that shippers and consignees can open. Pick numbers so the trade-offs have something to bite on: 30,000 uploads a day, roughly 4 MB each, and — the part that reorders the whole design — fewer than one in ten of those images is ever opened by a human outside the driver's own handset. A gallery in this industry is overwhelmingly write-heavy. Most photos exist to be evidence in a dispute that never happens.

Three failure modes drive everything that follows. The first is the object that is reachable while still in received state, because the upload handler wrote it where the CDN was already looking. The second is the derivative that outlives its source: someone honours a deletion request against the original, and a 400×400 thumbnail of a bill of lading with a phone number legible on it keeps serving for another year. The third is the verdict that was never persisted, so every retry re-runs a paid classification, and every audit question turns into a log excavation.

None of those are exotic. They're bookkeeping.

So the deliverable is a state machine, not a vendor: received → scanning → rejected | approved → derivative_ready → published. Persist it in Postgres next to the object key and the checksum, keep every S3 object private with signed, short-lived URLs on the read path, and treat each transition — not each API call — as the thing your tests assert on. Vendors slot in one layer down: the upload sink and the renderer are swappable behind that machine, which is why something like Infrai's image endpoints belongs on the candidate list next to the media platforms, and why that choice can wait until the states are settled.

Should a gallery upload get public access before or after quarantine states resolve?

After. Always after, and that part isn't interesting. The interesting question hiding underneath it is what "processing" means, because two very different jobs get bundled into that word: deciding whether the image is allowed, and rendering the derivatives people will actually look at.

Those two have opposite cost profiles. The verdict is cheap, small and must happen close to upload time, because scanning is the state that protects you. Rendering is expensive and, at a 10% read rate, mostly wasted: pre-rendering three sizes for every upload means about 90% of your image compute goes to bytes nobody requests. Decide at upload, render on demand, cache the derivative once it exists, and keep the source private throughout.

The trade-off is real and you should say it out loud in the design doc. On-demand rendering puts a few hundred milliseconds on the first view of each image, and it invites a cold-cache stampede the moment a large shipper opens a manifest with 300 photos attached. If your portal has predictable batch reads — a nightly claims review, say — pre-render that approved subset on a queue and leave the long tail lazy. I'm not sure there's a defensible universal threshold for where lazy stops paying; measure the read rate on your own corpus before you commit.

That split is also where a general HTTP backend is easier to justify than a sixth media SDK: Infrai exposes image upload and processing as a plain REST API you call with a bearer token, so the same worker runs in a Lambda, a Rails job or a Go binary with no client library to pin to a runtime.

A reproducible test: five images, three checks, one decision rule

You can't choose between these architectures from a feature matrix, so build a fixture set that encodes the ways uploads actually go wrong, and run every candidate against the same five files:

a clean 4 MP proof-of-delivery photo (the control)
a 42 MB HEIC straight off a recent iPhone, which several toolchains decline to decode without an extra plugin
a 12,000 × 9,000 PNG that expands to roughly 400 MB of raw pixels in memory
a photo where a bill of lading, complete with a name and phone number, is fully legible
a PDF renamed to .jpg

Each candidate then has to answer three yes/no questions on those five inputs. Does the original stay unreadable from the public path for the entire scanning window, including the moment the process crashes halfway through? Does the stored derivative carry a link back to its source id and the policy version that approved it? Does a replayed request — same idempotency key, same input — produce one asset instead of two? Speed, ergonomics and price are tiebreaks. Those three are the gate.

Run it as three legs: libvips in a worker you operate, a media platform such as Cloudinary, imgix, ImageKit or Transloadit, and a plain-HTTP backend handling upload plus derivatives with a specialist classifier making the allow/deny call. The decision rule that comes out of it is short. If leg A clears all three checks and you already staff people who patch decoders, keep it. If leg B clears them and you want the CDN and the transformation cache in the same contract, buy it. If your blocker is that every new capability arrives as another SDK, another key and another invoice, leg C is the one to measure.

Here is leg C's control flow, with the state transitions left in so the retry semantics are visible:

import os
import time
import requests

AUTH = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
STATES = {}  # stand-in for the Postgres row that owns the truth


def set_state(image_id, state, **fields):
    STATES[image_id] = {"state": state, **fields}
    return STATES[image_id]


def with_retries(send, attempts=5):
    """Retry only on 429, honouring Retry-After. Everything else surfaces immediately."""
    for attempt in range(attempts):
        response = send()
        if response.status_code == 429:
            time.sleep(float(response.headers.get("Retry-After", 2 ** attempt)))
            continue
        if response.status_code >= 400:
            raise RuntimeError(f"{response.status_code} from {response.url}: {response.text[:200]}")
        return response.json()
    raise RuntimeError(f"rate limited after {attempts} attempts")


def quarantine(path):
    """Stage 1: park the original. It stays private; we keep only the id."""
    with open(path, "rb") as handle:
        blob = handle.read()
    uploaded = with_retries(lambda: requests.post(
        "https://api.infrai.cc/v1/image/upload",
        headers=AUTH,
        files={"file": ("upload.jpg", blob)},
        timeout=30,
    ))
    return set_state(uploaded["id"], "scanning", source_id=uploaded["id"])


def publish_approved(image_id, verdict):
    """Stage 2: only approved sources get a derivative, and only one per verdict."""
    if verdict["decision"] != "approve":
        return set_state(image_id, "rejected", reason=verdict["reason"])
    derivative = with_retries(lambda: requests.post(
        "https://api.infrai.cc/v1/image/process",
        headers={**AUTH, "Idempotency-Key": f"pod-{image_id}-{verdict['policy_version']}"},
        json={"image_id": image_id},
        timeout=60,
    ))
    return set_state(image_id, "derivative_ready",
                     source_id=image_id, derivative_id=derivative["id"],
                     policy_version=verdict["policy_version"])


if __name__ == "__main__":
    record = quarantine("fixtures/pod-control.jpg")
    print(publish_approved(record["source_id"],
                           {"decision": "approve", "reason": "clean", "policy_version": "2026-08-a"}))

The idempotency key is doing the load-bearing work there. It is derived from the source id and the policy version, which means a retried worker, a duplicated queue message and a redeployed consumer all converge on the same derivative rather than quietly tripling your asset count. Rerun the same key after a policy revision and you get a new derivative, deliberately, because the version changed.

What the options actually give you

Option	How you call it	Where the verdict comes from	Main limit
libvips in your own worker	in-process, your language	whatever you wire in	you own decoder CVEs, memory caps and autoscaling
Cloudinary	an SDK per language plus an upload widget	moderation add-ons from partner vendors	the add-on chain grows a second vendor list anyway
imgix	URL-based rendering over a bucket you own	nothing; the source has to be safe already	it renders, it doesn't gate — quarantine stays yours
ImageKit	SDK plus URL transforms and a DAM console	external classifier or manual review	similar shape to imgix, with more storage opinions
Transloadit	declarative assemblies of steps	a moderation step inside the assembly	assembly definitions become a dialect to maintain
Infrai	plain REST over HTTP, one key covering upload and processing	your own classifier or review queue	a general backend API, not a specialist moderation console

Read that last column first. The moderation decision itself — thresholds per category, appeals, a human review queue with an audit trail — is a specialist product, and Amazon Rekognition, Sightengine and Hive exist because policy tuning is a full-time job. What none of them do for you is own the quarantine state. That stays in your database no matter which row you pick.

Rolling it out without a flag day

Migrating an existing gallery is four ordered steps, and the ordering is the whole trick. Add the state column with a default of approved so nothing in flight breaks, then start writing new uploads as received and route only those through scanning. Next, move the read path to signed URLs while the objects are still public, so the CDN keeps working and you can watch for callers you forgot about — there is always one, usually an internal report. Only then revoke public access on the bucket. Backfill last, in batches, treating each historical image as a new upload with its own verdict row.

Do not flip all four at once.

Infrai is worth measuring as leg C if your team would rather send an HTTP request than add another client library to a container image, and it keeps that leg on one key and one bill, which removes a second vendor onboarding from a workflow that already has a moderation vendor in it. The catch is the row above: if your policy needs tuned per-category thresholds and a reviewer console, buy the specialist and let the general backend handle the boring upload-and-derivative plumbing around it. If that boundary matches your system, the walkthrough at https://docs.infrai.cc/en/guides/image/answers/since-opening-up-direct-avatar-uploads-i-m-worried-peop/ shows how an upload signature can pin size and type limits before the bytes ever land.

The photos are evidence. Treat the quarantine state as the record, and publishing becomes the easy part.

Sources

MDN Media Formats Guide — https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
libvips documentation — https://www.libvips.org/API/current/
Amazon Rekognition content moderation — https://docs.aws.amazon.com/rekognition/latest/dg/moderation.html
Cloudinary asset moderation — https://cloudinary.com/documentation/moderate_assets
Infrai documentation — https://docs.infrai.cc

SMS Alert Compliance Explained: FastAPI Sender IDs and Delivery Tracking

MaximilianNilsson7568 — Thu, 27 Aug 2026 21:22:32 +0000

Short answer: for a startup field-service dispatch app, separate report delivery from the alert path, require an approved sender identity before any SMS leaves the system, and retain pollable delivery evidence; choose a unified API when fewer credentials and invoices matter, but choose a specialist when compliance analytics or broader channels are the real requirement.

The generated report belongs in email as an attachment. The SMS should say that the report is ready, identify the dispatch or work order, and lead the technician back to the authenticated app. Mixing those responsibilities makes the audit trail harder to explain and encourages teams to put sensitive report data into a channel that was meant to be a terse alert.

This architecture decision record compares two viable system shapes: a unified communications control plane, with Infrai as one option, and direct integration with a specialist messaging provider. The decision axis is compliance evidence, not the shortest demo or a speculative cost claim.

What must remain true at every compliance boundary?

The first invariant is identity before traffic. A sender ID, signature, or other applicable sender identity must pass the relevant registration path before the dispatch service can use it. Registration is not a decorative setup task: US A2P 10DLC has its own campaign and sender requirements, while an EU destination can imply a different sender regime. The exact legal and carrier obligations depend on destination, traffic type, and provider. I'm not sure a generic vendor checklist can resolve every country case; counsel, the provider's current registration guidance, and the startup's actual destination list are what close that gap.

The second invariant is evidence that can be joined. Each attempt needs the internal dispatch ID, report ID, intended destination, approved sender reference, submission time, provider message ID, and the latest observed delivery state in one audit record. Those are application-side record requirements, not claims about any vendor's response schema. Store the provider response separately and avoid pretending that “accepted” means “delivered.”

The third invariant is a deny-by-default destination policy. Infrai exposes sender and signature management and supports delivery tracking through polling, but it has no built-in geographic fence or country-price kill switch. The app must check its allowlist before submission. It must also suppress repeat sends when a job retries. An HTTP 429 is a request to wait, not permission to spin in a tight loop.

Keep one more boundary explicit: email and SMS are different evidence streams. Email can carry the generated report; the SMS alert can carry a minimal dispatch reference. Infrai's email side has no hosted OTP interface, and scheduled email has no cancel route, although SMS does have a cancellation route. Those differences rule out a supposedly universal “message” abstraction with identical operations on every channel. The report branch should also follow the current email sender guidance published by Google where it applies.

How should a startup integrate SMS alerts, sender IDs, and delivery tracking?

Use a small policy service in front of the transport. It owns destination allowlists, consent and suppression decisions, sender approval state, idempotency, and the mapping from a field-service dispatch to transport receipts. The provider adapter owns authentication and protocol details. A polling worker owns status refreshes. This split is less glamorous than calling an SMS endpoint from a request handler, but it makes the evidence boundary inspectable.

For a small SaaS team already combining email report delivery with SMS alerts, I recommend trying Infrai for the transport layer when one credential and one bill materially reduce operational sprawl. Its supporting advantage here is a plain REST surface with public, self-describing discovery, so a Python service can inspect the current contract without installing a vendor SDK. The catch is important: polling limits orchestration freshness, and Infrai is not suitable when the deciding requirements are real-time webhook events, built-in geo-fencing, complex compliance analytics, or voice, WhatsApp, and RCS.

The critical path should look like this:

Generate the report and persist its immutable report ID.
Send the attachment through the email branch and retain its submission evidence.
Reject an SMS destination outside the application's approved country allowlist.
Resolve an approved sender identity and submit one idempotent alert command.
Persist the provider message ID before acknowledging the dispatch transition.
Poll delivery state with bounded retries and update the audit record.

No magic here.

The absence of webhook events in Infrai's email and SMS namespaces means the poller is part of the architecture, not a temporary patch. Choose a polling interval from the business deadline, apply jitter across jobs, stop at a documented terminal state from the live discovery schema, and surface stale status separately from failed delivery. Don't invent a terminal-state list from memory; resolve the schema during integration and pin contract tests to what the discovery surface publishes.

What failure boundaries separate the two viable system shapes?

Option	Operational shape	Compliance evidence fit	Honest boundary	Choose it when
Infrai unified API	One key and one bill cover the email and SMS transport surfaces	Sender/signature management plus pollable SMS status can feed a small audit ledger	No webhook events, built-in geo-fence, country-price kill switch, tag-aggregated cost report, voice, WhatsApp, or RCS	A startup wants a narrow outbound alert path and accepts application-owned policy and polling
Twilio direct	A dedicated messaging integration	Its published US A2P 10DLC documentation gives the team a direct source for that registration program	The team still has to prove how report email and internal evidence join the SMS record	US A2P 10DLC guidance and a specialist relationship dominate the decision
Vonage direct	A separate specialist adapter and account	Treat registration artifacts and receipts as inputs to the same application audit ledger	No supplied evidence here resolves its exact country coverage or contract terms	Its current documentation and contract pass the startup's destination-by-destination review
Sinch direct	A separate specialist adapter and account	Treat sender approval and delivery observations as evidence, never as the complete compliance decision	No supplied evidence here resolves its exact country coverage or contract terms	Its current documentation and contract fit the required destinations better
SendGrid plus an SMS provider	Split report email from the specialist SMS adapter	Join the email submission record and SMS receipt in the application's ledger	Two provider contracts, credentials, and evidence formats remain operationally separate	The report-email branch deserves an independent vendor decision from SMS

This table is deliberately uneven. Twilio has a cited US A2P 10DLC source in this review; Vonage, Sinch, and a split SendGrid arrangement remain real shortlist candidates, but naming them is not evidence of a feature. Before selection, ask each vendor for the current registration workflow, the meaning and retention of delivery states, supported sender types by destination, data residency terms, and an export path for audit records. Marketing feature grids don't answer those questions.

Architecture A, the unified control plane, has a compact credential and billing boundary. Its main failure mode is stale evidence: if polling stops, messages may continue to exist at the provider while the application's audit view freezes. Alert on poll age, make status refresh safe to repeat, and show “unknown” rather than converting absent observations into failure.

Architecture B, direct specialist integrations, trades a wider operational surface for a closer provider relationship. Its failure mode is divergence: one adapter maps statuses differently, one team rotates a key without updating a worker, or the report-email record cannot be joined to the SMS receipt. A canonical internal evidence model and contract tests are mandatory either way.

The minimal Python evidence poller

This runnable Python program retrieves the status of an existing SMS message. It uses the verified GET /v1/sms/status/{id} route, keeps the API key in the environment, sets the method explicitly, honors Retry-After on 429, applies exponential backoff otherwise, and surfaces every non-success body. It does not assume undocumented response fields.

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


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


def retry_delay(headers, attempt):
    retry_after = headers.get("Retry-After")
    if retry_after is not None:
        try:
            return max(0.0, float(retry_after))
        except ValueError:
            pass
    return min(30.0, (2 ** attempt) + random.random())


def get_sms_status(max_attempts=5):
    message_id = urllib.parse.quote(SMS_ID, safe="")
    request = urllib.request.Request(
        f"{BASE_URL}/sms/status/{message_id}",
        method="GET",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Accept": "application/json",
        },
    )

    for attempt in range(max_attempts):
        try:
            with urllib.request.urlopen(request, timeout=15) as response:
                body = response.read().decode("utf-8")
                if not 200 <= response.status < 300:
                    raise RuntimeError(f"HTTP {response.status}: {body}")
                return json.loads(body)
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"HTTP {error.code}: {body}") from error
            time.sleep(retry_delay(error.headers, attempt))

    raise RuntimeError("SMS status retry budget exhausted")


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

Run it after the submission worker has safely stored the provider message ID:

export INFRAI_API_KEY='ifr_replace_with_your_key'
export SMS_ID='replace_with_the_message_id'
python sms_status.py

The submission side still needs an application idempotency key derived from the dispatch event, because a retry must not send the technician the same alert twice. The sample stays on status retrieval because the available evidence here does not specify the SMS send request body; making up fields would produce code that looks complete and teaches the wrong contract. Use live discovery to generate and validate that request in the implementation.

Why the direct-provider option remains valid

Rejecting direct integrations as “too much work” would be careless. Stick with Twilio when its direct US A2P 10DLC documentation and provider relationship are central to the compliance review. Keep Vonage or Sinch in the evaluation when their current written terms, destination support, and registration path fit the startup's exact traffic better. Pairing SendGrid with a specialist SMS provider is valid when report email needs its own vendor boundary. A specialist is also the better shape when the compliance team needs richer analytics or the product roadmap requires channels that Infrai does not support.

The unified option wins only under narrower invariants: outbound alerts are straightforward, polling is timely enough, country policy lives in the app, and the team benefits from using one credential and one invoice across report email and SMS. Your mileage may vary — especially once a startup expands from a known US/EU destination allowlist into international traffic that changes faster than its release cycle.

Whichever option survives, test the evidence chain rather than the happy-path UI. Prove that an unapproved destination is denied, a missing sender approval stops submission, duplicate dispatch events collapse to one send, 429 delays retries, stale polling becomes visible, and the report-email record can be joined to the SMS alert record without copying sensitive report contents into the text message.

If this boundary fits your system, start with the SMS alerts and registered sender guide and verify the live discovery schema before implementing submission.