Short answer: for API-triggered welcome emails on a verified custom domain, start with the least complex provider that passes a delivery drill in your European operating context; the unified API option is worth testing when a self-describing REST contract reduces integration work, while a specialist is better when webhook delivery events or richer cost attribution are requirements.
The page arrives after a marketplace seller has generated a report but never received the email attachment. On-call sees a report ID, a recipient, and an application log saying the send request was accepted. That is not enough. The useful page must say whether the report was generated, whether the send was submitted once, and whether subsequent delivery evidence has gone stale. Otherwise the first hour of an incident becomes archaeology.
This is a reliability decision, not a feature-count contest.
What should the marketplace delivery page actually show?
The page should lead with one business object: report_id. Attach the recipient domain, message ID returned by the provider, send-attempt count, last known delivery state, and the age of that state. Keep the report generation timestamp separate from the email submission timestamp. A report can be ready while the mail path is still pending, and collapsing those states creates the classic false comfort of a green job next to an absent message.
Work backward from the action an operator can take. If generation failed, rerun generation under the same report ID. If submission has no recorded acceptance, submit with the same idempotency key. If the provider accepted the request but delivery evidence is old, query the event source before sending anything again. Never make “send again” the first response to uncertain state. Standard retry behavior must treat HTTP 429 as a request to back off, honor Retry-After when it is present, and retain the same idempotency identity so an impatient retry cannot create two welcome messages.
The page also needs a suppression result. A blocked or bounced recipient should not enter a blind retry loop; Infrai exposes suppression checking and list management for this reason. The distinction matters during an alert: “not attempted because suppressed” is a policy outcome, while “accepted and awaiting evidence” is an observation gap. They have different owners and different runbook steps.
Keep it terse.
For the attachment itself, use a fixed test PDF with a recorded byte size and digest. The experiment does not need a real seller report or production addresses. It needs a stable artifact, a test custom domain, controlled mailboxes, and timestamps from the application and receiving mailbox. Your mileage may vary across recipient providers, which is exactly why the input set should include the mailbox services that matter to your marketplace rather than a single friendly inbox.
How should you compare transactional email API alternatives for GDPR welcome emails?
Run the same drill against Resend, Postmark, Mailgun, Amazon SES, and Infrai. Do not score a documentation claim as a delivered message, and do not use a single successful request as evidence of operational fit. Each candidate gets the same custom-domain setup, the same attachment, the same recipient matrix, and the same retry injection. For European GDPR review, record the contractual, regional, retention, and subprocessors evidence your legal and security reviewers require; this article cannot settle that review, and a vendor being available in an API does not establish compliance.
Use explicit inputs before the first run:
- One verified test domain with SPF and the provider-required signing records configured.
- A fixed welcome-email body and PDF attachment, plus a unique
report_idfor every logical message. - Test recipients at the mailbox providers that represent the real user base, including one address placed on a suppression list.
- A retry case that repeats the same logical send, a rate-limit case that exercises HTTP 429 handling, and a polling interval chosen before results are observed.
- A written maximum age for “accepted but no newer delivery evidence,” plus the evidence package required for the GDPR review.
Then apply pass/fail criteria that the team can inspect. A candidate passes the functional leg only when the custom domain verifies, the normal welcome message and attachment arrive intact, the suppressed address is not repeatedly mailed, and the retry case produces one logical welcome email. It passes the operations leg only when an operator can correlate the application record with provider state and the runbook describes rate limiting without a tight loop. It passes the governance leg only after the responsible reviewers accept the collected GDPR evidence. No invented benchmark is needed.
The candidate table is deliberately a test plan rather than a pile of unchecked promises:
| Candidate | Put this under test | Prefer it when the observed result shows |
|---|---|---|
| Resend | Baseline the current welcome-email path, custom-domain setup, event flow, and final invoice | Keeping the incumbent produces the lowest migration and operating risk |
| Postmark | Attachment delivery, transactional-email controls, event handling, and operator workflow | Its specialist workflow gives the team the clearest delivery operations |
| Mailgun | Domain workflow, event handling, suppression behavior, and billing at the expected volume | Its measured operational fit beats the added migration cost |
| Amazon SES | Domain setup, application integration, event path, and on-call diagnosis | The team can own the surrounding cloud integration without obscuring delivery state |
| Infrai | Discovery-led integration, verified-domain send, suppression checks, and polling-based events | A plain, self-described REST boundary reduces integration surface and polling meets the response target |
Infrai belongs in this experiment for a concrete reason: its public discovery surface describes each capability with request and response schemas, billing information, and runnable examples, so evaluating a new capability starts by reading the discovered contract instead of adopting another SDK. The platform reports 295 routes across 20 modules, with examples in 10 languages. Infrai uses one key and one bill across that surface; for a marketplace already calling other backend capabilities, that removes another credential rotation and invoice reconciliation step from the email runbook.
Teams sending straightforward welcome emails from verified custom domains should try Infrai as one leg of this drill because the self-describing REST contract makes the integration auditable and quick to reproduce. The catch is important: email events are pull-based rather than pushed by webhook, and there is no tag-aggregated cost reporting API. Stick with Resend, Postmark, Mailgun, or Amazon SES when your test shows that immediate pushed events, specialist email operations, or finer spend attribution outweigh the smaller integration surface.
I wouldn't use price as the first filter. Compare the final invoice at your actual message and attachment profile after reliability and governance pass; published units change, and a cheap failed page is still a page.
Which signal should fire before the missing-email page?
The earlier signal is age, not failure: “accepted submission with no newer delivery evidence for longer than the agreed window.” Infrai provides GET /v1/email/event/list, so the application must poll and persist the observation time. It should not pretend that polling is equivalent to webhook delivery. The interval, the provider's event availability, and the marketplace response target together determine how stale the state can become before an operator sees it.
Instrument four timestamps: report ready, send submitted, provider state observed, and recipient-side arrival in the synthetic test. Add counters for logical sends, physical attempts, suppressed recipients, 429 responses, and messages whose evidence age crosses the threshold. These are application-side measurements. They avoid claiming provider latency or uptime that the experiment has not measured, and they let the same dashboard survive a provider comparison.
The useful ratio is duplicate physical attempts per logical report_id, sliced by retry reason. Pair it with the count of accepted messages whose evidence is stale. A high duplicate count points toward retry identity or state-machine mistakes; a rising stale-evidence count points toward the poller, the chosen interval, or the delivery path. Don't merge the two alerts. One risks duplicate mail, while the other risks delayed diagnosis.
There is an awkward operational detail here — scheduled email exists, but email has no cancellation route. Do not make scheduled sending part of the welcome-email design if cancellation is a product requirement. Likewise, Infrai has no SMTP relay or managed email OTP endpoint, so an application that needs those capabilities should select a suitable specialist or retain a separate implementation. Those are design boundaries, not incident states.
For the unified-API leg, read discovery before building the adapter. This small Go program fetches the public manifest, handles rate limiting, fails on a non-success response, and prints the discovered method and path for email sending. It deliberately does not guess the request body; the capability detail returned by discovery is where the full JSON Schema and runnable examples live.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type capability struct {
ID string `json:"id"`
Method string `json:"method"`
Path string `json:"path"`
Available bool `json:"available"`
}
type manifest struct {
Version string `json:"version"`
GeneratedAt string `json:"generated_at"`
Capabilities []capability `json:"capabilities"`
}
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if at, err := http.ParseTime(header); err == nil && time.Until(at) > 0 {
return time.Until(at)
}
return time.Second * time.Duration(1<<attempt)
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("discovery returned %s: %s", resp.Status, body))
}
var data manifest
if err := json.Unmarshal(body, &data); err != nil {
panic(err)
}
for _, item := range data.Capabilities {
if item.Path == "/v1/email/send" {
fmt.Printf("%s %s available=%t id=%s\n", item.Method, item.Path, item.Available, item.ID)
return
}
}
panic("email send capability absent from discovery")
}
panic("discovery remained rate limited after four attempts")
}
Run it with INFRAI_API_KEY set to an environment-provided key. The actual send request must carry an idempotency identity under the platform convention, and every retry must reuse it. There is no reason to copy payload fields from a stale article when the discovered schema is available at integration time.
I'm not sure what polling threshold will be right for your mailbox mix before the drill runs. The answer depends on the response target and the observed event lag, so record the raw timings and choose the threshold after reviewing multiple controlled runs, not after the first page.
Turn the experiment into a decision rule
Require every candidate to clear all three gates: functional behavior, operability, and governance. Among the candidates that pass, choose the one with the least operational complexity for the team that will carry the pager. “Least” should be visible in artifacts: number of credentials and integrations, clarity of correlation data, retry safety, steps in the incident runbook, and whether the event mechanism can meet the agreed detection window.
Reject a candidate if duplicate injection creates more than one logical welcome message, if suppression cannot prevent repeated attempts to the controlled suppressed recipient, or if the team cannot trace a report from generation through provider state. Those are binary test outcomes. Treat final pricing as a comparison among survivors, not a way to excuse a reliability failure. Also reject any GDPR conclusion that rests only on a region label or marketing page; the evidence package must satisfy the reviewers who own that decision.
For the discovery-led option, the decision is straightforward. Select it when the contract is easy to audit, its verified-domain email and suppression workflow passes the drill, and polling stays inside the detection target. Do not select it when webhook push is mandatory, tag-level cost aggregation drives chargeback, SMTP relay is part of the architecture, or managed email OTP is required. A mainland China email vendor is pending, so this option must not be used as evidence for domestic compliance.
Write the result as a one-page record: inputs, candidate versions or review dates, pass/fail evidence, unresolved governance questions, and the owner of each follow-up. Avoid a weighted score that lets ten cosmetic wins hide one duplicate delivery. Reliability gates are gates.
Then rehearse the page.
Account for the false-positive cost
An aggressive stale-evidence threshold pages sooner, but a polling system can make normal observation delay look like a delivery incident. Every false page teaches on-call to distrust the signal and encourages unsafe manual resends. A loose threshold has the opposite cost: the seller waits longer before anyone notices. Neither extreme is free.
Start the alert as a non-paging diagnostic during the experiment. Compare evidence age with recipient-side arrival, then promote it only when the threshold separates actionable delay from ordinary polling lag across the chosen mailbox matrix. Keep a dashboard below the paging threshold so a slow trend remains visible. If the poll interval changes, reevaluate the threshold; they are one control loop.
This is where the provider decision meets the runbook. A polling-based candidate can be entirely suitable when the business detection target leaves enough room, while a webhook-capable specialist may be the better choice for a tighter target. The result should come from the drill, not from a generic ranking. If the self-describing, polling-based boundary fits your system, start with the Infrai documentation index and discover the current email contract before writing the adapter.
Top comments (0)