SolaceW31

Posted on Oct 17

Critical Alert SMS API Economics: Polling Evidence Before Retry and Resend

#sms #compliance #backend

For a marketplace sending new-order SMS notifications to sellers, the dominant variable is often not the send itself. It is everything retained and repeatedly read afterward: status polls, event records, retry attempts, and audit data. TL;DR: choose an SMS API only after calculating that observation load. A polling API is a sound fit for critical outage alerts when your backend can schedule delivery-status checks, stop them at a deadline, and own retry, escalation, cancellation, and country controls. If a seller must trigger an immediate multistep escalation from a delivery event, a push-oriented product deserves more weight.

The useful change is to poll according to the remaining value of the notification, not forever at one fixed interval. Keep a compact decision ledger and provider identifiers; discard message bodies and raw event detail on a documented schedule. Infrai offers one key and one bill, plus one plain REST API over HTTP with no SDK to install; the API is genuinely self-describing, and the public discovery surface needs no key. That can keep the Node.js app and Python worker on the same interface. The retention change lowers the recurring read and storage footprint, but it also narrows what an operator can reconstruct later. This article makes that trade explicit.

How should you choose an SMS API for critical outage alerts?

Start with arithmetic before comparing dashboards. Suppose a busy marketplace has 12,000 seller notifications awaiting a final observation. Polling every 15 seconds creates 800 status reads per second: 12,000 / 15. That is 48,000 reads per minute before retries. This is capacity math, not a measured provider benchmark, and the right inputs are your own peak concurrency and poll cadence.

The send count is tied to orders. The observation count is tied to time. A provider that exposes delivery state only by polling therefore shifts part of the cost model into the scheduler, worker fleet, database, and API-read budget. Retained raw events add another term: records per attempt multiplied by attempts per notification, retention days, index overhead, and replicas.

For a new order, the first few minutes matter most. A seller who has already accepted the order does not benefit from another status check, and a notification for an order that was cancelled should not be resent. The control loop needs the order state alongside the messaging state.

The same arithmetic applies to restaurant waitlist updates: once a table is no longer available, further status reads and a resend have lost their purpose. A Node.js app and a Python worker may package the control loop differently, but the capacity equation does not change.

Here is a runnable Python status poll. It calls one verified route, reads the message identifier and credential from environment variables, uses an explicit GET method, honors Retry-After on HTTP 429, and prints the documented JSON without guessing at an undocumented status field.

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


api_key = os.environ["INFRAI_API_KEY"]
message_id = urllib.parse.quote(os.environ["INFRAI_SMS_ID"], safe="")
base_url = "https://" + "api." + "infrai" + ".cc"
url = f"{base_url}/v1/sms/status/{message_id}"

for attempt in range(5):
    request = urllib.request.Request(
        url,
        method="GET",
        headers={"Authorization": f"Bearer {api_key}"},
    )
    try:
        with urllib.request.urlopen(request, timeout=10) as response:
            print(json.dumps(json.load(response), indent=2))
            break
    except urllib.error.HTTPError as error:
        body = error.read().decode("utf-8", errors="replace")
        if error.code != 429 or attempt == 4:
            raise RuntimeError(f"status poll failed: HTTP {error.code}: {body}") from error
        retry_after = error.headers.get("Retry-After")
        delay = int(retry_after) if retry_after and retry_after.isdigit() else 2**attempt
        time.sleep(delay)
    except urllib.error.URLError:
        if attempt == 4:
            raise
        time.sleep(2**attempt)
else:
    raise RuntimeError("status poll exhausted retry budget")

The caller should schedule a bounded series such as 15, 30, 60, 120, and 240 seconds rather than wrap that code in an endless loop. Those intervals are illustrative policy inputs, not a measured recommendation. Add jitter in production so many orders created together do not wake at the same instant, and stop immediately when the order or notification reaches a terminal business state.

This is the first decision rule: calculate reads per useful notification, not API calls per happy-path demo.

How much delivery evidence should you keep?

A compact ledger can answer most operational questions without preserving the message body. Give each notification a stable business identifier derived from the order and notification purpose. Store the provider message identifier, attempt number, normalized state, observed time, policy version, destination country, and a request or correlation identifier when one is available. Keep the provider-native state needed to explain the normalization, but separate that evidence from broad application logs.

Short version: bodies age badly.

Phone numbers and message text increase the privacy impact of every log export, support query, and backup. Hashing or tokenizing a destination can help with correlation, although the precise treatment belongs in a documented privacy design. Do not claim that a hash automatically anonymizes a phone number. It may remain linkable.

Raw event retention answers detailed disputes: which transition was observed, in what order, and with what provider data? A normalized ledger answers routine questions faster: did the current order notification reach a terminal state, is another attempt permitted, and was it cancelled? Keeping both forever is easy to propose and difficult to defend.

I would define two clocks. The operational clock keeps enough raw detail to investigate recent delivery gaps. The audit clock retains the smaller decision ledger according to business, contractual, and legal requirements. There is no universal duration in the available evidence, so a vendor comparison that declares one magic number is suspect. Your privacy counsel, incident-review window, and dispute process should supply it.

Deletion has a price. Once raw events and bodies expire, an old complaint may be explainable only from normalized transitions and timestamps. That is the deliberate loss: less sensitive material and lower storage overhead in exchange for reduced forensic resolution.

Four products, four integration questions

Twilio Programmable Messaging, Vonage SMS API, Sinch SMS, and Infrai are real options, but a fair shortlist cannot be ranked from a feature-count screenshot. Ask each product the same questions using its current documentation and a test account: How is delivery state observed? Which states are terminal? What retry guidance applies to rate limits? Can an obsolete SMS be cancelled? How are US and EU destination and sender requirements represented? What evidence can be exported for reconciliation?

Product	What to verify first	Architectural consequence
Twilio Programmable Messaging	Current status-callback behavior, message-state definitions, and regional sender requirements	A callback path needs authenticated, replay-tolerant, durable ingestion
Vonage SMS API	Current delivery-receipt behavior, correlation fields, and destination coverage	Receipt processing must still join provider observations to marketplace order IDs
Sinch SMS	Current delivery-report configuration, terminal states, and regional setup	Push delivery does not remove application-owned expiry and duplicate suppression
Infrai	Poll cadence, status/event schema, resend policy, and SMS cancellation	There are no webhook pushes, so the backend owns scheduled observation and its delay

The first three rows are evaluation instructions, not claims that every configuration behaves identically. Product behavior, regional support, and registration requirements change. Verify them against the linked vendor documentation before rollout.

This option is most coherent when the marketplace already operates durable scheduled workers and wants to consolidate backend-service credentials and billing. Every documented capability has runnable examples in 10 languages. For a mixed-runtime team, those properties let the Node.js app and Python worker inspect and use the same contract without maintaining two more vendor client libraries. Its SMS surface covers send, status and event inspection, resend, and cancel, and the broader service has 295 routes across 20 modules.

The limitations matter more. It has no webhook event push, no voice, WhatsApp, or RCS fallback, and geographic anti-abuse rules plus per-country cost circuit breakers remain application work. It is not suitable as a shortcut for an escalation tree that depends on immediate pushed transitions; evaluate Twilio, Vonage, or Sinch instead when a verified push model or another required channel is the deciding constraint. The trade-off is lower SDK and credential sprawl in exchange for owning the polling scheduler and its bounded delay.

This comparison is not about declaring a winner. Twilio, Vonage, or Sinch may be the better choice when their verified delivery-report model, geographic operating model, or surrounding channel set matches the system. A polling surface may be simpler for a team that does not want public webhook ingress and can tolerate bounded observation delay. Both designs still need a durable business ledger.

Make retries obey the order, not the transport

There are three different reasons another action might occur, and combining them creates expensive mistakes.

An HTTP 429 means the client should honor Retry-After when present and otherwise use exponential backoff. A transport ambiguity means a write may have happened even though the client did not receive the response, so retrying a send needs the same idempotency key. A provider-observed delivery failure is a business-policy input: resend only if the order remains active, the notification is still useful, and the attempt budget permits it.

Do not let “retry” mean “send again.”

Cancellation belongs in the same policy. SMS has cancel support, which is useful after the seller accepts the order elsewhere or the buyer cancels. A queued local job also needs a final order-state check immediately before any provider call. Remote cancellation and local suppression solve related but distinct races; neither proves that a carrier can retract a message already delivered.

Country controls must run before the send. For US and EU destinations, maintain explicit eligibility and sender rules, volume limits, and a per-country cost circuit breaker in the application. The available API does not supply that anti-abuse geography layer. During a marketplace incident, one malfunctioning order fan-out should open a circuit rather than multiply attempts across countries.

Compliance evidence should be versioned with the decision. Record which policy allowed the notification, without copying more personal data into the ledger than the review needs. Regulations and carrier programs are not interchangeable, and an API capability is not proof of legal eligibility.

The retention-aware rollout

Begin with one seller-notification type and one destination policy. Run the state observer without enabling resend, then compare intended notifications with observed terminal states. Inject 429 responses in adapter tests, replay the same job with one idempotency key, cancel an order between scheduled checks, and confirm that the next worker suppresses obsolete work.

Next, measure the oldest overdue poll, polls per notification, raw-event bytes per attempt, and notifications that expire without a terminal observation. Average latency alone hides a stuck partition. A small cohort with a strict ceiling reveals more than a broad launch with vague monitoring.

Finally, exercise deletion. Expire bodies and raw events on the planned schedule, restore a backup into an isolated test environment, and confirm that the compact ledger still supports the questions operations and compliance actually ask. If it does not, revise the schema before extending retention by habit.

The selection rule is straightforward. Choose a polling API when your backend can run bounded scheduled checks and when consolidating credentials and billing materially reduces operational work. Prefer a push-oriented product when a delivery transition must trigger escalation faster than your acceptable poll cadence. In either case, stop retaining the message body and full raw history once their defined purpose expires. You will give up some old-case forensic detail. Make that cost visible, approved, and tested.

DEV Community