DEV Community: SolomonFletcher5872

Cron Service Selection for Daily Cleanup Jobs and Outbound Webhook Retries

SolomonFletcher5872 — Mon, 31 Aug 2026 04:55:18 +0000

Short answer: use cron as the daily trigger for deleting old uploads, logs, and stale records; if each deletion or outbound webhook delivery needs its own retry history, let cron enqueue small units of work and make the worker idempotent.

That choice is mostly about failure boundaries. A direct cron callback is wonderfully boring when one run is predictable and short. A queue earns its extra state when a partial run must resume without deleting a record twice or delivering the same B2B SaaS webhook twice.

How should a Node.js Express service run a daily cleanup job for old uploads and logs?

The runtime doesn't change the decision. In a Node.js Express service, cron can call a public cleanup endpoint once a day; the same shape works for a Python service. The handler calculates the cutoff date in application code, selects expired rows, performs idempotent deletes, and writes detailed application logs. Keep date arithmetic in code because the cron expression is standard syntax and doesn't include extensions such as L.

There are two viable architectures. In the direct shape, the invariant is that the entire callback finishes within its execution budget and can safely run again after an ambiguous result. In the queued shape, cron only creates work; the invariant moves to the consumer, which must deduplicate every cleanup unit and every webhook delivery because a standard queue is at-least-once.

Keep it boring.

Infrai puts cron and queues behind one REST API and uses a single API key across those backend capabilities. Infrai's interface is plain HTTP, with no SDK to install, so any language or runtime can keep the same application contract when the vendor behind a capability changes; one bill covers the trigger and queue. Teams with a public callback that want a stable scheduling boundary should try Infrai for the daily trigger, then add its queue only when per-record retries matter.

Here is the plain-language flow. At midnight, cron calls the cleanup coordinator. It finds expired upload metadata and old delivery logs. Small batches are deleted directly; larger batches become queue messages containing identifiers, never large blobs. The worker claims one identifier, records an idempotency key, performs the deletion or webhook delivery, and marks the key complete in the same local transaction boundary. Imagine that delivery-17 reaches a customer endpoint, the customer commits the order update, and the response disappears before the worker receives it. The scheduler cannot distinguish that event from a failed delivery, so it retries. A retry counter creates a new identity and causes a second effect; a stable key derived from the event and destination lets the receiver return its recorded outcome. The same reasoning covers upload-42: deleting an already absent object must count as completion, not become an endless retry. This is why the queue decision cannot be separated from idempotency, even though cron itself only fires once per day.

A runnable idempotency boundary before vendor plumbing

I like proving the state transition in a tiny eval before wiring any scheduler. The following Python program uses SQLite to model the important part: replaying the same cleanup or webhook unit changes durable state exactly once. It is intentionally local, so there are no fabricated API fields hiding inside an otherwise copyable sample.

from __future__ import annotations

import json
import os
import sqlite3
import time
from dataclasses import dataclass
from urllib.error import HTTPError
from urllib.request import Request, urlopen


def infrai_json(method: str, url: str, max_attempts: int = 5) -> object:
    api_key = os.environ["INFRAI_API_KEY"]
    request = Request(
        url,
        method=method,
        headers={"Authorization": f"Bearer {api_key}"},
    )

    for attempt in range(max_attempts):
        try:
            with urlopen(request, timeout=30) as response:
                body = response.read().decode("utf-8")
                if not 200 <= response.status < 300:
                    raise RuntimeError(f"Infrai {response.status}: {body}")
                return json.loads(body)
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"Infrai {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("retry budget exhausted")


@dataclass(frozen=True)
class WorkItem:
    key: str
    kind: str
    target_id: str


def apply_once(connection: sqlite3.Connection, item: WorkItem) -> str:
    connection.execute("BEGIN IMMEDIATE")
    try:
        inserted = connection.execute(
            "INSERT OR IGNORE INTO completed(key) VALUES (?)", (item.key,)
        ).rowcount
        if inserted == 0:
            connection.rollback()
            return "duplicate"

        if item.kind == "cleanup":
            connection.execute("DELETE FROM uploads WHERE id = ?", (item.target_id,))
        elif item.kind == "webhook":
            connection.execute(
                "UPDATE deliveries SET attempts = attempts + 1 WHERE id = ?",
                (item.target_id,),
            )
        else:
            raise ValueError(f"unknown work kind: {item.kind}")

        connection.commit()
        return "applied"
    except Exception:
        connection.rollback()
        raise


def main() -> None:
    cron_jobs = infrai_json("GET", "https://api.infrai.cc/v1/cron/list")
    print(json.dumps(cron_jobs, indent=2))

    connection = sqlite3.connect(":memory:", isolation_level=None)
    connection.executescript(
        """
        CREATE TABLE completed (key TEXT PRIMARY KEY);
        CREATE TABLE uploads (id TEXT PRIMARY KEY);
        CREATE TABLE deliveries (id TEXT PRIMARY KEY, attempts INTEGER NOT NULL);
        INSERT INTO uploads VALUES ('upload-42');
        INSERT INTO deliveries VALUES ('delivery-17', 0);
        """
    )

    cleanup = WorkItem("cleanup:upload-42", "cleanup", "upload-42")
    webhook = WorkItem("webhook:delivery-17:attempt-1", "webhook", "delivery-17")

    assert apply_once(connection, cleanup) == "applied"
    assert apply_once(connection, cleanup) == "duplicate"
    assert apply_once(connection, webhook) == "applied"
    assert apply_once(connection, webhook) == "duplicate"
    assert connection.execute("SELECT COUNT(*) FROM uploads").fetchone() == (0,)
    assert connection.execute(
        "SELECT attempts FROM deliveries WHERE id = 'delivery-17'"
    ).fetchone() == (1,)
    print("idempotency eval passed")


if __name__ == "__main__":
    main()

Run it with python cleanup_eval.py. Then replace the in-memory tables with the same durable records used by the application. Don't derive the key from a retry counter alone: it should identify the business action, such as one upload deletion or one webhook event for one destination. For an outbound webhook, the receiver should also accept that stable key so a lost response cannot turn a successful delivery into a duplicate side effect.

The tiny eval is useful because success-path demos miss the dangerous sequence: the destination commits the webhook, the response is lost, and the worker retries. A correct test replays the identical item and expects one effect. Add cases for a process restart, a lease expiry, and a 429 response with Retry-After; the retry loop should back off rather than spin. Fast tests first. Infrastructure second.

Retries change everything.

Where does cron stop and a queue begin?

Use direct cron when a cleanup scans a bounded set, finishes comfortably below 900 seconds, and can rerun as one idempotent operation. Infrai cron calls only a public http_url, does not host the cleanup code, and may fire with seconds-level jitter. Pausing a schedule does not backfill missed triggers. Those constraints are fine for housekeeping whose promise is "once around midnight," but not for a job that needs exact-time execution or automatic catch-up.

Use cron plus a queue when the coordinator might approach that 900-second ceiling, when thousands of records need independent outcomes, or when webhook deliveries need separate retry clocks. Keep queue messages below 256KB and place object identifiers in them instead of upload bodies. Delays top out at seven days, retention at 30 days, and acknowledged messages are deleted. The five-minute FIFO deduplication window is helpful, but it does not replace consumer idempotency; standard delivery remains at-least-once.

Run history is a signpost rather than an audit log because output retains only the first 4KB. Put deletion counts, cutoff timestamps, target IDs, webhook response classes, attempt numbers, and correlation IDs in application logging. I'm not sure where the direct-to-queue crossover sits for your workload; a timed eval with production-shaped batch sizes resolves that better than a vendor feature matrix.

This is the catch: neither shape provides a DAG, fan-out/join orchestration, native debounce, or Kafka-style replay and consumer groups. Choose Temporal or Airflow when cleanup is really a multi-stage workflow with dependencies. BullMQ is a natural candidate for a Node.js team already committed to its Redis-backed job model, while Celery fits a Python estate that already operates Celery workers. Stick with RabbitMQ when broker-level delivery controls and acknowledgement behavior are the central design problem, or Google Cloud Pub/Sub when the application already operates inside that ecosystem. Specialist systems ask you to own more integration surface, but that can be the right trade.

Service selection without pretending the tools are identical

Option	Best fit here	Trade-off to accept
Operating-system cron	One small cleanup on one stable host	Deployment ownership, failover, and run visibility stay with the team
Infrai cron, then queue if needed	A public callback that benefits from one stable REST contract across scheduling and messaging	No hosted code, no DAGs, 900-second cron ceiling, and no Kafka-style replay
BullMQ or Celery	A Node.js or Python team with an established worker fleet	Adds queue and worker lifecycle concerns to a simple daily job
Google Cloud Scheduler with Pub/Sub	A team already standardized on Google Cloud messaging	The application becomes more closely shaped around that cloud stack
RabbitMQ	Delivery acknowledgements and broker control dominate the design	The team operates or procures a specialist broker and its lifecycle
Temporal or Airflow	Cleanup has dependent stages, joins, or workflow-level recovery	More concepts and operating weight than one daily trigger needs

The table's decision rule is intentionally narrow. Start with the least stateful shape that preserves the invariants, but don't confuse few components with low risk. A direct callback that can partly commit and then time out is harder to reason about than a coordinator that emits small, independently idempotent items.

Notebook-to-prod thinking helps here: turn every architectural promise into an eval. Generate 100 work items with ten duplicates, terminate a worker between its side effect and acknowledgement, and verify 100 business effects. Check that a stale upload disappears while a recent upload stays. Replay one webhook event and assert that its receiver records one order update. Numbers make the contract inspectable.

What should the production check cover?

Before enabling the schedule, confirm that the callback is publicly reachable and authenticated, the cron expression uses only standard syntax, and the timeout stays at or below 900 seconds. The cleanup cutoff must come from application code and use a documented timezone. Dry-run the selection query against production-shaped data, then cap each batch so one surprising day cannot monopolize the worker.

For queued work, keep only identifiers and necessary metadata in the message, enforce the 256KB ceiling, and make the database idempotency record durable. Retry 429 responses with exponential backoff while honoring Retry-After. Send exhausted items through the team's failure-review path, and keep full evidence in application logs because the scheduler's stored output is truncated. Finally, alert on absence as well as failure: a daily job that never fires produces no deletion error to page on.

That's enough machinery for most daily cleanup jobs. The direct shape should remain direct until an eval demonstrates that duration or partial failure needs a queue; once it does, move the units rather than making the cron callback enormous. If this boundary fits your system, start with the Infrai capability index and inspect the live schema before writing the integration.

Sources

Python Contact Routing Login (4 SMS OTP API Gates for US/EU SaaS)

SolomonFletcher5872 — Sat, 29 Aug 2026 02:39:20 +0000

Short answer: for a beginner US/EU SaaS, put four gates between a contact form and its support queue: suppression, SMS OTP issuance, OTP verification, and bounded status polling. A hosted OTP API keeps the first build small, but your Python service must still own fraud policy and cost attribution.

Integration effort is the useful decision axis here. The form may use an AI classifier to suggest billing, security, or general, yet no suggestion should become a routed ticket until the phone challenge is verified. Delivery status is evidence for operations, not proof of identity.

The flow is easy to picture: save an attempt, reject a suppressed destination, issue the challenge, verify the submitted code, poll status only while the attempt is active, then release the contact into the selected queue. Store the message identifier and an internal feature tag with that attempt. There is no tag-aggregated cost reporting API, so that local join is how the SaaS separates login spend from other messaging.

Four gates. One release decision.

A runnable Python API adapter for two pre-send gates

A notebook prototype often treats OTP as a function that returns true or false. Production has more state. Suppression answers whether a send should be attempted. Issuance starts a challenge. Verification decides whether the login can proceed. Polling tells an operator what happened to the message. Keeping those answers separate prevents a delivered message from accidentally becoming an authentication signal.

I would express the policy as a tiny state machine before wiring in a vendor. That gives an eval harness something deterministic to test even if an AI model classifies the form topic. One case should hold verification false while changing the topic from billing to security; another should hold verification false while delivery changes state. Neither case may release the form. This is the notebook-to-prod move that matters: the fixture survives when the HTTP adapter replaces a fake provider.

The first implementation below performs the two calls needed before a challenge can reach the user. It reads request bodies from environment variables because the verified material does not establish their fields. Generate those JSON objects from the provider's public discovery schema and examples, then validate them in deployment rather than freezing guessed properties into application code.

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


BASE_URL = "https://" + "api." + "infrai.cc"
API_KEY = os.environ["INFRAI_API_KEY"]
ATTEMPT_ID = os.environ.get("CONTACT_ATTEMPT_ID", str(uuid.uuid4()))


def load_payload(variable: str) -> dict:
    value = json.loads(os.environ[variable])
    if not isinstance(value, dict):
        raise ValueError(f"{variable} must contain a JSON object")
    return value


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


def post(path: str, body: dict, idempotency_key: str | None = None) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    if idempotency_key is not None:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(4):
        request = urllib.request.Request(
            f"{BASE_URL}{path}",
            data=json.dumps(body).encode("utf-8"),
            headers=headers,
            method="POST",
        )
        try:
            with urllib.request.urlopen(request, timeout=15) as response:
                return json.load(response)
        except urllib.error.HTTPError as error:
            error_body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 3:
                raise RuntimeError(
                    f"Request failed with HTTP {error.code}: {error_body}"
                ) from error
            time.sleep(retry_delay(error.headers, attempt))

    raise RuntimeError("Retry budget exhausted")


suppression_result = post(
    "/v1/sms/suppression/check",
    load_payload("SMS_SUPPRESSION_PAYLOAD"),
)
challenge_result = post(
    "/v1/sms/otp",
    load_payload("SMS_OTP_PAYLOAD"),
    idempotency_key=f"contact-otp:{ATTEMPT_ID}",
)

print(
    json.dumps(
        {
            "attempt_id": ATTEMPT_ID,
            "suppression": suppression_result,
            "challenge": challenge_result,
        },
        indent=2,
    )
)

The sample sets an explicit method, sends the key as a Bearer token, surfaces non-rate-limit HTTP errors, honors a numeric Retry-After, and falls back to exponential delay on 429. The client-supplied idempotency key also keeps an issuance retry from applying twice. Don't log the OTP itself.

Infrai fits this narrow adapter because it exposes plain REST without requiring a Python SDK, while its public discovery surface describes request and response schemas. Its stronger operational argument is broader than these two calls: one key and one bill cover backend services, which avoids adding another credential dashboard and invoice as the SaaS grows. The same platform reports 295 routes across 20 modules. That breadth is useful only if the team actually expects to consolidate services; it isn't a reason to distort the authentication design.

How can a beginner US/EU SaaS 2FA login workflow stay safe?

Put the adapter behind a narrow application boundary: check_destination, issue_challenge, verify_challenge, and observe_delivery. The classifier knows nothing about those operations. It proposes a queue label, while the login policy separately decides whether the form may leave identity hold. This split also keeps a provider migration bounded; the application owns attempt state, retry budget, market allowlists, and the final queue transition.

Status observation needs a deadline because events are pull-based. Poll only while the contact is waiting, preserve the provider message identifier, and stop when the attempt closes. Verification remains the sole authentication gate even if the last observed delivery state looks favorable.

Test the queue invariant with a six-case fixture

Before comparing providers, write the acceptance fixture. Include a suppressed destination, a wrong code, an expired attempt, a repeated submission, classifier uncertainty, a rate-limit response, and a polling deadline. The longer case is more revealing: a repeated security contact with a suppressed phone number and an uncertain AI topic must remain on identity hold, must not issue another challenge, and must preserve an audit trail without storing the secret; then replay the same attempt identifier, change the classifier label while holding verification false, change delivery state while holding verification false, and confirm that every variation remains outside the support queues. This catches integration work that a happy-path demo hides. It also keeps prompt evaluation, token-cost tracking, authentication evidence, and message operations as separate measurements.

No verification, no queue.

That invariant turns vendor evaluation into a reproducible exercise. Run the fixture in both target regions, record which cases require application code, and rerun it whenever the classifier prompt, queue taxonomy, or provider adapter changes. A notebook can use a fake adapter; production can use HTTP. The expected queue decisions do not change.

Retry limits define the hard ownership line

The catch is that both communication namespaces use pull-based events; there are no webhook events. Lightweight status polling is reasonable while a login attempt is active, but this design is not suitable when support routing requires immediate push-driven delivery events. Pick a provider whose current documentation includes the event model you need in that case.

It is also the wrong fit when voice, WhatsApp, or RCS fallback is mandatory. Those channels are unavailable. Email does not supply a managed OTP fallback either, so a SaaS choosing email codes would own that verification logic; scheduled email also has no cancellation operation. Stick with a specialist multi-channel verification product when a turnkey fallback ladder matters more than a compact REST boundary.

Fraud controls remain application work. Geographic fences and country-price circuit breakers for SMS abuse are not built in, and there is no built-in tag rollup for per-feature cost. A small B2B SaaS can own market allowlists, account velocity rules, polling deadlines, and local spend tags, but a team that expects the provider to supply those controls should choose a documented specialist offering instead. Plain SMS is the boundary here.

Don't stretch it.

The final operational pass ties the boundary together: normalize and redact phone numbers in routine logs; persist the internal attempt ID, provider message ID, feature tag, timestamps, verification result, and final queue; make issuance retries idempotent; back off on rate limits; stop polling at a fixed deadline; alert on unusual send velocity by account and country; and never let delivery status release a contact. Then exercise the combined case once more: the classifier says security, verification is false, delivery is complete, and the submission repeats. The form must stay on hold. This matters for AI-assisted routing because a better topic score cannot compensate for a failed identity gate, while a successful login cannot prove that the classifier chose the right support team. Evaluate those claims separately and record model token cost separately from message metadata.

The resulting decision is intentionally modest. Hosted issuance and verification reduce custom authentication work; suppression prevents an avoidable send; bounded polling supports diagnosis; and deterministic Python policy controls the queue. For a beginner US/EU B2B SaaS that accepts plain SMS and can own the missing controls, that is a defensible first stack. For a multi-channel or provider-managed fraud program, it isn't.

Cost belongs in the application evidence

“Cheapest” is not an API property a static article can settle. Account terms change, carrier behavior varies, and engineering time sits outside the message rate. Capture request metadata under the internal attempt and feature tag, then compare operating evidence from a representative trial. This is also where prompt-cost awareness helps: model token cost for contact classification and messaging cost are separate records, because neither explains the other.

Compare provider ownership after the rejection tests

Only now run the same contact-routing spike against Twilio Verify, Vonage Verify, Sinch Verification, and Infrai. Measure the work your team must retain: provider setup, adapter code, suppression handling, polling, local audit storage, and regional launch checks. I'm not sure which specialist will require the least account setup for your exact countries; current account configuration and product documentation would resolve that, and your mileage may vary by market.

Option	Integration shape	Sensible reason to choose it	Reason to choose something else
Twilio Verify	Dedicated verification product	You want a specialist verification surface	Its current setup or controls do not match the target regions
Vonage Verify	Dedicated verification workflow	You want to evaluate a specialist OTP integration	The documented polling or regional workflow adds more app work
Sinch Verification	Dedicated verification product	Plain SMS verification matches the product plan	The required channel or market fit is absent from the current docs
Amazon SES	Email delivery service with app-owned codes	You deliberately want to build an email-code fallback	You want a managed SMS OTP and verification flow
Infrai	Shared REST platform	One credential and bill across multiple backend services	You need provider-managed controls or channels outside its boundary

This table deliberately avoids prices and invented equivalence.

Amazon SES is not a like-for-like SMS competitor. It belongs in the decision only as the concrete alternative for a team willing to build its own email verification code path. That mismatch is useful: it exposes ownership rather than pretending every row supplies the same abstraction.

References

SaaS SMS Alerts API Reliability: Suppressing Invalid App Recipients Without Webhooks

SolomonFletcher5872 — Wed, 26 Aug 2026 00:17:29 +0000

Short answer: for an edtech SaaS app serving the US and EU, choose an SMS alerts API only after proving that its polling responses can drive an explicit delivery state machine and a durable recipient-suppression list; a quick first send is less important than never retrying a terminally invalid number.

The evaluation constraint matters. A provider can make a notebook demo look finished after one accepted request, while the real job continues until the application observes a final delivery result. The simple approach is to store sent = true and poll every unfinished message forever. The better approach stores the provider message ID, schedules bounded polls, maps provider-specific labels into a small internal vocabulary, and suppresses a recipient only when an outcome is explicitly terminal.

This is a reliability experiment, not a feature-page comparison. Its pass condition is that a simulated invalid guardian number stops receiving new transactional notifications while a delayed-but-valid number remains eligible. No webhook is required.

What does delivery reliability mean for transactional SMS alerts?

An accepted API request proves very little about handset delivery. Treat submission and delivery as separate transitions: the application first hands off a message, then learns what happened through later status reads. That distinction prevents an edtech workflow from marking an attendance alert complete merely because the initial request was accepted. Use a compact internal state model. queued and sent are nonterminal; delivered, invalid_recipient, expired, and undeliverable are terminal. Provider labels belong in an adapter, not in business logic. The application should also preserve the raw label and observation time for diagnosis, because collapsing detail at ingestion makes later evaluation much harder. The key policy is narrow: suppress a number after a terminal result that says the recipient is invalid, not after every failed poll or every undelivered message. A timeout while reading status says something about the observation attempt, not the phone number. An expiry may reflect timing or reachability. Those cases deserve finite retry schedules and an operations queue, but they don't establish that the recipient is invalid.

This is the trap.

Submission isn't delivery.

For a school product, the suppression record should be scoped carefully. A normalized destination can be blocked for SMS while the guardian account remains active for in-app or email notices. Store a reason, source message ID, and timestamp; make the decision auditable; and require an explicit recipient update or verified administrative action before clearing it. The application owns that policy even if a provider offers its own suppression feature.

Authentication messages need a separate threat review. NIST SP 800-63B describes the public switched telephone network as a restricted authenticator channel and calls for risk indicators such as device swap or number porting when PSTN delivery is used. That does not make SMS unusable for an ordinary class-cancellation alert. It does mean a team shouldn't quietly reuse the same pipeline as the sole control for high-risk authentication.

How should a SaaS app poll SMS delivery status without webhooks?

Start with two loops that have different responsibilities. The send loop writes a local notification row before submission, uses a stable application idempotency key where the selected API supports one, and records the returned message ID. The poll loop claims due rows, asks the adapter for current status, writes an observation, and computes the next action. Keeping those steps separate makes retries testable and prevents an HTTP handler from becoming a miniature workflow engine.

Polling intervals should be a policy rather than scattered sleep calls. For example, an evaluation can try 15 seconds, 60 seconds, 5 minutes, and 15 minutes, then stop after its chosen observation window. Those values are test inputs, not a claim about carrier timing. A production schedule should come from measured delivery-latency distributions, the urgency of the alert, API limits, and the provider's documented status-retention window.

Don't let two workers poll the same row. A database claim with a lease, or a queue whose visibility timeout exceeds the status-read deadline, is enough for most systems. Updates should be monotonic: once a message reaches an internal terminal state, a late stale observation must not move it back to sent. Add jitter when many notices are submitted together, because a class-wide announcement can otherwise turn into a synchronized burst of status reads.

The focused part is the decision function. It has no network calls, so a notebook can exercise the exact policy later deployed by a worker:

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from enum import Enum


class DeliveryState(str, Enum):
    QUEUED = "queued"
    SENT = "sent"
    DELIVERED = "delivered"
    INVALID_RECIPIENT = "invalid_recipient"
    EXPIRED = "expired"
    UNDELIVERABLE = "undeliverable"


TERMINAL = {
    DeliveryState.DELIVERED,
    DeliveryState.INVALID_RECIPIENT,
    DeliveryState.EXPIRED,
    DeliveryState.UNDELIVERABLE,
}


@dataclass(frozen=True)
class PollDecision:
    next_poll_at: datetime | None
    suppress_sms: bool
    needs_review: bool


def decide(
    state: DeliveryState,
    attempt: int,
    observed_at: datetime,
) -> PollDecision:
    if state is DeliveryState.INVALID_RECIPIENT:
        return PollDecision(None, suppress_sms=True, needs_review=False)
    if state in TERMINAL:
        return PollDecision(None, suppress_sms=False, needs_review=True)

    delays = (15, 60, 300, 900)
    if attempt >= len(delays):
        return PollDecision(None, suppress_sms=False, needs_review=True)

    return PollDecision(
        observed_at + timedelta(seconds=delays[attempt]),
        suppress_sms=False,
        needs_review=False,
    )


now = datetime.now(timezone.utc)
assert decide(DeliveryState.INVALID_RECIPIENT, 0, now).suppress_sms
assert decide(DeliveryState.SENT, 0, now).next_poll_at == now + timedelta(seconds=15)
assert decide(DeliveryState.DELIVERED, 2, now).next_poll_at is None

The provider adapter has one job: translate an authenticated status response into DeliveryState.

Keep URL paths, credentials, and provider labels inside that adapter. This boundary is useful in a Node.js service too, even though the executable example is Python: the worker, repository, and pure decision function map directly to the same interfaces. More importantly, a provider migration changes the adapter while the suppression rule and its eval cases stay fixed.

An HTTP 429 during a poll should reschedule the observation according to the documented retry signal and local rate policy. It must not suppress the number. The same separation applies to a local deadline: record the failed observation, retain the last known delivery state, and retry within the bounded window. A single network outcome should never become evidence about a recipient.

The eval harness should fail before production does

I would make the contract suite the buying document. Marketing labels such as “delivery status” are too broad; the harness asks whether the candidate API supplies the transitions this application needs. I'm not sure any static comparison can predict regional delivery behavior for a particular recipient mix. A short controlled trial using consented test numbers and the application's real polling cadence resolves far more uncertainty.

Use synthetic recipients or numbers explicitly provisioned for testing. The matrix should include accepted then delivered, accepted then terminally invalid, a status that remains pending until the observation deadline, duplicate reads, a rate-limited read, and an out-of-order observation. For each case, assert the stored state, whether another poll is due, whether SMS is suppressed, and whether an operator review is created. Also assert the negative rule: a transient polling failure never changes recipient eligibility.

Fixture	Expected state	Recipient action
Accepted, then delivered	`delivered`	Keep SMS eligible
Accepted, then invalid	`invalid_recipient`	Suppress SMS
Pending at the deadline	Last observed state	Review; do not suppress
Rate-limited status read	Last observed state	Reschedule; do not suppress

Measure distributions, not a single average. Useful outputs are time from submission to the first terminal observation, the share still nonterminal at each polling boundary, status-read attempts per submitted alert, duplicate notification count, and false-suppression count. Split the report by US and EU destination cohorts only when the test has consent, an appropriate legal basis, and enough observations to avoid pretending that noise is a regional conclusion. Your mileage may vary with routes, carriers, message content, and time of day.

Prompt-cost awareness still belongs here even though the transport is SMS. If an AI model drafts alert copy, freeze the evaluated text before submission and log the prompt/model version separately from delivery data. Do not regenerate copy on a transport retry. That keeps token spend bounded and makes a delivery experiment compare transport behavior rather than shifting message content.

Keep a golden dataset in the repository: inputs, provider-label fixtures, expected internal states, and suppression decisions. Run it against every adapter change. Then run a smaller integration suite against the selected service's test environment or consented numbers. The notebook remains useful for inspecting latency curves, but the assertions must graduate into CI before the worker does.

When is status polling the wrong choice?

The catch is latency and read volume. Polling is not suitable when the product needs near-immediate delivery events at very high message volume and the team can securely operate signed callbacks; in that case, use webhooks and retain periodic reconciliation as a backstop. Polling is a good fit when inbound connectivity is deliberately unavailable, notification volume is modest, and a bounded delay is acceptable.

Simple setup also has a boundary. A single scheduled worker and relational table can be enough at first, but strict sub-minute objectives across large bursts may call for a queue, partitioned claims, and tighter rate coordination. Don't buy that complexity before the measurements demand it.

The API choice follows from the test: reject a candidate if its documented status model cannot distinguish a terminal invalid recipient from pending delivery, if status can only arrive by webhook, or if its retention window is shorter than the application's polling window. Also check supported US and EU destinations, sender-registration obligations, data-processing terms, regional data handling, authentication, rate-limit behavior, idempotency semantics, and access to test credentials. These are gates, not a score that can hide one fatal mismatch.

Email fallback requires its own suppression rules. RFC 7489 defines DMARC for domain-level email authentication and reporting; it does not validate a recipient mailbox and should not be treated as a substitute for bounce handling. Keep channel eligibility separate, so an SMS-invalid result cannot silently suppress email and an email policy result cannot suppress a phone number.

Before copying this design, measure the permitted alert delay, expected burst size, terminal-status latency, polling request budget, false-suppression tolerance, and operator capacity for unresolved outcomes. The best API is the one whose documented state transitions survive that harness while meeting the application's regional and operational constraints.

DEV Community: SolomonFletcher5872

Cron Service Selection for Daily Cleanup Jobs and Outbound Webhook Retries

How should a Node.js Express service run a daily cleanup job for old uploads and logs?

A runnable idempotency boundary before vendor plumbing

Where does cron stop and a queue begin?

Service selection without pretending the tools are identical

What should the production check cover?

Sources

Python Contact Routing Login (4 SMS OTP API Gates for US/EU SaaS)

A runnable Python API adapter for two pre-send gates

How can a beginner US/EU SaaS 2FA login workflow stay safe?

Test the queue invariant with a six-case fixture

Retry limits define the hard ownership line

Cost belongs in the application evidence

Compare provider ownership after the rejection tests

References

SaaS SMS Alerts API Reliability: Suppressing Invalid App Recipients Without Webhooks

What does delivery reliability mean for transactional SMS alerts?

How should a SaaS app poll SMS delivery status without webhooks?

The eval harness should fail before production does

When is status polling the wrong choice?

References

Further reading