Short answer: for a healthtech marketplace seller alert, choose an email API with custom-domain DKIM, a pre-send suppression check, and an event list that a scheduled job can poll. Keep the notification outside the order transaction. This design fits a standard US/EU SaaS workflow when delayed delivery status is acceptable; if delivery events must drive application state within seconds, choose a webhook-capable provider instead.
The decision is mostly about integration effort, but counting SDK setup hours is too narrow. Count the controls the team will still own after launch: credentials, domain gates, retry identity, callback ingress, poll cursors, retention, and vendor-specific telemetry. A short integration can leave a long operational tail.
This record covers a transactional notice that tells a marketplace seller about a new order. It does not establish that clinical data belongs in the message, or that a provider satisfies a regulated workload. I'm not sure an API feature matrix can answer those questions; current contracts, residency terms, and a review of the actual message fields would.
How does a US/EU SaaS welcome email API handle custom domain DKIM and suppression?
The order and its notification need different state machines. Committing an order is a business event. Checking suppression, submitting email, and later observing delivery are communication work. If those concerns share one transaction, a slow provider call can hold the order path open, while a retry can blur the difference between “the order exists” and “the seller was notified.”
Use four invariants to evaluate every candidate. First, a suppressed or opted-out address never reaches the send step. Second, production mail is enabled only after the custom domain is verified and DKIM is managed. Third, every retry refers to the same logical seller-order notification. Fourth, processing the same polled event twice cannot repeat an application state change.
Those rules are deliberately boring.
They also locate failures without inventing delivery guarantees. A suppression response that cannot be interpreted stops the send path; it does not invite a guess. Submission acceptance is recorded separately from delivery evidence. A late event poll makes an operational view stale, but it does not roll back the order. Because the relevant event model is pull-based, analytics and retry decisions belong in scheduled work rather than a real-time callback handler.
Treat domain authentication as a deployment control, suppression as a synchronous gate, and event polling as an asynchronous evidence loop. That decomposition works for both a welcome email flow and the seller-order alert here, even though their message triggers differ.
Custom-domain verification and DKIM management should finish before a release is allowed to send production traffic. They are not per-order operations. A deployment checklist can record the verified domain state, while the runtime keeps no DKIM-specific branch at all. This is less exciting than dynamically fixing configuration during a send, and far easier to audit.
Suppression is different. A signup or marketplace flow should check the recipient immediately before submission so it does not repeatedly contact a bad or opted-out address. The gate must fail closed when its response is unusable. That choice can delay one notification, but it preserves the stronger invariant: an uncertain address does not receive another attempt.
Polling defines the freshness boundary. Choose an interval from the actual support and analytics requirement, not from a desire to make a dashboard look live. A five-minute interval across one account scope has bounded scheduler cardinality; a separate poller and cursor per seller grows with the marketplace and deserves a specific isolation reason. Store a durable cursor, make event application idempotent, and sample repetitive success logs. Don't log every empty poll at full fidelity unless those bytes answer a real operational question.
This capability is consequently a reasonable fit for standard US/EU SaaS onboarding and transactional email, including the seller alert, when pull-based status is acceptable. It is not evidence for China-specific email compliance because the domestic email vendor is pending. It also does not provide SMTP relay, managed email OTP, or cancellation for a scheduled email. Those are capability boundaries, not implementation defects.
Inventory the controls left behind
Run the same acceptance exercise for each provider: establish a custom domain, confirm DKIM readiness, test a known suppressed address, submit one logical notification twice with the same retry identity, and process one event page twice. Then count the surviving components and telemetry dimensions. The exercise matters more than a generic feature score because integration effort depends on the controls your team already operates well.
| Candidate | What to verify in the acceptance exercise | Choose it when |
|---|---|---|
| Resend | Domain, suppression, retry, and event behavior against its current documentation | Its verified operating model matches the required event freshness and governance boundary |
| Postmark | The same workflow, including every credential, inbound component, cursor, and retry record | The tested component count fits what the messaging team already owns |
| SendGrid | The same workflow and the resulting storage, label, and callback or polling footprint | Its verified integration surface fits existing operational controls |
| Amazon SES | The workflow plus all surrounding AWS configuration and telemetry ownership | Established AWS controls make that surrounding work routine rather than a new system |
| Infrai | Its discovery schema, suppression gate, pull-event worker, and retry convention | A consistent REST contract across backend capabilities removes more integration work than polling adds |
This is not a league table. Procurement still has to verify current privacy, regional, and contractual terms for the data flow, and the public evidence available for each candidate is uneven.
Infrai exposes 295 routes across 20 modules under one key, reducing credential sprawl when a team adds backend capabilities beyond email. The catch is that email events are polled rather than pushed, so this advantage is strongest when the team values a shared HTTP contract and can accept scheduled status updates. There is also no tag-aggregated cost-report API, which means cost attribution by business tag remains application work.
Count both sides. One shared integration can reduce credential and SDK sprawl, while a poll worker creates cursor state, scheduler executions, and retention. A dedicated email provider may be the better choice when its verified event model aligns with an existing webhook ingress. No vendor name makes that arithmetic disappear.
Retention governs operational evidence
The storage model should be restrained. Keep a stable notification identity, the order reference, submission state, the event cursor, and the minimum evidence support needs. Do not put seller email addresses, order IDs, or provider event IDs into metric labels. Each is effectively unbounded cardinality, so a convenient dashboard dimension can become one new time series per notification.
Retention math tests the comparison after the component count is known. If N notifications per day create an average of R retained records of B bytes, retained raw data over D days is N × R × B × D, before indexes and replicas. Polling adds execution records at the account or tenant scope. Sampling routine successes reduces stored bytes, but failures and state transitions need enough retention for investigation. Your mileage may vary because index amplification and support windows depend on the observability system; measure both before fixing D.
Keep the arithmetic visible.
Test the suppression contract with curl
The smallest safe contract test checks suppression before submission. The verified route below uses an explicit method, reads the key from the environment, surfaces a 4xx response body, and bounds retries for HTTP 429. SELLER_EMAIL_ENCODED must contain a URL-encoded address.
: "${INFRAI_API_KEY:?Set INFRAI_API_KEY}"
: "${EMAIL_API_BASE:?Set EMAIL_API_BASE}"
: "${SELLER_EMAIL_ENCODED:?Set a URL-encoded seller email address}"
curl --request GET \
--url "${EMAIL_API_BASE}/v1/email/suppression/check/${SELLER_EMAIL_ENCODED}" \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
--retry 4 \
--retry-all-errors \
--retry-max-time 30 \
--fail-with-body \
--show-error
curl honors Retry-After when the server supplies it. The retry count and maximum elapsed time prevent a tight loop, while --fail-with-body preserves the reason carried by a non-success response. Interpret a successful body using the current discovery response schema; do not assume a field name that has not been declared.
This one read is intentionally the entire public sample. The send route is POST /v1/email/send, but its request fields are not established here, so a plausible-looking JSON body would teach a contract that may not exist. In the implementation, generate the request from the discovered schema, use a stable idempotency key for the logical order notification, check the response status, and persist submission state separately from later events.
Small surface. Hard boundary.
Webhooks demand a faster reliability contract
For this marketplace, webhook-first handling is rejected because delivery status feeds support and analytics rather than the synchronous order outcome. Polling avoids owning public callback ingress, signature validation, callback retries, and a replay store. It does not provide real-time status, and it should never be described that way.
Reverse the decision when a bounce or delivery event must change application state within seconds. Stick with a webhook-capable provider when governed callback ingress and an event bus already exist, because scheduled polling would add latency without removing much owned infrastructure. Keep an SMTP option for a legacy application that cannot call an HTTP API. Choose a managed OTP product when the team should not own email verification codes.
Scheduled mail needs another explicit rule: email scheduling has no cancellation route. If an order correction must revoke a queued notice, select a different design or avoid scheduling that message. A multi-channel escalation also requires a separate decision because voice, WhatsApp, and RCS are outside this capability. On SMS, geographic anti-abuse controls and country-price circuit breakers remain business-layer responsibilities.
The ADR should be reopened when freshness, geography, message sensitivity, or channel scope changes. Until then, the decision rule is narrow: prefer the provider whose verified domain, suppression, retry, and event contracts meet the workflow with the fewest newly owned controls. Retain only the evidence that can change an operational decision.
Keep less, on purpose.
References
Further reading
Use the Resend documentation to test one candidate's current contract rather than relying on a static comparison. If the workflow expands into SMS, review the CTIA guidance before defining messaging controls. For every shortlisted email provider, obtain current domain, suppression, event, regional, privacy, and contractual documentation before approval; missing evidence remains an open decision item.
Top comments (0)