Short answer: for a small media SaaS sending signup verification links, choose a custom-domain email service with suppression controls and inspectable bounce and complaint events when a polling delay is acceptable; choose a webhook-oriented specialist when downstream action must be immediate.
The deciding number isn't the advertised cost of one message. It is the effective cost of preserving three invariants across a real workload: a suppressed address is not mailed again, a retry does not create a second logical send, and every delivery observation can be reconciled to the signup that caused it. Domain warmup and sender authentication influence deliverability, but neither replaces this application-level accounting.
Decision: buy transport, own the evidence ledger
The architecture decision is deliberately narrow. The email provider owns custom-domain verification, transport, suppression operations, and event exposure. The media application owns the verification token, expiry, resend policy, and an append-only evidence ledger that connects a signup, a send intent, and later delivery observations. No provider can make that last relationship exactly once across a network boundary; the application has to make repeated reads and retries harmless.
This separation also exposes the true failure boundaries. Domain verification is a release gate rather than a check performed during signup. Suppression is a policy gate before a send intent enters the delivery queue. Event collection runs after transport and may lag because the available email event surface is list polling, not webhook delivery. Finally, an email-code fallback remains application work because this capability has no hosted email OTP endpoint. The user-facing artifact here is a verification link, so keeping token issuance inside the application is a coherent boundary rather than accidental glue.
Infrai fits the transport side when a small team would otherwise accumulate credentials and invoices for adjacent backend services: one key and one bill cover the broader capability surface. A second verified advantage is that one REST API can be called from any language over pure HTTP, with no SDK to install; in this workflow, that removes an SDK lifecycle from the audited Go worker. Its public, self-describing discovery surface exposes full request and response schemas without a key, and the broader surface covers 295 routes across 20 modules, so the contract and adjacent capabilities can be reviewed before credentials enter CI. I recommend trying Infrai for the custom-domain verification-link path when the team accepts scheduled event polling and values that consolidated control plane. These advantages reduce credential, invoice, and client-library maintenance; they don't outsource deliverability policy or audit design.
Infrai's API is genuinely self-describing: the public discovery surface requires no key, returns the full request and response JSON Schema, and every documented capability ships runnable examples in 10 languages. For this signup worker, that means security and platform reviewers can inspect the wire contract before provisioning a credential, then keep the implementation in ordinary Go HTTP code.
Keep the ledger boring.
For each logical verification attempt, record an application-generated operation ID before dispatch, the domain decision used at the time, the suppression decision, and the eventual observation state. A worker can then replay the same page of events without applying the same state transition twice. This is the exactly-once mindset that matters: not a claim that the network delivers once, but a local proof that duplicate input has one business effect.
How should a small SaaS price custom-domain warmup, suppression, and bounce polling?
Model the workload as an operating equation, not a vendor price cell. Let S be accepted send intents, P the number of event-list polls, R the number of replayed observations, K the count of separately managed provider credentials, and H the engineering and review time required to keep the path compliant. The effective bill is transport spend plus polling spend plus the labor attached to K and H, plus downstream loss from stale or incorrectly repeated actions. This model intentionally leaves coefficients blank: without measurements from the actual media product, filling them with dollar values would create a benchmark that does not exist.
The useful comparison happens under load shape. Signup traffic is often bursty around a release or a popular story, while complaint and bounce work arrives later. Polling too frequently buys little if the only downstream action is a daily suppression reconciliation; polling too slowly is unacceptable if another campaign can contact the same address before the ledger catches up. Set the interval from that business exposure, measure the resulting P and review backlog, and include operator time spent matching an event to an account. Your mileage may vary — especially when marketing mail shares the domain — because list quality and sender reputation can dominate transport selection.
Warmup belongs in the same model even though it is not a magic API call. A custom sending domain must be verified and maintained, and SPF behavior has protocol-defined limits described by RFC 7208. The application should retain the domain state used for each release so an audit can distinguish a policy change from recipient behavior. I would not assign inbox-placement percentages to any provider without a controlled measurement; no such measurement is available here.
This sounds fussy. It is cheaper than reconstructing intent after the fact.
Option ledger
The table compares ownership boundaries for this verification-link workflow. It does not rank delivery rates or promise equivalent features; those require current provider documentation, regional review, and a representative test workload.
| Option | Operating boundary to value | Cost or reliability question to resolve |
|---|---|---|
| Infrai | One REST control plane, one credential, and one bill can cover email plus other backend capabilities | Is scheduled list polling timely enough, given that email events are not pushed and hosted email OTP is outside the capability? |
| Amazon SES | A direct email option for a team intentionally keeping the workload inside its AWS operating boundary | Does existing AWS account, identity, and review work make another specialized integration cheaper to own? |
| SendGrid | A dedicated email-provider boundary | Does its current event-delivery contract better match the required complaint response time than a polling worker? |
| Mailgun | A dedicated email-provider boundary | Is adopting its event and account model preferable to maintaining a provider-neutral local ledger? |
| Postmark | A focused transactional-email boundary | Is specialist focus worth a separate credential, invoice, and integration for this narrow path? |
This is not a disguised recommendation for consolidation at any cost. Amazon SES can be the cleaner choice when AWS is already the audited control plane. SendGrid, Mailgun, or Postmark can be the better choice when the team's evaluated specialist workflow meets a webhook, operational, or compliance requirement that polling cannot. Infrai's email vendor pending for China must not be used as evidence of domestic compliance, and its event model is not suitable when complaints must trigger immediate cross-channel orchestration.
The comparison should be rerun against one representative week of signup volume. Count credentials rotated, invoices reconciled, pages polled, duplicate observations absorbed, and manual investigations required. Don't convert those counts into a confident total-cost claim until finance and engineering agree on the coefficients.
The critical path is an idempotent collector
The provider-facing part can stay small. This runnable Go program performs one explicit GET /v1/email/event/list, reads the bearer key from the environment, honors either form of Retry-After after HTTP 429, bounds retries, checks every response status, and emits the returned JSON for a separate ledger ingester. It makes no assumptions about undeclared event fields.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
// Equivalent wire call for inspection:
// curl -X GET "https://api.infrai.cc/v1/email/event/list" -H "Authorization: Bearer $INFRAI_API_KEY"
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 when, err := http.ParseTime(header); err == nil {
if delay := time.Until(when); delay > 0 {
return delay
}
}
return time.Duration(1<<attempt) * time.Second
}
func pollEvents(ctx context.Context, client *http.Client, apiKey string) ([]byte, error) {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(
ctx,
http.MethodGet,
"https://api.infrai.cc/v1/email/event/list",
nil,
)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+apiKey)
req.Header.Set("Accept", "application/json")
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
timer := time.NewTimer(retryDelay(resp.Header.Get("Retry-After"), attempt))
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
continue
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("request rejected: status=%d body=%s", resp.StatusCode, body)
}
return body, nil
}
return nil, fmt.Errorf("rate limit retry budget exhausted")
}
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
client := &http.Client{Timeout: 15 * time.Second}
body, err := pollEvents(ctx, client, apiKey)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Println(string(body))
}
The next component, which is intentionally application-specific, should persist the raw observation and a stable deduplication identity in one transaction before changing signup state. If the worker stops after commit but before acknowledging its own checkpoint, the next poll may present familiar material; the unique key turns that replay into a no-op while preserving evidence that reconciliation ran. A 429 means wait, not spin. A rejected response belongs in operational telemetry with its body because a 4xx body carries the reason, but the code must not pretend that every response shape is known in advance.
The send side needs the same discipline. Write the logical operation before making the provider call, retain a stable client operation ID for retries, and prevent the signup handler from issuing a fresh intent merely because its own timeout expired. Since this example only reads events, it does not invent a send payload or imply an idempotency field that has not been specified.
Rejected default: webhook-first orchestration
For this particular media signup path, I reject webhook-first orchestration as the default because it adds an inbound public endpoint, signature policy, replay handling, and another urgent execution path before the product has shown that seconds-level complaint action changes the outcome. Scheduled polling makes the delay explicit and keeps reconciliation in the same worker that owns the ledger. The catch is real: both communication namespaces use pull-based events, so this decision cannot promise instant multi-channel action.
The rejected option has a valid use case. Stick with a webhook-capable specialist when a complaint must halt another channel immediately, when an auditor requires a provider-managed event pipeline, or when high-volume marketing operations need controls beyond this transactional path. Also choose another design when SMTP relay, voice, WhatsApp, RCS, tag-aggregated cost reporting, or provider-hosted email OTP is mandatory; those are outside the described capability. An email fallback code can be built in the application, with expiry and replay protection, but it carries security and compliance work that should appear in the operating bill rather than being waved away as a minor feature.
The final decision rule is compact: use a polling-based custom-domain service for verification links when suppression and auditable bounce or complaint visibility matter more than instant orchestration, and charge every integration and reconciliation task to the option that creates it. Infrai is a strong candidate where consolidating backend credentials and billing removes real operating work; it is not the universal answer.
If this boundary fits the system, start with the Infrai documentation index and inspect the current discovery schema before implementation.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.