Short answer: Choose the SMS service whose polled delivery states can drive recipient suppression without provider-specific logic; the lowest advertised rate matters less if an invalid number keeps re-entering a media alert campaign.
For a US and EU transactional notification system with no webhook receiver, the deciding constraint is integration effort: one send call, one status lookup, and a small state machine that a test harness can replay. Give each candidate the same fixtures, normalize its delivery response at one adapter boundary, and measure how often the application reaches an unambiguous terminal decision. A send-only prototype fails this test because an accepted request proves submission, not final delivery. The better design polls only unsettled messages and records suppression separately from message history.
Accepted isn't delivered.
This is a selection method, not a vendor ranking. Published prices, country coverage, sender rules, and status vocabularies can change; verify each candidate's current documentation and contract before committing.
How should you compare a transactional SMS alerts API for US and EU notifications?
Start with a capability matrix, but score the adapter you would have to own. The useful question is not whether a dashboard displays a delivery state. It is whether the API exposes a stable message identifier after submission and lets the application retrieve a documented, machine-readable state later, without requiring a webhook.
| Test | Evidence to capture | Reject or investigate when |
|---|---|---|
| Submission | Message ID and acceptance state | The response cannot be correlated with a later lookup |
| Polling | Documented lookup operation and state vocabulary | Only webhook delivery evidence is available |
| Finality | Explicit terminal success and failure states | A pending state has no documented policy |
| Recipient validity | A documented signal that supports suppression | Every failure collapses into one opaque label |
| Regional fit | Current US and EU destination and sender requirements | Required media markets cannot be tested |
| Operations | Rate-limit and authentication documentation | Safe polling behavior cannot be designed from the contract |
The catch is that "simplest" depends on the evidence the product needs. A newsroom sending an editorial correction may need final delivery evidence. An internal low-stakes reminder may tolerate an accepted state and a short retention window. Don't award points for fields that never affect a decision. Every extra external state becomes adapter code, fixtures, observability labels, and maintenance.
Likewise, "cheapest" should mean expected cost for the workload, not one headline unit price. Build a worksheet from the candidate's current terms: submitted messages, regional routing, sender requirements, status lookups, retries, and the engineering time needed to maintain the adapter. No universal winner follows from those inputs. Your mileage may vary sharply with recipient geography and how long messages remain unsettled.
Model suppression as a separate decision
A message record answers what happened to one attempt. A suppression record answers whether another attempt should be allowed. Mixing them makes retries dangerous: a transient state from yesterday can look like permission to send today, while one permanent recipient failure can disappear among newer rows.
Keep the application vocabulary small. queued and sent are unsettled; delivered is successful; invalid_recipient is a permanent recipient signal; failed needs a documented reason before it can change recipient eligibility. Those names are a local domain model, not claims about any provider's exact labels. Each adapter maps only documented external states into them. Unknown values stay unknown and page an operator rather than silently suppressing a reader.
One boundary matters most: suppress only on evidence that the recipient itself is invalid. A timeout, authentication problem, content rejection, or regional sender restriction says nothing reliable about whether the phone number can receive a later alert. Treating every failure as a bounce will quietly erase valid subscribers. Treating every failure as retryable does the opposite and repeatedly targets known-invalid numbers.
Be conservative.
Email needs a parallel but distinct path. SPF is a protocol for authorizing hosts to use domains in SMTP identities, as specified by RFC 7208; it does not validate a telephone number or define an SMS delivery result. A media product that sends both email and SMS can share a recipient-policy interface, but its channel adapters must preserve those different semantics.
A focused polling worker
The adapter below uses a generic interface because route shapes and response fields must come from the service being evaluated. It shows the contract the application should demand. The worker selects due messages, polls once, normalizes the result, and writes suppression only for the permanent recipient outcome.
from dataclasses import dataclass
from typing import Literal, Protocol
DeliveryState = Literal[
"queued", "sent", "delivered", "invalid_recipient", "failed", "unknown"
]
@dataclass(frozen=True)
class DeliveryResult:
message_id: str
state: DeliveryState
reason: str | None = None
class SmsAdapter(Protocol):
def get_delivery(self, message_id: str) -> DeliveryResult: ...
def reconcile(message: dict, adapter: SmsAdapter, store) -> None:
result = adapter.get_delivery(message["provider_message_id"])
store.record_delivery(message["id"], result.state, result.reason)
if result.state == "invalid_recipient":
store.suppress(
channel="sms",
recipient=message["recipient"],
reason="invalid_recipient",
evidence_message_id=result.message_id,
)
elif result.state in {"delivered", "failed"}:
store.stop_polling(message["id"])
elif result.state == "unknown":
store.flag_for_review(message["id"], result.reason)
else:
store.schedule_next_poll(message["id"])
The focused failure case is easy to miss in a notebook. Imagine a breaking-news alert submitted to 20,000 opted-in recipients. One number returns a documented permanent invalid-recipient result. The campaign table still contains that subscriber, and tomorrow's digest builds a fresh message row. If suppression is merely a flag on yesterday's attempt, the number is sent again. With a channel-plus-recipient suppression key checked before message creation, the new attempt is never submitted. Meanwhile, a different recipient whose status is still sent remains eligible for polling but not for an immediate duplicate send. This distinction is why the data model deserves more attention than the HTTP client.
Don't copy the polling interval from an example. Derive it from documented rate limits, the product's latency target, and the maximum useful age of an alert. Use bounded backoff with jitter, stop at documented terminal states, and cap the number of unsettled records processed per run. The exact schedule cannot be selected responsibly without the candidate's current contract and observed status-latency distribution.
Evaluate before migrating the notebook
Turn the selection into a replayable evaluation. Create fixtures for accepted, delivered, permanently invalid, transient or ambiguous failure, unknown external state, and a message that remains unsettled across several polls. Then run every candidate adapter against the same assertions. This is the notification equivalent of an eval harness: the score is based on decisions the product can safely make, not on how pleasant one happy-path request looks.
For each run, capture normalization coverage, time from submission to a terminal state, lookup requests per message, duplicate submissions, false suppressions, and invalid recipients submitted again. The last two metrics pull in opposite directions, so optimizing only one is a trap. Also record adapter code size and the number of provider concepts that leak past it; they are imperfect but concrete indicators of integration effort.
Measure both.
Prompt and model costs are irrelevant to this transport loop unless an AI feature generates message content. If it does, evaluate content generation separately and freeze the rendered text before submission. A delivery retry must reuse the approved content, not invoke a model again and create a different alert or another token charge. Authentication messages need another boundary: OWASP's forgot-password guidance treats reset codes or tokens as security-sensitive, recommends single use and expiration, and warns against account-enumeration behavior. A media headline alert should not inherit password-reset semantics, while an actual OTP flow should not be designed as ordinary editorial messaging.
A polling-only service is not suitable when the required delivery latency is tighter than a safe lookup schedule, when the service cannot expose final state through retrieval, or when polling volume overwhelms the operational budget. In those cases, choose a candidate with a documented webhook path and operate the receiver. Conversely, stick with polling when inbound infrastructure is the larger burden and delayed status evidence is acceptable. That's a real trade.
What to measure before choosing
Run a small, consented test set across the actual US and EU markets you intend to serve, following the candidate's current rules. Do not infer regional support from a generic marketing page. Record the raw documented state, normalized state, timestamps, and suppression decision, but minimize retained recipient data and control access to it.
The decision rule can stay compact: reject any candidate that cannot provide correlation, retrievable status, and a defensible invalid-recipient signal; among the remaining candidates, select the adapter with the lowest measured integration and operating burden for the latency target. Re-run the fixtures when the external status vocabulary or contract changes.
No single service is the answer in every market. The durable asset is the evaluation suite and the suppression boundary, because they let the media application change transport without rewriting campaign policy.
Top comments (0)