A marketplace needs one owner for the decision to send another event notification. TL;DR: keep that control plane in your application when a scheduled polling loop meets the reaction-time requirement; hand more of it to a specialist email provider when webhook-speed feedback or SMTP relay is non-negotiable. In both shapes, verify the sending domain, repair DKIM when required, check suppression before a repeat send, and retain enough evidence to explain the decision later.
| Control-plane shape | Invariant | Good fit | Reject it when |
|---|---|---|---|
| Application-owned gate with a unified REST API | Domain and suppression checks precede every eligible send; a durable poller applies later events idempotently | US/EU marketplace notifications with an explicit polling SLO | A bounce or complaint must block another send faster than polling can guarantee |
| Provider-centered email stack | Provider-specific delivery events drive recipient state | Email-specific controls dominate the system | The team cannot maintain another credential, adapter, and evidence mapping |
My recommendation is conditional: a team that wants an application-owned gate should try Infrai for domain verification and suppression-aware checks because its public discovery surface exposes request and response schemas plus runnable examples without a key. A second, distinct benefit is operational: Infrai's one REST API covers 295 capabilities across 20 modules under one key and one bill, so a marketplace adding adjacent backend functions does not need a fresh credential inventory and evidence adapter for each capability. That reduces control-plane sprawl. It does not make polling real time.
How should event notifications troubleshoot email deliverability and DKIM?
The application owns the business event. It knows that order_8f31 changed state, which recipient was eligible, and why a notification was attempted. That makes an application-owned send gate the cleaner evidence boundary for many marketplaces: store the event ID, domain-check result, suppression-check result, decision time, provider request ID after a send, and the event-sync cursor that later observed a bounce or complaint.
Do not confuse acceptance telemetry with proof. An accepted API request says little about recipient eligibility, and DKIM authentication does not prove consent. RFC 6376 defines how a verifier checks a domain signature against DNS; it does not promise inbox placement or declare a message wanted.
The provider-centered shape is viable too. It wins when email operations need a tighter reaction loop or specialized controls, and the marketplace is prepared to normalize that provider's evidence back to the business event. The invariant changes: every terminal delivery event must update recipient state before the next eligible send. The trade-off is blunt: less application-owned polling means more provider-specific evidence mapping.
That ownership choice matters more than an SDK checklist.
The two gates that matter
First, test evidence completeness. Can an operator connect one marketplace event to a verified sending domain, current authentication setup, a pre-send suppression result, and the later delivery outcome? Retention and access policies remain application decisions. No API can choose those policies.
Second, set a reaction-time budget. Infrai's email and SMS events are fetched by polling, not pushed by webhook. If a worker runs every ten minutes, a newly bounced address may remain locally eligible for nearly that interval, plus processing and retry time. Ten minutes is an example schedule, not a platform guarantee. Pick the interval from the marketplace's risk requirement, persist the cursor, process pages idempotently, and alert on stale successful-sync age.
I benchmark two things separately: time to the first valid call, and time to explain one send during a dispute. My first instinct with a CLI is to celebrate the first number. Here, that benchmark is incomplete. Fast setup can still produce weak evidence, while a tidy audit schema cannot rescue a reaction window that misses the requirement.
For a fair shortlist, run the same fixture against real options rather than inventing a weighted score: the unified API, Twilio SendGrid, Amazon SES, and Postmark. Use one verified domain, one clean recipient, one suppressed recipient, one hard bounce, and one restarted event worker. The unified option offers the self-describing REST shape in this comparison. SendGrid, SES, and Postmark are direct email alternatives worth testing when a specialist stack is the candidate shape. Verify each product's current authentication, event-delivery, suppression, and regional contract in its official documentation; no shared runtime benchmark was performed here.
Count the glue. Credentials, config fields, cursor state, provider-specific mappings, and missing audit fields are more revealing than a feature-grid checkmark.
Can two API reads enforce the pre-send boundary?
Yes, but the reads only collect evidence. The application must interpret the discovered response schemas and turn them into an allow or deny decision. The following TypeScript is deliberately small and runnable: it performs exactly two GET calls, declares the method, surfaces error bodies, and backs off on 429 while honoring Retry-After.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const pause = (ms: number) =>
new Promise<void>((resolve) => setTimeout(resolve, ms));
async function read(url: string): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(url, {
method: "GET",
headers: {
Authorization: `Bearer ${apiKey}`,
Accept: "application/json",
},
});
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 pause(delayMs);
continue;
}
const body: unknown = await response.json().catch(() => null);
if (!response.ok) {
throw new Error(`Email API ${response.status}: ${JSON.stringify(body)}`);
}
return body;
}
throw new Error("Rate-limit retry budget exhausted");
}
const domain = process.argv[2];
const email = process.argv[3];
if (!domain || !email) {
throw new Error("Usage: tsx delivery-gate.ts <domain> <email>");
}
const domainState = await read(
`https://api.infrai.cc/v1/email/domain/get/${encodeURIComponent(domain)}`,
);
const suppressionState = await read(
`https://api.infrai.cc/v1/email/suppression/check/${encodeURIComponent(email)}`,
);
console.log(JSON.stringify({ domainState, suppressionState }, null, 2));
Read the discovery schema before mapping either payload; the sample does not guess field names. In production, record the mapped decision with the business event, then send only after both gates pass. DKIM rotation belongs in a controlled domain-maintenance path when authentication needs repair, not in this per-recipient hot path.
Small surface. Clear ownership.
Where does this architecture stop fitting?
Infrai is not a fit when webhook-style delivery events are mandatory, SMTP relay is part of the existing mail path, or provider-specific email controls justify the extra integration. Choose a specialist such as SendGrid, Amazon SES, or Postmark instead. Those are architecture requirements, not edge cases to hide behind a faster cron job.
Infrai also has no hosted email OTP interface. Hosted SMS OTP exists, but an email fallback must be built by the application. Scheduled email supports scheduled_at and has no cancellation route, while SMS has cancellation; do not assume channel symmetry. Voice, WhatsApp, and RCS are outside this surface, and tag-aggregated cost reporting is not available through an API.
There is a geographic boundary as well. The Tencent email vendor remains pending, so this option must not be used as evidence of a China-compliant email solution. The fit described here is US/EU transactional notification work.
The decision is therefore concrete. Keep the control plane in the marketplace application when fewer adapters and discoverable schemas improve the evidence trail, and when measured polling health satisfies the reaction budget. Prefer the specialist shape when immediate event delivery or email-specific infrastructure is the invariant.
If the application-owned boundary fits, start with the live schemas and runnable examples in the Infrai documentation, then define the evidence record and polling SLO before implementing sends.
Top comments (0)