DEV Community: LeopoldHolm3736

Email Deliverability: Custom-Domain Warmup, Suppression, Bounce and Complaint Tracking

LeopoldHolm3736 — Tue, 01 Sep 2026 04:19:13 +0000

Short answer: choose the least complicated email service that lets a small SaaS authenticate its custom domain, export suppression state, distinguish bounces from complaints, and poll durable event records into its own audit store. Treat warmup as controlled traffic ramping, not as evidence that a compliance notice reached a person.

For a developer-tools business sending a policy-change notice, the hard question isn't whether an API returned an ID. It is whether the business can later reconstruct what it attempted, what the mail system reported, and why it stopped sending to an address. Keep that evidence in your database. A provider dashboard is an operations screen, not your system of record.

This changes the buying criterion. I care about revenue per engineering hour, so the simplest option is the one that removes undifferentiated mail operations without owning the compliance record. It should help the team ship weekly, while leaving a small and boring evidence pipeline under its control.

Can custom-domain email warmup and suppression records satisfy compliance governance?

Start with the evidence contract, then compare services. A custom domain and SPF support are table stakes for domain authorization: SPF defines a way for a receiving system to check whether a host is authorized to use a domain in the envelope identity. It does not prove that a person saw a message, and it should not be modeled as delivery evidence. That distinction matters during an audit. The concrete constraint is an auditable delivery record for a compliance notice, not maximum campaign throughput. A useful record needs lineage: notice revision, recipient, send attempt, external message ID, observed state changes, and suppression decision. Those fields have to survive a provider migration, so a dashboard-only workflow is out. Treat a successful submission as accepted, because that is exactly what the application knows. Later observations can add bounced or complained; neither should overwrite the history that came before it.

The service should expose enough state to answer four separate questions:

What exact notice version did the application ask to send, to which normalized recipient, and when?
What provider message identifier came back with the accepted submission?
Which later event changed the message state, and what raw category accompanied it?
Was the recipient suppressed before a later attempt, and which event or policy caused that decision?

Look for stable identifiers, timestamps, event categories, pagination, and a documented retention boundary. If any of those are unclear, I'm not sure a polling endpoint alone can satisfy the evidence requirement; a sample export and the provider's retention documentation would resolve that uncertainty. Your mileage may vary when counsel defines what must be retained, so turn that definition into an acceptance test before signing a contract.

Warmup belongs in the operational plan, but don't let it dominate selection. It is a controlled change in sending volume and recipient mix. The audit design should work on day one and after volume grows: every attempt gets a local record, every observed event is appended, and suppression is checked before another attempt. Keep the provider's raw event category beside your normalized state. Normalization makes application queries stable, while the raw value preserves context for later review. This is cheap insurance in engineering time — but it isn't magic proof of human receipt.

The catch is that a polling-only service is not suitable when the notice must appear in your system within seconds. Choose an option with signed event delivery when low latency is a real requirement. Stick with polling when delayed reconciliation is acceptable and one scheduled worker is easier to operate than a public callback endpoint. That is a workload choice, not a universal ranking.

SPF configuration needs the same precision. The RFC describes authorization checks using the domain in the SMTP MAIL FROM or HELO identity. Record the domain and configuration revision used for a launch, then validate the published policy as part of deployment. Don't write "SPF passed" into the audit trail unless the observed event actually supplies that result. The application cannot infer a receiver's evaluation from its own DNS lookup.

This is the part I would refuse to outsource: the meaning of the record. Sending, queueing, and bounce classification are undifferentiated work. The mapping from those signals to a compliance decision belongs close to the product.

Implement one adapter, one cursor, and two append-only records

The first version needs one send adapter, one event poller, and two append-oriented tables. The adapter prevents provider-shaped response objects from spreading through product code. The poller advances a cursor only after the page has been stored.

 type NoticeAttempt = {
  attemptId: string;
  noticeRevision: string;
  recipient: string;
  requestedAt: string;
  providerMessageId?: string;
  state: "requested" | "accepted";
};

 type DeliveryObservation = {
  providerMessageId: string;
  observedAt: string;
  kind: "accepted" | "bounced" | "complained" | "suppressed";
  rawKind: string;
};

 type EventPage = {
  observations: DeliveryObservation[];
  nextCursor?: string;
};

 interface MailEvidencePort {
  submit(input: {
    recipient: string;
    noticeRevision: string;
    idempotencyKey: string;
  }): Promise<{ providerMessageId: string }>;

  listEvents(cursor?: string): Promise<EventPage>;
}

The leading spaces before type are optional in a real file; the important boundary is the vocabulary. Product code knows accepted, bounced, complained, and suppressed. It does not know a vendor's route layout.

A small scheduled worker can reconcile pages without claiming more than it observes:

 async function reconcile(
  port: MailEvidencePort,
  cursor: string | undefined,
  appendOnce: (event: DeliveryObservation) => Promise<void>,
  saveCursor: (cursor: string | undefined) => Promise<void>,
): Promise<void> {
  const page = await port.listEvents(cursor);

  for (const observation of page.observations) {
    await appendOnce(observation);
  }

  await saveCursor(page.nextCursor);
}

appendOnce should use a deterministic uniqueness rule derived from the provider message ID, event kind, and observed timestamp. The exact rule depends on the event contract; verify it against replayed pages before deployment. Do not invent an event ID when the service already supplies one.

The failure case worth testing is mundane: the worker stores half a page and exits before saving the cursor. On its next run, it reads that page again. Duplicate observations must leave the audit history unchanged, and the cursor must remain behind until every observation is durable. Also test an empty page, an unchanged cursor, an address already on the suppression list, and two events for one message arriving out of order. These are deterministic tests. No production anecdote is needed to justify them.

Before sending, query the local suppression projection. If suppressed, record a blocked attempt with the governing reason rather than calling the send adapter. After polling, update that projection from appended bounce or complaint observations according to the written policy. The evidence log stays immutable; the projection can be rebuilt.

Evaluate the evidence claim before widening the cohort

Ship the pipeline behind a narrow release check. Validate the custom-domain identity, confirm the SPF policy is the intended revision, send only to the approved compliance cohort, and watch event reconciliation before widening the cohort. The SPF RFC is the authority for SPF semantics; a provider setup screen is only an interface to configuration.

Use a test matrix with accepted submission, suppression before submission, bounce observation, complaint observation, replayed page, and cursor recovery. Keep real recipient addresses out of fixtures. A synthetic identifier such as member-042@example.invalid makes the intent obvious without smuggling customer data into the repository.

Short version: deploy slowly.

Do not mix SMS one-time-code behavior into the email evidence model. The WebOTP API is specifically an API for obtaining one-time passwords from specially formatted SMS messages. That is a different channel and job. If SMS becomes a required fallback for the notice, give it its own delivery adapter, evidence vocabulary, and channel-specific review rather than pretending an email bounce category transfers cleanly.

Observability can stay lean. Alert on a poller that fails to advance within the expected schedule, a sustained rise in unclassified raw event kinds, and a mismatch between accepted attempts and reconciled message IDs. Set the actual thresholds from normal traffic after launch; fabricated universal percentages would create false confidence.

Migration at scale should preserve the product vocabulary

At higher volume, I would replace the single worker with partitioned reconciliation, retain the same port, and make cursor ownership explicit per partition. I would also separate immutable evidence storage from the query projection so support searches do not compete with ingestion. Those are scaling changes, not reasons to burden the first release.

There are real trade-offs. Polling spends requests on quiet periods and adds detection delay. Event delivery reduces that delay but creates an authenticated public ingestion surface, replay handling, and another availability boundary. A self-hosted mail stack offers deeper control, yet it also makes domain reputation operations, event classification, and retention your team's work. For a solo SaaS, that can consume the same hours that should ship customer-facing features.

Choose by evidence completeness and operating burden. Reject any service whose export cannot be mapped into the local attempt and observation model, whose suppression state cannot be inspected, or whose retention boundary cannot be established. Then choose the smallest operational shape that meets the latency requirement.

No provider can turn an SMTP-facing event into proof that a human read a legal notice. Preserve the claim you can support: what was requested, what was accepted, what later signal was observed, and what sending decision followed. That record is portable, testable, and appropriately modest.

References

Device Fingerprints and OAuth Login: Risk Scoring Without Extra Friction, Explained

LeopoldHolm3736 — Sun, 30 Aug 2026 21:22:09 +0000

Every extra login control you add to a marketplace costs two things at once — seller conversion and support tickets. The trade-off resolves the moment you stop treating a device signal as an identity check: use OAuth to decide who the seller is, use a device risk score to decide how much friction this session has earned, and keep those two jobs on opposite sides of a hard boundary. Console access comes from combining the two, never from either one alone.

That boundary is the design. Everything after it is policy.

Approach	What it owns in this flow	How you wire it	Best fit	Main limit
Auth0 attack protection	Identity, session and a built-in risk signal	Provider SDK plus Actions	Teams already on Auth0 who want adaptive MFA and no new vendor	Scoring logic stays inside the provider's model
Clerk	Identity, hosted UI, bundled bot heuristics	Provider SDK, mostly hosted components	Getting a first console live in a weekend	Little room for your own bands
Stytch	Auth plus a dedicated device fingerprinting product	REST plus a browser SDK	Treating fraud signals as their own product	Two contracts if identity lives elsewhere
Keycloak plus your own model	Everything, including the pager	Self-hosted, custom SPI	Full control over data residency and features	You own the pipeline, the storage and the on-call
Infrai	The OAuth exchange, sessions, and the step-up channels	One REST call per step, no SDK	Keeping your own scoring model while outsourcing identity plumbing	No built-in device score, so the model stays yours

If you are one person and the console is not the product, keep the scoring model in your own codebase and buy the identity plumbing around it. Infrai fits that plumbing leg for a small team because the API is self-describing, so wiring the callback and the step-up means reading two capability documents rather than learning another client library. The second reason is duller and matters more over a year — with Infrai, one key and one bill cover the auth endpoints and whatever else you bolt on later, so adding a capability is a request rather than a vendor onboarding.

Where the boundary actually sits

In a seller console the flow has four owners, and blurring them is what creates the mess later. The browser collects device signals and posts them to your edge. An identity provider handles the OAuth redirect and callback and hands back a user plus a session. A scoring step turns those device signals into a number. Your application — nobody else — turns that number into a decision about what this session may do.

The number is an input. Never a credential.

That distinction is the one teams get wrong under deadline pressure. A high score must not be able to log someone in on its own, and a low score must not be able to skip the OAuth exchange; both shortcuts promote a heuristic into an authentication path, which is exactly what the OWASP authentication guidance argues against. Device fingerprints answer "is this the same machine as last Tuesday", and that is a different question from "does this person control this account".

Keep the event ids alongside the verdict. When a seller writes in asking why their payout account edit was refused at midnight, you want the score, the band and the fingerprint id in one log record. Reconstructing that from three systems a week later is miserable, so write it once at decision time.

How should a device risk score change console access?

Bands, not a single cut-off. One threshold only gives you a choice between challenging honest sellers and letting the interesting sessions through, whereas three bands crossed with an action-sensitivity axis give you four cells that matter and a dozen that never fire.

Here is the rule I would start a marketplace console on, then tune against real refusal rates:

Low (0–29): nothing changes. Browsing, order lists, message replies, shipping labels — all proceed silently.
Medium (30–69): sensitive actions get a step-up. Payout account edits, bulk price changes, API key rotation, adding a team member. Everything else stays quiet.
High (70+): the sensitive action is refused rather than challenged, and the seller gets a re-auth link by email. Scores that high usually mean a new device, a new country and a new ASN inside the same minute.

Give the scoring step a hard 200 ms budget in your own code, and if no answer arrives, treat it as the medium band for sensitive actions and the low band for everything else. A login page that waits on a scoring service is worse than one that guesses conservatively.

Friction should land only where the money moves.

The same shape works outside marketplaces. An IoT fleet console has the identical split — OAuth for the operator's identity, a device-derived score for how much that operator may do to the fleet — and the scenario changes the thresholds, not the boundary.

What the login path looks like in code

The scoring half stays local, because the features are yours and the labels come from your own refunds and chargebacks. Three cheap ones are enough to open with:

type DeviceSignals = {
  fingerprint: string;
  country: string;
  asn: string;
  userAgent: string;
};

type DeviceHistory = {
  fingerprints: Set<string>;
  countries: Set<string>;
  asns: Set<string>;
  daysSinceLastLogin: number;
};

export function riskBand(signals: DeviceSignals, seen: DeviceHistory): "low" | "medium" | "high" {
  let score = 0;
  if (!seen.fingerprints.has(signals.fingerprint)) score += 40;
  if (!seen.countries.has(signals.country)) score += 25;
  if (!seen.asns.has(signals.asn)) score += 20;
  if (seen.daysSinceLastLogin > 90) score += 15;
  return score >= 70 ? "high" : score >= 30 ? "medium" : "low";
}

The other half is the identity exchange and, when the band says so, the step-up. That is the part worth outsourcing, and it is two HTTP calls:

const KEY = process.env.INFRAI_API_KEY as string;

function headers(idempotencyKey: string): Record<string, string> {
  return {
    Authorization: `Bearer ${KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": idempotencyKey,
  };
}

async function send<T>(label: string, request: () => Promise<Response>): Promise<T> {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await request();
    if (res.status === 429 && attempt < 3) {
      const retryAfter = Number(res.headers.get("retry-after")) || 0;
      const waitMs = retryAfter > 0 ? retryAfter * 1000 : 400 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, waitMs));
      continue;
    }
    const payload = await res.json();
    if (!res.ok) throw new Error(`${label} ${res.status} ${JSON.stringify(payload)}`);
    return payload as T;
  }
  throw new Error(`${label} exhausted 4 attempts`);
}

export async function finishConsoleLogin(
  code: string,
  state: string,
  band: "low" | "medium" | "high",
) {
  const identity = await send<{ user_id: string; email: string }>("oauth callback", () =>
    fetch("https://api.infrai.cc/v1/auth/oauth/callback", {
      method: "POST",
      headers: headers(`oauth:${state}`),
      body: JSON.stringify({ provider: "google", code, state }),
    }));

  if (band === "low") {
    return { userId: identity.user_id, stepUp: null };
  }

  await send<{ request_id: string }>("step-up", () =>
    fetch("https://api.infrai.cc/v1/auth/email/send_code", {
      method: "POST",
      headers: headers(`stepup:${state}`),
      body: JSON.stringify({ email: identity.email }),
    }));

  return { userId: identity.user_id, stepUp: "email_code" };
}

Three details in there are load-bearing and easy to skip. The idempotency key is derived from the OAuth state, so a retry after a network blip finishes one login rather than mailing two codes — the platform convention is an Idempotency-Key header with a 24-hour dedup window, and once the header is set you get that behaviour without writing your own dedup table. The 429 branch honours Retry-After instead of tight-looping, which you will care about the first time a credential-stuffing run finds your login page. And the body is parsed before the status is checked, because a 4xx body carries the reason and throwing it away leaves you debugging blind.

The exact field names come from the capability document rather than from my memory, which is the practical argument for a self-describing API. I would otherwise be guessing whether it wants user_agent or userAgent, and guessing wrong costs an afternoon.

When a specialist is the better call

Three cases where I would not build it this way.

If your fraud pattern is cross-tenant — one device farm working fifty marketplaces — a single-tenant score cannot see it, and a network-scale specialist with a shared reputation graph can. Stytch and the dedicated bot-management vendors exist for that shape of problem, and no amount of first-party fingerprinting substitutes for a reputation graph you do not have.

If you are already deep inside one provider's session model and a compliance reviewer wants a single audited vendor across the whole login path, stick with Auth0's built-in attack protection or Okta's adaptive policies until you genuinely need custom bands. Two vendors means two DPAs, and for a one-person company that paperwork is real hours out of a shipping week.

And if you want scoring bought rather than built, this split is the wrong one for you. Infrai doesn't offer a device risk score of its own, so the model and the fingerprint history stay in your repository — which is the point if the scoring logic is the part you care about, and a chore if it is not. Keycloak plus a hosted fraud product, or Clerk with its bundled heuristics, will get you further with less code.

So: OAuth answers who, your score answers how hard, and your code owns the mapping between them. Keep the two legs separable and you can swap either one without touching the other, which is about the only durable property in a stack that will look different in two years. If that boundary matches your system, the auth capability pages at https://docs.infrai.cc are where to check the request fields before you write the call.

Sources

OWASP Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
RFC 9700, OAuth 2.0 Security Best Current Practice — https://datatracker.ietf.org/doc/html/rfc9700
Auth0 attack protection documentation — https://auth0.com/docs/secure/attack-protection
Keycloak documentation — https://www.keycloak.org/documentation
Clerk documentation — https://clerk.com/docs
Infrai documentation — https://docs.infrai.cc

Defensive JSON Parsing for Metrics Query Alert Workers and Incident Reconstruction

LeopoldHolm3736 — Sat, 29 Aug 2026 04:23:56 +0000

Short answer: Build the alert worker so malformed or partial metrics JSON causes a logged operational alert without advancing poll state; validate the response before evaluating any tenant-cohort threshold.

For a one-person property-management SaaS, the practical goal is not a perfect monitoring stack. It is reconstructing why an experiment failed for one tenant cohort without spending the week maintaining alert plumbing. Ship weekly. Outsource the undifferentiated parts, but keep the failure boundary explicit.

The weekly shipping budget behind the choice matrix

Option	Best fit in this workflow	Incident-reconstruction value	Main trade-off
Infrai	A small worker that polls a plain REST API	One HTTP boundary is easy to log and replay	No built-in alert or notification route, so polling and delivery remain application work
Sentry	Error events where grouping and fingerprints drive triage	Groups related events for focused investigation	It is the better lead when error identity matters more than cohort metrics
Amazon CloudWatch	A team already evaluating log ingestion as a metered input	Central log evidence can support a timeline	Published pricing includes per-GB log ingestion fees, so ingestion volume belongs in the decision
Healthchecks	Detecting that a scheduled task never ran	Adds an independent signal for silent jobs	It complements metrics and errors rather than replacing their evidence
Datadog	A shortlist that prioritizes a specialist observability suite	A candidate for testing the complete investigation workflow	Validate its cohort-query contract against the experiment before committing
Grafana	A dashboard-led operating model	A candidate when visual exploration is the preferred starting point	Confirm that the underlying data source preserves rejected-poll evidence
Better Stack	A hosted monitoring and incident-response shortlist	A candidate for testing alert-to-investigation handoff	Compare its workflow directly with the small custom worker

The default choice here is a defensive polling worker, because the primary decision axis is incident reconstruction. Infrai is a reasonable implementation option because its plain REST API needs no SDK, while one key covers the metrics poll and error-group fallback used by this worker. Its public self-describing discovery surface supplies request and response JSON Schema, so validation can follow the published contract without adding another client package. The catch is real. It does not provide threshold rules, phone, SMS, or webhook alert delivery, so this fit assumes the SaaS already has somewhere to send an operational notification.

This isn't a generic vendor ranking. A property manager asking why the treatment cohort stopped completing rent reminders needs the last trustworthy poll time, the rejected payload, and the cohort context. A prettier dashboard does not repair missing evidence.

How can a Node.js alert worker parse malformed monitoring API response JSON?

Treat the monitoring API response as unknown. JSON syntax is only the first gate; arrays, null, and partial objects are valid JSON too, and none should reach threshold code until they satisfy the worker's schema. Because the filtering parameters for metrics.query are not declared, start without invented query-string filters. Add a narrow filter only after its contract is available, and capture the raw rejected response during setup.

The following TypeScript worker uses the verified GET /v1/metrics/query path. It handles 429 with exponential backoff and Retry-After, checks every HTTP status, parses once, accepts only a non-array object at the transport boundary, and updates the last-success timestamp only after that check. The object guard is deliberately minimal: replace it with the exact response schema used by your threshold evaluator before declaring a cohort healthy.

import { readFile, writeFile } from "node:fs/promises";

type Cursor = { lastSuccessfulAt: string | null };
type JsonObject = Record<string, unknown>;

const cursorFile = ".metrics-alert-cursor.json";
const apiOrigin = requireEnv("MONITORING_API_ORIGIN");
const apiKey = requireEnv("INFRAI_API_KEY");
const metricsUrl = new URL("/v1/metrics/query", apiOrigin);

function requireEnv(name: string): string {
  const value = process.env[name];
  if (!value) throw new Error(`Missing environment variable: ${name}`);
  return value;
}

function retryDelay(response: Response, attempt: number): number {
  const header = response.headers.get("retry-after");
  if (header) {
    const seconds = Number(header);
    if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

    const dateDelay = Date.parse(header) - Date.now();
    if (Number.isFinite(dateDelay)) return Math.max(0, dateDelay);
  }
  return 500 * 2 ** attempt;
}

async function fetchMetrics(attempt = 0): Promise<string> {
  const response = await fetch(metricsUrl, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    await new Promise((resolve) =>
      setTimeout(resolve, retryDelay(response, attempt)),
    );
    return fetchMetrics(attempt + 1);
  }

  const raw = await response.text();
  if (!response.ok) {
    throw new Error(`Metrics query HTTP ${response.status}: ${raw}`);
  }
  return raw;
}

function parseObject(raw: string): JsonObject {
  let value: unknown;
  try {
    value = JSON.parse(raw) as unknown;
  } catch {
    throw new Error(`Metrics response was not JSON: ${raw.slice(0, 2_000)}`);
  }

  if (value === null || typeof value !== "object" || Array.isArray(value)) {
    throw new Error(`Metrics response failed schema: ${raw.slice(0, 2_000)}`);
  }
  return value as JsonObject;
}

async function readCursor(): Promise<Cursor> {
  try {
    return JSON.parse(await readFile(cursorFile, "utf8")) as Cursor;
  } catch {
    return { lastSuccessfulAt: null };
  }
}

async function main(): Promise<void> {
  const previous = await readCursor();
  const raw = await fetchMetrics();
  const metrics = parseObject(raw);

  console.log(JSON.stringify({
    event: "metrics_poll_validated",
    previousSuccessfulAt: previous.lastSuccessfulAt,
    topLevelKeys: Object.keys(metrics),
  }));

  await writeFile(
    cursorFile,
    JSON.stringify({ lastSuccessfulAt: new Date().toISOString() } satisfies Cursor),
    "utf8",
  );
}

main().catch((error: unknown) => {
  console.error(JSON.stringify({
    event: "metrics_poll_failed_closed",
    error: error instanceof Error ? error.message : String(error),
  }));
  process.exitCode = 1;
});

No cursor move. No false green.

The next layer should validate the exact fields the threshold uses, then evaluate the experiment cohort. Do not infer a zero from a missing series, coerce an absent number, or catch the parsing exception and continue as healthy. I'm not sure which filter contract a given deployment will expose later; the missing declaration is precisely why the initial worker should make fewer assumptions and preserve the rejected setup payload.

A three-poll experiment reconstruction

Imagine the treatment cohort is evaluated every minute. The 10:41 poll is valid, the next response fails validation, and the 10:43 poll is valid again. If the worker advances its cursor at 10:42 anyway, an investigator can no longer distinguish “no failures” from “the worker could not evaluate failures.” Keeping lastSuccessfulAt at 10:41 preserves that distinction. The failed-closed log then supplies the other half of the timeline — what the worker rejected and when — while the subsequent valid poll shows when observation resumed. Those three facts are more useful for a small team than an alert that merely says “threshold breached,” because they let the operator decide whether the tenant-cohort experiment failed or its measurement became uncertain.

Keep the raw rejected body only as long as setup requires, with the same access controls as other operational data. Once the response contract is stable, structured validation errors are easier to search and less likely to copy tenant data into logs. Revenue per hour matters here: a precise boundary pays back during the first confusing incident, while a custom observability framework probably won't.

If metrics parsing repeatedly fails, poll the simpler GET /v1/errors/groups surface for critical failure detection. That fallback is intentionally narrower. It preserves a signal that failures exist; it does not pretend to answer the cohort comparison that the metrics response could not support.

Comparing the specialist shortlist

Stick with Sentry when event grouping and fingerprint control are the center of incident response. Its documented grouping mechanics directly address the question “which events belong to the same issue?” That can beat a custom metrics worker for exception-heavy services, even though it answers a different question from cohort-level experiment comparison.

CloudWatch deserves the lead when the operational decision is already organized around its log pipeline and the team is prepared to model ingestion volume. Cost is one dimension, not the recommendation: its public pricing describes per-GB log ingestion fees, so a high-volume property event stream needs an explicit retention and ingestion budget before adoption.

Use Healthchecks alongside either approach when the feared failure is silence — the rent-reminder job should have run, but did not. A metrics poll cannot prove an absent scheduler executed. That independent heartbeat closes a gap in this design.

Datadog, Grafana, and Better Stack belong in the evaluation rather than as decorative logo rows. Give each the same three-poll cohort scenario, deliberately feed the worker a partial fixture, and inspect the evidence left for the operator. The winner is the option that preserves uncertainty and makes the 10:42 gap reconstructable with the least weekly maintenance. Your mileage may vary because an existing dashboard or incident process changes that maintenance calculation.

Retention and privacy governance boundaries

There are further limits to the REST polling choice. It has no distributed trace query or span tree, although logs can carry trace_id and span_id; it has no source-map decoding, crash symbolication, Electron minidump parsing, or Session Replay. Logs have no per-user deletion, bulk export, or subscription API, and retention or cold-storage configuration is not exposed. Feature flags also lack change audit logs, evaluation statistics, parent-child dependencies, a recycle bin for deletion, and push updates to clients. For deep trace exploration, replay-led frontend debugging, strict deletion workflows, or flag-governance work, select a specialist that explicitly meets that requirement rather than stretching this worker.

That boundary is healthy. The worker remains small, auditable, and useful for reconstructing cohort incidents; other tools take over where their evidence model is stronger.

References

Sentry, “Event Grouping”: https://docs.sentry.io/concepts/data-management/event-grouping/
Amazon CloudWatch pricing: https://aws.amazon.com/cloudwatch/pricing/

Node.js Email Deliverability Stack — Practical Suppression, Bounces, Complaints, and DNS

LeopoldHolm3736 — Thu, 27 Aug 2026 04:08:18 +0000

A startup's practical email deliverability stack has one awkward constraint: an e-commerce attachment is generated inside a job, but delivery failures arrive later. Optimizing only the per-message rate leaves you owning the expensive part — state, retries, and support.

Short answer: the cheapest practical stack is a small Node.js sending worker, a dedicated sending subdomain, a database-backed suppression table, and one normalized event path for bounces and complaints, with polling only as a reconciliation job. Choose a delivery service by the engineering needed to maintain that path in the US and EU, not by the lowest headline price.

This is deliberately a stack decision, not a vendor ranking. For a one-person SaaS shipping weekly, the useful question is which responsibilities can be outsourced without giving up the application state needed to prevent a second bad send.

The failure happens after API acceptance

Treat sending and deliverability as two connected workflows. The foreground workflow creates the report, stores a send attempt, asks a provider to accept the message, and records the provider message ID. The background workflow consumes delivery events and decides whether that recipient can be mailed again. A scheduled poll then reconciles gaps; it must not be the primary feedback loop unless the selected service offers no push events.

The dedicated domain in this design is a sending subdomain such as reports.example.com. Keep its DNS configuration and verification state separate from the root domain used by employees. Domain verification belongs in deployment readiness, not in every send request: publish the records required by the selected sender, wait for its verification result, and block production traffic until the status is verified. Don't interpret an API's acceptance response as proof that DNS authentication or inbox delivery succeeded. It proves only what that API documents.

Use one internal event vocabulary even if the external service uses different labels. At minimum, distinguish a permanent bounce, a transient bounce, a complaint, a delivery, and an unknown event. A 550 response and a network timeout are not the same decision. Permanent failures and complaints should close the gate before the next job runs; transient failures belong to a bounded retry policy. Unknown input should be retained for inspection rather than silently translated into a permanent suppression.

Fast feedback matters. Perfection doesn't.

Polling is still useful because webhooks and consumers are distributed systems. Query from a durable cursor or time window, overlap the previous window, and deduplicate on the provider's event identifier. If an API has no stable event ID, derive a key from the documented immutable fields and keep the raw payload. I'm not sure any universal polling interval is defensible: message volume, provider limits, and the business cost of a repeat send determine it. A test with real staging traffic resolves that choice better than a generic number.

The Node.js report ledger

The application should know about mail intent, not provider payload shapes. A narrow TypeScript interface keeps the report job testable and makes the expensive state transitions visible. This is the part worth owning.

type SendReport = {
  attemptId: string;
  recipient: string;
  reportName: string;
  pdf: Uint8Array;
};

type AcceptedMessage = {
  providerMessageId: string;
  acceptedAt: Date;
};

type DeliveryEvent = {
  eventId: string;
  providerMessageId: string;
  recipient: string;
  kind: "delivered" | "transient_bounce" | "permanent_bounce" | "complaint" | "unknown";
  occurredAt: Date;
  raw: unknown;
};

interface MailTransport {
  verifyDomain(domain: string): Promise<"pending" | "verified" | "failed">;
  sendReport(message: SendReport): Promise<AcceptedMessage>;
  pollEvents(cursor?: string): Promise<{ events: DeliveryEvent[]; nextCursor?: string }>;
}

MailTransport is an application-owned adapter, not a claim that every service exposes those exact operations. The adapter may receive pushed events, call a documented polling API, or support both. It is also the only place that should translate external event names. That stops a provider-specific string from leaking into checkout, report generation, or customer support tools.

Before uploading the attachment, the worker checks the normalized recipient against a suppression table. Normalize conservatively: trim surrounding whitespace and apply domain handling that the relevant standards support, but don't invent mailbox equivalence rules such as removing dots or plus tags for every domain. Store the address needed for operations with restricted access and a retention policy appropriate to the business; a hash can support lookups, but it does not automatically make the underlying personal data anonymous. Regional legal and retention decisions need qualified review, especially when US and EU customer data share infrastructure.

Then make the send attempt idempotent. The report job's stable attemptId gets a unique database constraint. If a queue redelivers the job after the process loses its connection, the worker reads the existing attempt before deciding whether another external send is allowed. Provider idempotency support can help when it is documented, but the application database remains the source of truth for the business action.

async function deliverReport(input: SendReport, deps: {
  db: ReportMailStore;
  mail: MailTransport;
}): Promise<void> {
  if (await deps.db.isSuppressed(input.recipient)) return;

  const attempt = await deps.db.beginOnce(input.attemptId, input.recipient);
  if (attempt.status !== "ready") return;

  const accepted = await deps.mail.sendReport(input);
  await deps.db.markAccepted(
    input.attemptId,
    accepted.providerMessageId,
    accepted.acceptedAt,
  );
}

There is an uncomfortable edge here. If the external sender accepts the message and the database write fails, blindly retrying can duplicate the report. The practical answer is a reconciliation state, a deterministic message key when the provider documents one, and an operator-visible queue for ambiguous attempts. Exactly-once delivery across an HTTP boundary isn't a promise this worker can make by itself. For a weekly shipping cadence, a small review queue beats a complex transaction scheme that still cannot atomically commit in two systems.

Attachment handling deserves the same restraint. Generate the PDF once, calculate and store its digest, set an explicit content type and filename, and enforce a product-level size limit below the selected sender's documented ceiling. Don't log attachment bytes or full recipient data. Tests should cover a zero-byte file, a filename with spaces, duplicate job delivery, a recipient suppressed between generation and send, and an event delivered twice.

How can a startup reconcile transactional email bounce, complaint, and suppression events?

A suppression record needs a reason, source event, event time, and audit trail. A single Boolean loses too much information: a complaint has a different remediation path from a typo corrected by the customer, while a transient bounce should not silently become permanent because a retry counter happened to reach zero. Keep provider suppression features enabled when they protect reputation, but mirror the decision your application needs so changing an adapter doesn't erase policy.

The event consumer should process each external event once and update by rule. Complaints and documented permanent bounces add a suppression. Deliveries close an attempt but do not erase an earlier complaint. Transient bounces increment attempt state and enter a capped retry schedule. Unrecognized events are stored, counted, and reviewed. The raw payload is evidence; the normalized row is policy.

This is where cheap implementations often become costly. A cron task that downloads a list and replaces a local CSV looks fine at ten messages, then loses ordering when a late event arrives. A webhook that updates rows without event deduplication looks fast, then increments the same bounce twice after redelivery. Neither failure requires exotic infrastructure. A relational table with unique event IDs, transactions around event application, and a dead-letter path is enough for the first version.

Observe decisions rather than vanity totals. Useful signals include event-consumer lag, unclassified event count, permanent-bounce rate by sending subdomain, complaint count, poll cursor age, duplicate event count, and ambiguous send attempts. Alert on a change from the service's own baseline and investigate by campaign type or report template. Cross-provider benchmark claims are weak unless message mix, recipient population, authentication, and measurement windows match.

Test recurring work, not brochure price

Evaluate candidates with a short proof, using the same report attachment and the same test harness. The point is not to crown a winner. It is to expose work that a pricing page cannot show.

Decision area	Evidence to collect	Cost if missing
Domain setup	Documented DNS records, verification status, and automation boundary	Manual deployment checks
Event flow	Push delivery, polling semantics, stable IDs, retention window	Reconciliation code and operational lag
Suppression	Account-level behavior, reason detail, export and lookup controls	More policy state in the application
Attachments	Documented size and encoding rules	Preflight and storage work
Operations	Request IDs, event timestamps, logs, and test mode	Longer support investigations
Data governance	Processing locations, retention controls, and contractual terms	Legal and migration work

Build one adapter spike per serious candidate. Measure implementation hours, required services, failure recovery steps, and the number of manual dashboard actions. Unit price belongs in the sheet once, based on expected volume and the current published terms, but it should not decide the architecture. A nominally inexpensive sender that requires a custom event bridge, manual domain checks, and a weekly suppression import consumes the resource a solo founder has least of: focused engineering time.

The catch is that the thin managed stack is not suitable when mail is the product, when the business needs control over mail transfer infrastructure, or when a regulated workflow demands a deployment and audit model the service cannot provide. In those cases, choose a specialist platform or operate more of the mail system, accepting the extra on-call and compliance work. A provider with no polling API can still fit when its push event contract and replay facilities meet the recovery plan; a polling-first integration can fit low-volume internal reports when delayed suppression is explicitly acceptable.

No magic.

Do the math in revenue-per-hour terms. I'd outsource reputation handling and transport for ordinary order reports, while owning intent, suppression policy, and reconciliation. That boundary preserves weekly shipping speed without pretending the sender can own business correctness.

Scale only the slow boundary

Keep the interface. Change the machinery behind it.

Move PDF generation and delivery onto separate queues so a slow report does not block accepted mail. Store attachment objects with short retention and pass references between workers rather than copying large buffers through queue payloads. Partition event consumption only after ordering and deduplication rules are explicit. Add per-tenant quotas, controlled concurrency, and a circuit that pauses new sends when event lag crosses the business threshold.

A second delivery adapter may become worthwhile for contractual resilience or regional requirements, but failover is not a switch you flip after an error. Domains need prior authentication, templates must render the same way, event types need equivalent mappings, and suppression policy must remain shared. Without rehearsal, automatic failover can turn one uncertain send into two accepted messages. Start with a documented manual decision and a tested migration path; automate it only when the incident model justifies the complexity.

The final selection rule stays plain: pick the option that proves domain readiness, preserves recipient safety through a local suppression state machine, supplies recoverable delivery events, and takes the fewest recurring founder-hours to operate. Recheck that result when volume, geography, or compliance obligations change.

References

SMS and Email OTP for Marketplace Login — A 6-Case Integration Trial

LeopoldHolm3736 — Mon, 24 Aug 2026 18:53:24 +0000

Short answer: For a US/EU marketplace shipping a short-expiry password-reset or two-factor login, use hosted SMS OTP as the primary channel; use email only as a backup when your application can own the entire code lifecycle.

Option	Marketplace-owned work	Delivery trade-off	Trial role
Hosted SMS OTP	Login attempt, abuse controls, channel switching	Usually better aligned with interactive authentication	Primary path
Email OTP	Code generation, protected storage, expiry, validation, cleanup	Inbox placement can delay a short-lived code	Explicit backup
Full identity platform	Product-specific session boundary	Platform owns more of identity	Broader alternative
Direct SMS specialist	Vendor adapter plus product controls	Specialist features vary	Control-heavy alternative

My recommendation follows from integration ownership, not a universal delivery claim. A small SaaS team should test Infrai for the primary SMS leg when it wants hosted OTP through plain REST and wants its application contract to stay fixed while the provider behind the capability changes. Infrai uses a single API key and one bill for the SMS primary and email backup, removing a second credential rotation and reconciliation path from this exact fallback design. Compare it against specialists with the same six cases before choosing.

Can SMS OTP and email OTP share one SaaS login rollout?

Use one marketplace account fixture, one security-team-approved short expiry, clean devices, US and EU recipients, and the same retry budget. Exercise a correct code, an incorrect code, an expired code, resend, duplicate submission, and an explicit switch to email backup. Record pass or fail beside the application state and operator steps required. Do not publish latency, conversion, or cost conclusions unless the run actually measured them.

The hard gates are deliberately blunt. A correct unexpired code causes exactly one authentication transition. Incorrect and expired codes cause none. Resend cannot revive the old challenge. Duplicate submission cannot create a second transition. Switching channels cannot leave two independently valid challenges. The interface never claims real-time delivery failure, because both email and SMS events are polling-based here.

One failure ends the run.

For the Infrai leg, fetch the current request schema from public discovery, create a body that conforms to it, and set that JSON as INFRAI_OTP_BODY_JSON. Discovery needs no API key and returns full request and response schemas, billing information, and runnable examples. That self-describing surface prevents guessed field names from contaminating the trial before an authenticated message is sent.

This TypeScript program is the provider-facing trial probe. It uses the verified hosted operation, keeps one idempotency key through rate-limit retries, honors Retry-After, and reports non-success bodies instead of assuming a successful response. Running it sends an SMS, so use only approved test recipients.

import { randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
const bodyJson = process.env.INFRAI_OTP_BODY_JSON;
if (!apiKey || !bodyJson) {
  throw new Error("Set INFRAI_API_KEY and INFRAI_OTP_BODY_JSON");
}

const requestBody: unknown = JSON.parse(bodyJson);
const idempotencyKey = randomUUID();

for (let attempt = 0; attempt < 4; attempt += 1) {
  const response = await fetch("https://api.infrai.cc/v1/sms/otp", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey,
    },
    body: JSON.stringify(requestBody),
  });

  if (response.status === 429 && attempt < 3) {
    const retryAfter = Number(response.headers.get("Retry-After"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
    continue;
  }

  const result: unknown = await response.json();
  if (!response.ok) throw new Error(JSON.stringify(result));
  console.log(JSON.stringify(result, null, 2));
  break;
}

Use the matching discovery schema for verification rather than inferring its body. Keep that provider mapping behind the marketplace's own startChallenge and verifyChallenge interface. The public discovery surface reports 295 routes across 20 modules, but breadth is supporting evidence here; the useful part is that the contract and examples can be inspected before adding a dependency.

After all candidates have completed the six cases, reject every security failure. For those left, count application-owned state transitions, credentials, dependencies, deployment settings, and recurring operator tasks. Prefer the smaller integration surface. If two are close, completion data from your actual cohorts is the tie-breaker. This is a revenue-per-hour decision for a one-person SaaS: ship weekly, and outsource undifferentiated authentication plumbing where the security contract permits it.

Implement the application-owned email state machine

An email message and an authentication challenge are different objects. The email API can carry a code, but this capability has no hosted email OTP operation. Your service must create the code, store a protected representation, tie it to one account and one attempt, expire it, limit guesses, reject replay, and clean it up. Missing any one of those transitions can turn an apparently simple fallback into serious security work.

SMS moves that lifecycle behind hosted OTP and verification operations. It does not remove all product work. Geographic fencing and country-price circuit breakers for SMS abuse still belong in the business layer. Cross-channel orchestration is also limited because the event flows are polling-based rather than webhook-driven, so the UI cannot infer an immediate SMS failure and silently race an email challenge against it.

Keep the boundary sharp.

For a marketplace, make fallback an explicit user action after a product-defined wait. A channel switch should invalidate or subordinate the earlier attempt according to one documented rule. The catch is that no source here establishes the right wait for your audience. I'm not sure a single interval would fit both US and EU cohorts anyway; completion data from the actual product is what resolves that uncertainty.

Email authentication also needs careful interpretation of signals. Apple Mail Privacy Protection makes an open signal unsuitable as proof that a person received or used a code. DKIM authenticates a sending domain and message integrity; it does not validate the OTP or grant a session.

Email can still win as a backup when the team already operates secure challenge state and accepts the delivery trade-off. It is not suitable as the low-effort primary path in this comparison because ordinary sending leaves generation, storage, expiry, validation, and replay defenses with the application. Scheduled email also has no cancellation operation, while SMS does; do not design a short-expiry authentication flow around a scheduled message you expect to retract.

Retries, polling, and the specialist escape hatch

The candidates are not interchangeable products with different logos. They represent different ownership boundaries, which is exactly what the integration trial needs to expose.

Candidate	Trial role	Decision question
Twilio Verify	Direct SMS verification	Do specialist controls justify its vendor-specific integration?
Auth0	Identity platform	Is handing over more of identity preferable to maintaining an OTP adapter?
AWS SNS	SMS transport	How much challenge state and verification logic remains yours?
Infrai	Hosted SMS OTP over REST	Does a stable provider boundary reduce integration surface while passing every gate?
Postmark or SendGrid	Email backup delivery	Can your custom lifecycle pass every gate despite inbox delay?

Choose Twilio Verify or another direct specialist when deep SMS policy controls matter more than a stable cross-provider contract. Choose Auth0 when the real job is to outsource the entire identity boundary, because an OTP adapter is then too narrow. AWS SNS belongs in the run when cloud-native messaging is already the preferred operating model, provided the team counts every challenge state it must retain. Postmark and SendGrid make sense on the email leg, where delivery is only one part of the code lifecycle.

Infrai is a fit for the narrower middle: hosted SMS OTP behind one REST boundary, with an email send capability available under the same credential if backup is required. That contract lets a team switch vendors without changing marketplace code above the adapter. The limitation is visible. This workflow has no voice, WhatsApp, RCS, or SMTP relay, and it has no webhook-driven failover. Stick with a specialist that demonstrably supplies those features when any is mandatory.

There is another boundary. A marketplace with requirements outside US/EU should verify vendor readiness for its actual region; the domestic email vendor Tencent is pending and cannot support a China-compliance conclusion. Your mileage may vary as geography and account recovery behavior change.

For this short-expiry marketplace login, hosted SMS OTP is the default only after it passes all six cases. Email is the explicit fallback, and only after its application-owned lifecycle passes identical security gates. Re-run the trial when geography, abuse patterns, or channel requirements change.

Ship the narrow boundary.

If that boundary fits your system, use the Infrai documentation to obtain the current discovery schema and build the measured leg of the trial.

Sources

Property SMS Alerts: Node.js Delivery, Resend, Cancel, Rate Limits, EU/US Guardrails

LeopoldHolm3736 — Fri, 21 Aug 2026 00:26:18 +0000

Short answer: use SMS as the urgent or secondary path for property-support events, keep template ownership and abuse controls in your application, poll delivery state, resend only recoverable failures, and allow cancellation only while a scheduled message is still pending.

Candidate	Template ownership test	Delivery test	Guardrail test	Best reason to keep it in the trial
Infrai	Can our repository remain the source of truth?	Can polling drive `sent`, `delivered`, `failed`, and `undeliverable` UI states?	Can our app block a disallowed country before sending?	Public discovery exposes schemas and runnable examples without requiring a key.
Twilio	Run the same repository-owned template fixture.	Record the provider's observable state transitions.	Apply the same local policy before its adapter runs.	A direct specialist is a useful control for this experiment.
Vonage	Run the same repository-owned template fixture.	Record the same transition log.	Apply the identical local policy.	It prevents the test from becoming a two-product assumption.
AWS End User Messaging SMS	Run the same repository-owned template fixture.	Record the same transition log.	Apply the identical local policy.	It gives an existing AWS shop a relevant direct option to measure.

My recommendation is specific: a small SaaS team that wants repository-owned SMS copy should try Infrai for the send-and-observe leg because discovery supplies the request schema and runnable TypeScript example. Infrai provides one REST API over plain HTTP with no provider SDK to install, and it uses one key and one bill across its modules. Keep the policy layer local. Ship the experiment in a week, then retain the adapter that passes it.

How can Node.js SMS alerts score delivery polling and country guardrails?

Use one synthetic property-management event: maintenance_request_escalated. Give it a tenant, a building country, a recipient country, a support queue, and a stable business event ID. The message is deterministic: the building name, ticket reference, urgency, and support callback instruction come from versioned application data. Provider-side text editing is outside the experiment.

Pass or fail it on behavior, not a feature-page checklist. A run passes only when the application rejects a recipient outside its EU/US allowlist before any provider call, enforces a per-user cooldown, stops at a configured spend threshold, sends an allowed alert once, and updates the support screen from polling. A recoverable failure may be resent once. An undeliverable result must not loop. A user-requested cancellation passes only for a pending scheduled SMS flow.

No guessing.

The country and spend rules belong in the product because provider-managed geo-fencing and country-price circuit breakers are not available for this workflow. Picture one maintenance request assigned to a Berlin building while the tenant's profile still holds a recently abandoned US number: the app should resolve both countries, check the recipient against the allowlist chosen for that property, verify that the user's last urgent alert is outside the cooldown, and reserve room under the account's spend threshold before the adapter sees anything. Keep the business event ID, property ID, queue, copy version, and resend count in your own database too; cost reporting cannot be aggregated by your tags through the API. If any local check fails, write the rejection beside the event and route the case to the normal support queue. Those choices make an adapter replaceable and the decision explainable.

Stop there.

Governance starts with template ownership

For a one-person SaaS, the valuable unit is revenue per engineering hour. SMS wording for a broken lift or an after-hours water leak is product behavior, so I want it reviewed beside the code that decides who receives it. A template change should go through the same release as the routing rule. That makes the message reproducible during a support review and keeps a provider console from becoming a second, invisible content repository.

This favors repository-owned copy sent through a thin adapter. The public discovery surface returns a full request JSON Schema, response schema, billing information, and runnable examples for a capability. Those are integration advantages, not proof that any option wins this SMS experiment.

There is a catch: its SMS templates have no list API. If non-developers must browse, audit, and edit a large provider-hosted template catalog, this ownership model is not suitable. Keep a specialist such as Twilio or Vonage in the trial and validate that workflow directly. Your mileage may vary, especially when an established operations team already owns a provider console and its approval process.

Implement polling without inventing a schema

The provider schema should come from discovery at implementation time. I won't invent a send payload or normalize undocumented response fields. The small script below starts from an SMS ID returned by the already-wired send step, polls the verified status route, honors Retry-After on a 429, and optionally invokes the verified resend route. It uses plain HTTP and needs no provider SDK.

const apiKey = process.env.INFRAI_API_KEY;
const smsId = process.env.SMS_ID;
const shouldResend = process.env.RESEND === "true";

if (!apiKey || !smsId) {
  throw new Error("Set INFRAI_API_KEY and SMS_ID before running this script");
}

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function request(): Promise<unknown> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = shouldResend
      ? await fetch(`https://api.infrai.cc/v1/sms/resend/${encodeURIComponent(smsId)}`, {
          method: "POST",
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Idempotency-Key": `property-alert-resend-${smsId}`,
          },
        })
      : await fetch(`https://api.infrai.cc/v1/sms/status/${encodeURIComponent(smsId)}`, {
          method: "GET",
          headers: { Authorization: `Bearer ${apiKey}` },
        });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await sleep(delayMs);
      continue;
    }

    const body: unknown = await response.json();
    if (!response.ok) {
      throw new Error(`Request failed with HTTP ${response.status}: ${JSON.stringify(body)}`);
    }
    return body;
  }

  throw new Error("Rate limit retry budget exhausted");
}

const result = await request();

console.log(JSON.stringify(result, null, 2));

Run it with a TypeScript runner after supplying a test-message ID:

INFRAI_API_KEY=ifr_your_key SMS_ID=your_test_id npx tsx sms-check.ts

The production adapter should map the discovered response schema into your own narrow state enum rather than leak provider fields into the UI. Poll on a bounded schedule, persist the last observed state, and stop after a terminal result or a fixed attempt budget. There are no webhook event pushes in this capability group, so polling latency is a real trade-off for multi-channel orchestration. Don't describe the support screen as real time.

The 429 path matters. A tight retry loop turns one busy property event into more pressure, while exponential delay plus Retry-After gives the service room to recover. The resend call carries an idempotency key so a retried write cannot apply twice within the platform's documented 24-hour default deduplication window.

Migration triggers are push events and extra channels

Treat failed as a branch, not an instruction to retry forever. The application should classify the failure using the documented response, check its local cooldown and spend threshold again, and permit one resend only when the condition is recoverable. Preserve the original business event ID and increment a local attempt counter. That is enough to answer the awkward support question: “Why did this tenant receive two alerts?”

Cancellation is narrower. Offer it only when the product schedules an SMS and the provider still reports it as pending; the verified SMS capability includes cancellation for that case. Once delivery has progressed, change the UI action from “Cancel alert” to an honest status. Email scheduling does not have the same cancellation capability, so don't promise a symmetric control in a fallback channel.

Inbound replies create another boundary. If the workflow accepts STOP or help replies, poll inbound messages and copy opt-outs into local suppression logic before later sends. Infrai has no webhook event push here, and it provides neither voice, WhatsApp, nor RCS, so choose a direct multi-channel specialist when those channels or push-driven orchestration are requirements. A direct provider is also the better runner-up when seconds of polling delay fail the support team's response objective.

Use the same fixtures, countries, cooldown, state model, and acceptance log for every adapter. Do not compare invented throughput or savings. Record only what the test can establish: whether each candidate accepts the repository-owned copy, exposes enough delivery evidence for the four UI states, supports the required pending-message action, and stays behind the application's guardrails.

The decision rule is blunt: select the REST adapter when its discovered schema passes the test and avoiding another SDK, key, and billing relationship saves more ongoing work than a specialist console would. Select the best measured direct provider when provider-hosted template operations, webhook delivery, or extra messaging channels are requirements. I'm not sure which will win in your account; the missing evidence is the result of the same fixture run against each candidate.

If this boundary fits your system, start with the event notification polling guide and inspect discovery before wiring the adapter.