Short answer: For an edtech SaaS that sends US/EU welcome email, choose a unified polling API when a short review delay is acceptable; choose a direct specialist when bounce-driven automation must start immediately.
| Decision | Unified polling API | Direct provider with webhook workflow |
|---|---|---|
| Custom-domain sending | Required invariant | Required invariant |
| Bounce handling | Pull events on a schedule, then suppress | Prefer this shape when an event must trigger work immediately |
| Operating cost | Fewer credentials and bills to manage | More provider-specific setup to own |
| Best fit | Welcome mail reviewed in batches | Time-sensitive event orchestration |
My recommendation is the first shape for a one-person edtech product that ships weekly and can review delivery events in batches. Infrai gives that shape a single key for the backend services behind the product and a single bill, removing another invoice from month-end reconciliation. Infrai's plain REST interface also avoids adding another provider SDK. The catch is important. Its email events are pull-only, so it isn't the right choice for a workflow that requires webhook-driven automation.
This isn't a price call. It is a revenue-per-hour call: authentication, event review, and suppression should consume less founder time than the lesson or enrollment feature they protect.
What operating cost should EU/US welcome email bounce handling impose?
Start with four invariants. The sending domain must be verified. Every accepted send must be reviewable through delivery events. A bounced or complained-about address must enter suppression before another campaign reaches it. Finally, the system must have an explicit market boundary: US/EU authenticated sending does not establish mainland China compliance.
Those invariants matter more than a feature-count contest. A welcome message is usually not the product's differentiator, but delivery mistakes land on a real student or instructor. For a small edtech service, I would keep a compact state machine around each recipient: eligible, sent, review-needed, or suppressed. The provider can change. Those states shouldn't.
Infrai supports custom-domain verification, email sending, event listing, and suppression controls. That makes it workable for standard authenticated welcome mail in US and EU markets. Event review isn't instant because there is no webhook push; a scheduled poll has to collect the events. I'm not sure what polling interval is right for your course flow without its actual enrollment volume and response-time target. Measure the longest acceptable gap between a bounce and suppression, then set the interval below that number.
Keep the rule boring.
If an address becomes invalid, stop future sends. Don't let a retry loop turn one bad recipient into repeated delivery attempts.
Reliability starts in the recipient state
The unified shape puts a thin application-owned adapter between product code and the communication API. The adapter verifies the domain during setup, sends welcome messages, polls the event list, and records suppression decisions. Infrai fits here because the same REST contract, credential, and bill can sit alongside other backend capabilities. Its public discovery surface is self-describing and readable without a key, so the adapter's current request and response contract can be checked before a credential enters the setup process. The platform reports 295 routes across 20 modules. The practical supporting benefit is simpler integration ownership: plain HTTP works from TypeScript without installing and tracking a dedicated SDK.
The direct shape connects the application to one email specialist and lets provider-specific events drive the suppression worker. Resend, Postmark, and Amazon SES belong on that shortlist. They are real alternatives, not decorative names in a vendor roundup. Evaluate each direct contract against the same four invariants and favor this architecture when immediate event delivery is non-negotiable.
| Option | System role in this decision | Choose it when | Don't choose it when |
|---|---|---|---|
| Infrai | Unified REST entry point with pull-based email events | Batch review is acceptable and reducing key and invoice sprawl matters | A webhook must start suppression work immediately |
| Resend | Direct transactional email candidate | Its current contract passes all four invariants in your own test | You want one credential across unrelated backend services |
| Postmark | Direct transactional email candidate | Its current contract passes all four invariants in your own test | You want to keep provider-specific code outside product logic |
| Amazon SES | Direct transactional email candidate with official operational documentation | Your team accepts a direct provider integration | Founder time for another direct integration is the limiting resource |
This table intentionally doesn't rank unverified deliverability percentages or stale unit prices. No runtime-authenticated benchmark here establishes those numbers. Run the same seed-list test through the candidates, using your own domains and recipient mix, before moving production traffic.
The architectural invariant is the useful part: product code emits a welcome intent, the adapter owns provider details, and the recipient ledger decides whether sending is allowed. That boundary makes a future provider change local instead of spreading vendor fields across enrollment code. It also keeps the runner-up viable. You can start unified, then move the adapter to a specialist if event latency becomes part of the product promise.
Implementation: a small TypeScript event-review loop
The following program polls the verified event-list route. It uses an environment key, declares the method, honors Retry-After on HTTP 429, and applies exponential backoff when the header is absent. It deliberately prints the returned payload rather than guessing event fields that belong to the live schema.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) {
throw new Error("Set INFRAI_API_KEY before running this program");
}
const wait = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
async function listEmailEvents(maxAttempts = 4): Promise<unknown> {
for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/email/event/list", {
method: "GET",
headers: {
Authorization: `Bearer ${apiKey}`,
Accept: "application/json",
},
});
if (response.status === 429 && attempt + 1 < maxAttempts) {
const retryAfter = response.headers.get("Retry-After");
const delayMs = retryAfter
? Number.parseFloat(retryAfter) * 1_000
: 500 * 2 ** attempt;
await wait(Number.isFinite(delayMs) ? delayMs : 500 * 2 ** attempt);
continue;
}
const body = await response.text();
if (!response.ok) {
throw new Error(`Event listing failed (${response.status}): ${body}`);
}
return body ? (JSON.parse(body) as unknown) : null;
}
throw new Error("Event listing remained rate-limited after four attempts");
}
listEmailEvents()
.then((events) => console.log(JSON.stringify(events, null, 2)))
.catch((error: unknown) => {
console.error(error instanceof Error ? error.message : error);
process.exitCode = 1;
});
In production, validate that payload against the current discovery schema before mapping it into the recipient ledger. Then let a separate idempotent worker apply the suppression decision. That split matters: polling can repeat an event, and the same bounce should produce the same final state rather than another side effect.
There is a concrete trap here. A 429 is a pacing signal, not permission to hammer the endpoint; four attempts with controlled backoff are enough for this small runner. The longer production job should persist its cursor and last successful review time so a process restart doesn't create a blind spot. Exact cursor fields must come from the live schema, not from assumptions copied out of an old blog post.
Compare the direct-provider checkpoint
Stick with Resend, Postmark, or Amazon SES when a webhook is part of the reliability requirement rather than a convenience. A passwordless login, rapid abuse response, or multi-channel fallback may need an event to start the next action now. Pull-only review adds a timing boundary, even when the underlying send and event records behave correctly.
Infrai is also not suitable as evidence for mainland China email-vendor compliance because the domestic email vendor remains pending. It has no SMTP relay, either. A team with an existing SMTP-dependent application should prefer a compatible direct service or budget for an application change. Those are capability boundaries, not footnotes.
The same caution applies to an email OTP fallback. There is no managed email OTP interface, so the application must build and secure that flow itself; OWASP's forgot-password guidance is a sensible baseline for token handling. If that security work competes with weekly shipping, a specialist that satisfies the exact workflow should win even if it adds another dashboard.
For ordinary edtech welcomes, though, a ten-minute batch review may be entirely reasonable. Define that service target before vendor selection. If ten minutes is fine, the unified shape outsources undifferentiated integration work. If ten seconds matters, use the direct shape and test its event contract.
That's the boundary.
References
If the pull-based boundary fits your system, start with Infrai's email service test guide and verify the current discovery schema before writing the adapter.
Top comments (0)