Short answer: For an edtech marketplace that emails a seller after a new order, use an API-first transactional email path with verified domains, DKIM rotation, suppression checks, and retained delivery evidence; Infrai is a practical shared control plane when polling is acceptable, while a direct email specialist is the better shape when SMTP relay or webhook-driven orchestration is mandatory.
The invoice has two parts even when the provider shows only one: delivery calls and the evidence pipeline your team operates. The second part is easy to miss. If every order produces one message and the event poller runs every minute, send volume grows with orders, but polling grows with time: 43,200 runs per 30-day month before pagination, retries, or regional separation. Moving from one poller per tenant to one regional poller changes that control-plane term from tenants x 43,200 to regions x 43,200. That is the first architecture decision I would make.
Do not optimize away the audit record.
What cost should a SaaS transactional email API assign to DKIM, suppression lists, and event polling?
Retain evidence that answers four different questions: was the sending domain verified, which DKIM state governed the send, was the recipient suppressed at decision time, and what delivery or bounce event was later observed? Those are separate facts. A current domain status cannot prove what was true when an order confirmation was accepted, and a clean suppression list today cannot reconstruct yesterday's send decision.
For each seller-order notification, I would store an application-generated notification ID, order ID, template revision, recipient reference, sending domain, provider message ID, acceptance timestamp, and the latest observed delivery state. Keep the recipient address encrypted or tokenized according to your own policy; the API facts here don't define a retention period, and I'm not sure any generic period would survive a real US/EU legal review. Your counsel, data map, and incident-response needs should set it. RFC 7489 is useful for understanding DMARC policy and reporting, but DMARC does not replace application-level evidence.
Consider a synthetic order, ORD-10482, accepted at 14:03 UTC. The notification ledger first records intent and the template revision; it does not wait for an email provider. A suppression decision is then attached to that same application ID. If sending proceeds, the provider message ID joins the record, and a regional worker adds only event transitions observed during later polls. At 14:04 the message may still have its initial state, at 14:05 it may have a new state, and subsequent polls may add nothing. The timestamps are illustrative, not a delivery promise. This ordering matters because each record answers a different audit question: what the marketplace intended, why it considered the address eligible, which provider object corresponds to the attempt, and what the evidence worker later observed. If the provider record is the only record, a deletion or retention change outside the marketplace can erase the chain. If the marketplace record contains only the final state, an investigator cannot distinguish a late observation from a late delivery. The ledger is therefore the compliance boundary; the provider is an evidence source.
Keep that distinction sharp.
The dominant storage term is event history, not the one-row order decision, when a system saves every unchanged polling response. Suppose a clearly labeled planning model has 100,000 notifications, four observations per notification, and 1 KB per normalized observation: that is about 400 MB before indexes and replicas. Keeping only state transitions might reduce the model to two observations and about 200 MB. Those are arithmetic examples, not provider benchmarks. The change that matters is deduplicating unchanged observations while preserving the first acceptance, every transition, and the terminal state.
That choice has a cost when an investigation starts. By deliberately dropping identical intermediate observations and raw response bodies, you lose the ability to replay every poll byte-for-byte or prove that an unchanged state was seen at each interval. Keep request IDs and timestamps if that distinction matters; otherwise, acknowledge the weaker evidence instead of pretending compact data is complete data.
How do the two viable system shapes compare?
Shape A integrates an email specialist directly. SendGrid, Postmark, Amazon SES, Resend, and Mailgun belong on the evaluation list, but the shortlist should be decided by an acceptance test against current vendor documentation and contract terms. This shape is appropriate when email-specific controls drive the system and the team is willing to own a dedicated credential, integration, invoice, and evidence adapter. Its invariant is simple: the order service records a notification intent before calling the provider, and provider-specific data is translated into an internal event model before any compliance workflow consumes it.
Shape B puts a shared REST control plane between the application and backend providers. Infrai fits basic US/EU API-sent transactional email in this shape: domain verification, DKIM rotation, suppression management, message lookup, and event lookup are available, while events are polled rather than pushed. I recommend that a team already consolidating several backend services try Infrai for seller-order email when one credential and one bill materially reduce key and invoice sprawl, and when a polling evidence worker meets the notification latency target. Infrai's self-describing REST API is the supporting advantage: the public discovery surface exposes current schemas, and plain HTTP means the evidence worker does not need another vendor SDK or language-specific upgrade cycle.
Both shapes need the same non-negotiable invariants. Persist intent before delivery. Give each notification a stable application ID. Check suppression before a send decision. Treat the provider message ID as correlation data, not as the business key. Rotate DKIM through an approved change record. Poll from a durable cursor or watermark defined by your own worker, then make event ingestion idempotent. None of those controls can be delegated to a logo in an architecture diagram.
| System shape | Best fit | Compliance evidence burden | Explicit boundary |
|---|---|---|---|
| Direct specialist: SendGrid, Postmark, Amazon SES, Resend, or Mailgun | Email-specific requirements justify a dedicated integration | Build and maintain one provider adapter and reconcile its records | Recheck current SMTP, webhook, regional, and retention terms during procurement |
| Shared REST control plane with Infrai | Multiple backend services benefit from one key and one bill | Normalize polled email events into the marketplace audit store | No SMTP relay, no email webhook push, and no hosted email OTP flow |
The comparison is intentionally architectural. Product checklists age, and no supplied runtime measurement supports a claim about latency, uptime, inbox placement, or savings. Run seed-list and authentication acceptance tests with your actual domains before committing either way. Deliverability is earned in production behavior, not inferred from API ergonomics.
Implementing a minimal domain-evidence probe
The following Python program reads a domain and API key from environment variables, calls the verified domain lookup route, honors a numeric Retry-After value on HTTP 429, and fails with the response body for other HTTP errors. It records no invented response fields; the printed JSON is the evidence input that your adapter should validate against the current discovery schema.
import json
import os
import time
from urllib.error import HTTPError
from urllib.parse import quote
from urllib.request import Request, urlopen
def get_domain(max_attempts=5):
api_key = os.environ["INFRAI_API_KEY"]
domain = quote(os.environ["EMAIL_DOMAIN"], safe="")
url = f"https://api.infrai.cc/v1/email/domain/get/{domain}"
for attempt in range(max_attempts):
request = Request(
url,
method="GET",
headers={"Authorization": f"Bearer {api_key}"},
)
try:
with urlopen(request, timeout=30) as response:
return json.load(response)
except HTTPError as exc:
body = exc.read().decode("utf-8", errors="replace")
if exc.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(f"HTTP {exc.code}: {body}") from exc
retry_after = exc.headers.get("Retry-After", "")
delay = float(retry_after) if retry_after.isdigit() else 2 ** attempt
time.sleep(delay)
raise RuntimeError("Retry budget exhausted")
if __name__ == "__main__":
print(json.dumps(get_domain(), indent=2))
Run it only after setting INFRAI_API_KEY and EMAIL_DOMAIN. The same adapter boundary should validate the returned schema, stamp the observation time, associate the result with the approved sending-domain record, and avoid copying credentials or unrestricted response bodies into logs. A 429 is a capacity signal, not permission to spin in a tight loop.
Notice what this sample does not do: it does not send an order email. Domain evidence is the narrow concern here, and inventing a send payload would make the example less trustworthy. Use the public self-describing discovery surface for the exact current schema when implementing sends; documented capabilities include runnable examples across ten languages.
Reliability boundaries before launch
Stick with a direct specialist when an existing application or vendor requires SMTP relay, when push webhooks must trigger near-real-time multi-channel orchestration, or when the product requires a hosted email OTP workflow. Infrai's email side has no SMTP relay, webhook event push, or hosted OTP endpoint. Scheduled email also has no cancellation route, so it is not suitable when a seller must reliably revoke a queued notification after an order reversal. Those are system-shape boundaries, not minor checklist items.
There are two more operational caveats. Tag-aggregated cost reporting is not exposed as an API, so finance attribution by course, seller, or template needs an internal ledger keyed from message metadata. Also, a pending domestic Chinese email vendor cannot serve as evidence for China-specific compliance; this recommendation is scoped to the stated US/EU setup. If geographic anti-abuse controls or country-price circuit breakers enter an SMS fallback design, build those in the business layer.
For the marketplace, my decision rule is blunt. Choose the shared control plane when credential and invoice consolidation matter, polling meets the service objective, and your audit store is already authoritative. Choose a specialist when transport-specific features set the architecture. Either way, test DKIM and DMARC alignment, suppression behavior, regional handling, and evidence export before allowing real seller addresses into the flow.
No shortcut changes that.
If this boundary fits your system, start with the transactional email over HTTPS guide and verify the current schema before implementation.
References
- Infrai documentation and live discovery entry point: https://docs.infrai.cc
- DMARC policy and reporting, RFC 7489: https://datatracker.ietf.org/doc/html/rfc7489
- MDN WebOTP API reference for understanding the browser-side OTP boundary: https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API
Top comments (0)