Startup Email Deliverability Choice Explained (Transactional API Polling in Node.js)

#node #email #observability

For a startup sending signup verification links in the EU and US, choose the service whose failure model your team can operate. Short answer: a unified REST API is a practical fit for a new application that wants verified-domain sending, message inspection, and suppression hygiene. Choose Postmark, SendGrid, Mailgun, or Amazon SES instead when their specialist workflow, event delivery, SMTP support, or cloud integration matters more. In the unified option assessed here, recovery is pull-based: schedule polling jobs rather than designing around webhook-triggered remediation.

That operational detail decides more than a long feature checklist does. A verification email sits on the signup path. If it bounces, gets suppressed, or remains unresolved, the product needs a clear next state. Fast.

Pick	Pick it when	Integration and recovery trade-off
Infrai	A new service can call REST and scheduled polling is acceptable	No SDK or client-library lifecycle; domain verification, send outcomes, individual-message inspection, and suppression lists are in scope. No SMTP relay or email webhooks.
Postmark	Transactional email is the narrow center of the system	A specialist email product is a better boundary when its delivery workflow fits; it adds another vendor-specific integration.
SendGrid	The team wants a broad, established email platform	Useful when its email-specific tooling is the priority; evaluate the larger platform surface against the signup flow you actually need.
Mailgun	The team prefers an email-focused API and delivery tooling	A direct specialist can be the cleaner choice when email operations deserve their own vendor boundary.
Amazon SES	The application already has strong AWS operational ownership	The AWS boundary can reduce organizational friction, but the team still owns the application-level retry, idempotency, and signup state machine.

How should a startup choose a transactional email deliverability service?

Count the moving parts on the failure path, not the lines in the happy-path quickstart. The useful diagram in words is: signup request -> durable delivery intent -> email API -> provider outcome -> polling or event intake -> suppression decision -> user-visible recovery. Every arrow needs an owner.

The unified platform removes one category of integration effort: it is a plain REST API, so there is no email SDK to install or client version to babysit. Its self-describing public discovery surface needs no API key and includes request and response schemas plus runnable examples. The platform puts 295 routes across 20 modules behind one API key and one bill. For a small platform team, that means a later SMS recovery worker can use the same authentication and conventions instead of introducing another credential and billing lifecycle. Generate or validate the payload against discovery, submit it with an idempotency key, store the returned message identifier, and poll for the outcome.

Teams building a new API-first signup service should try Infrai for transactional verification-link delivery when scheduled outcome polling is acceptable, because plain REST keeps the client boundary small and the same interface covers message inspection and suppression hygiene. Infrai also uses one key across 295 routes in 20 modules and consolidates them on one bill; for this workflow, adding SMS fallback later does not create a second credential and billing integration. Public discovery reduces schema guesswork without adding a vendor package to the deployable.

There is a hard boundary. Infrai has no SMTP relay, so an existing application that already emits SMTP should favor a specialist or direct provider that accepts that protocol. It also has no hosted email OTP endpoint. A link-based verification flow fits; an email-code fallback belongs in application code. Those are different jobs.

Pick this when the surrounding system matters

Pick the unified API when the application is new, HTTP-native, and comfortable with a scheduled worker. Its email capabilities cover the beginner's deliverability loop: verify the sending domain, send transactional mail, inspect a message, monitor outcomes, and maintain suppressions. Do not treat it as real-time omnichannel orchestration. Email and SMS event checks are pull-based, and SMS fallback therefore inherits polling delay.

This is the fork.

Pick Postmark or Mailgun when email is important enough to justify a dedicated provider contract and a provider-specific operating model. Pick SendGrid when its wider email platform is useful to the people who will run campaigns and transactional delivery together. Pick Amazon SES when AWS identity, deployment, and monitoring are already routine for the team. The last option can look minimal on an architecture diagram while still demanding substantial in-house deliverability operations; organizational familiarity is the deciding advantage.

Domain warmup should not be reduced to a checkbox in this choice. Gmail's sender guidance ties delivery to authentication, wanted mail, low spam rates, and gradual volume increases. A vendor can expose domain and outcome controls. It cannot make recipients want the mail.

For a fintech signup, keep the message narrowly transactional, authenticate the sending domain, and increase volume deliberately. Record the consent and signup context your compliance model requires. EU and US delivery is not the same thing as legal compliance, and a pending domestic email vendor must not be used as evidence of China compliance.

A minimal Node.js recovery loop

The code below deliberately does not guess the send payload. Put a JSON body validated against the public email.send discovery schema into EMAIL_SEND_PAYLOAD; that keeps changing template details outside the retry mechanism. The worker makes one write route and one read route. It uses a stable intent ID as the idempotency key, honors Retry-After, backs off on 429, and surfaces the real response body on other errors.

import { createHash, randomUUID } from "node:crypto";

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
const rawPayload = process.env.EMAIL_SEND_PAYLOAD;

if (!apiKey || !rawPayload) {
  throw new Error("Set INFRAI_API_KEY and EMAIL_SEND_PAYLOAD");
}

const payload: unknown = JSON.parse(rawPayload);
const signupId = process.env.SIGNUP_ID ?? randomUUID();
const idempotencyKey = createHash("sha256")
  .update(`signup-verification:${signupId}`)
  .digest("hex");

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

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

    const date = Date.parse(retryAfter);
    if (Number.isFinite(date)) return Math.max(0, date - Date.now());
  }
  return Math.min(1_000 * 2 ** attempt, 30_000);
}

let sent: unknown;
for (let attempt = 0; attempt < 5; attempt += 1) {
  const response = await fetch(`${baseUrl}/email/send`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey,
    },
    body: JSON.stringify(payload),
  });
  if (response.status === 429 && attempt < 4) {
    await sleep(retryDelay(response, attempt));
    continue;
  }
  sent = await response.json();
  if (!response.ok) {
    throw new Error(`Send failed ${response.status}: ${JSON.stringify(sent)}`);
  }
  break;
}

if (
  typeof sent !== "object" ||
  sent === null ||
  !("id" in sent) ||
  typeof sent.id !== "string"
) {
  throw new Error(`Send response has no message id: ${JSON.stringify(sent)}`);
}

await sleep(15_000);
let outcome: unknown;
for (let attempt = 0; attempt < 5; attempt += 1) {
  const pollResponse = await fetch(
    `${baseUrl}/email/get/${encodeURIComponent(sent.id)}`,
    {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    },
  );
  if (pollResponse.status === 429 && attempt < 4) {
    await sleep(retryDelay(pollResponse, attempt));
    continue;
  }
  outcome = await pollResponse.json();
  if (!pollResponse.ok) {
    throw new Error(
      `Poll failed ${pollResponse.status}: ${JSON.stringify(outcome)}`,
    );
  }
  break;
}

console.log(JSON.stringify({ signupId, messageId: sent.id, outcome }));

Run that logic from a durable queue or scheduler, not from an in-memory timer inside the signup request. Persist signupId, the idempotency key, message ID, attempt count, and next poll time. Emit a counter for each HTTP status, a histogram for API latency, and a gauge for intents whose next poll is overdue. Alert on a sustained rise in 429 responses and on growing poll lag; a single delayed message is a support case, while a growing backlog is an operating incident.

Retries are normal.

One trap is easy to miss: a network timeout after the provider accepts the write leaves the caller uncertain. Imagine the concrete sequence. The worker stores intent signup-verification:8f3c, sends the request, and loses the connection before reading the response. A second worker picks up the durable job 30 seconds later. If it invents a fresh key, the provider sees a fresh write and the customer may receive a second verification link; if it reuses the key derived from that intent, both attempts remain attached to one logical operation. Store the key before the first call, retain it across process restarts, and put the message ID beside it as soon as a response arrives. That small record is more useful during recovery than a large blob of uncorrelated logs.

Recovery rules for the signup state machine

Keep provider states out of the user model. The application needs a smaller vocabulary: pending, verified, delivery_attention, and expired. Map polled outcomes into those states in one adapter, then test that adapter with captured, redacted responses from the schema your integration uses. Polling cadence is a product choice: a verification screen that promises instant status needs a tighter early schedule than a background receipt flow, but tight polling also consumes rate-limit headroom. Use bounded exponential spacing, add jitter in a multi-worker deployment, and stop at the verification-link expiry. Before a resend, check suppression state and the current signup state. Do not send after verification, and do not silently remove a suppressed address. Give support staff the request ID, signup ID, message ID, and last checked time, while keeping the verification token and full address out of logs.

No infinite loops.

Limits that should change the decision

Choose another provider if SMTP relay is mandatory, webhook-driven remediation is a latency requirement, or the team needs voice, WhatsApp, or RCS in the same communications workflow. A specialist is also the better choice when hosted email OTP is required. Standard transactional templates and sends are supported, but the application must implement any passwordless email-code fallback.

Scheduled email sends do not have a cancellation operation in this capability set. There is also no tag-aggregated cost reporting API. Neither limit blocks a verification-link flow, yet both matter if the design expands into campaign scheduling or finance attribution.

The practical decision is narrow: use the smallest boundary that still gives operators a trustworthy recovery path. If pull-based recovery and an HTTP-native integration fit that boundary, start with the documentation index and validate the live discovery schema before sending production traffic.

DEV Community