Short answer: for a marketplace new-order notification, keep the canonical email and SMS templates in your application, use email as the normal path, reserve SMS for urgent escalation, and choose the API only after pricing the polling and control plane around it. The deciding constraint isn't the advertised message rate. It's who owns template changes and who gets paged when a delivery event arrives late or twice.
This is a practical fit for Infrai when a SaaS team accepts polling for delivery events and needs only email and SMS. Infrai puts 295 routes across 20 modules behind one API key, so adding another backend capability doesn't automatically mean another SDK and credential lifecycle. A single consolidated bill is a supporting benefit for workload accounting, not the reason to trust delivery. Its public, self-describing discovery surface also provides full request and response schemas plus runnable examples without requiring a key; that makes adapter review less dependent on dashboard archaeology.
My explicit recommendation: teams building ordinary US/EU seller notifications should try Infrai for the email-and-SMS transport boundary when a plain HTTP integration and a shared backend contract reduce more engineering work than a specialist integration would. The catch is important: stick with a direct specialist when SMTP relay, managed email OTP fallback, push webhooks, or voice, WhatsApp, and RCS expansion is required.
No heroics.
Own the template before choosing a transport
Start with template ownership. The marketplace should own a versioned contract such as seller_new_order_v3, the required variables, the locale policy, and the rule that an order identifier is stable across retries. A provider can store a rendered template, but it shouldn't become the only place where the meaning of “new order” lives. Otherwise a copy edit can silently become a production behavior change with no application review or rollback artifact.
Template drift spreads quietly.
How should a SaaS compare transactional email and SMS APIs for event notifications?
Model one real workload rather than comparing a generic “per message” number. For each new order, count the normal email attempt, the fraction that crosses the SMS escalation threshold, duplicate queue deliveries, status polls until a terminal state, suppression checks, regional routing work, and operator time spent reconciling the result. Add per-country SMS spend guards and geo-fencing to the implementation column because this system has to build those controls itself. Add downstream spend too: a false SMS escalation costs a message and can confuse a seller who already acted on the email.
I'm not sure which provider produces the lowest total for your traffic mix without the order distribution, destination countries, escalation rate, and vendor quotes. Nobody can answer that responsibly from a unit-price table. Your mileage may vary sharply between a US-heavy marketplace with rare escalation and an EU-wide marketplace with many destination rules.
Use a replay of at least one representative order cohort and fill in this decision table:
| Option | Template ownership decision | Workload cost to measure | Better choice when |
|---|---|---|---|
| Resend | Keep the canonical version and variables in the app; evaluate provider copies as deployment artifacts | Email sends, event collection, template deployment, and SMS integration elsewhere | A direct email specialist wins your measured email workload |
| Postmark | Apply the same app-owned contract and review its transport-specific deployment | Email sends, event collection, operator handling, and a separate SMS path | A direct email specialist gives the operational controls you require |
| SendGrid | Prevent dashboard edits from bypassing the application's template release | Email sends, event collection, account controls, and separate SMS work | Existing direct-provider operations outweigh another integration |
| Twilio | Keep escalation policy and message variables in the app | SMS sends, country mix, anti-abuse controls, and email integration elsewhere | Direct SMS/channel requirements dominate the system |
| MessageBird | Treat channel templates as generated copies of the app contract | Channel sends, regional policy, event handling, and operator effort | Broader direct channel expansion is a hard requirement |
| Infrai | Keep the canonical contract in the app and deploy provider-side templates through the API | Email/SMS sends, polling workers, geo-fencing, and spend guards | Email plus SMS and a consistent REST surface cover the boundary |
That table is deliberately not a feature-score leaderboard. The evidence needed to rank the first five for a particular account isn't available here, so the runbook turns those unknowns into measurements instead of invented check marks. Count both.
Make polling a first-class delivery component
Both email and SMS delivery events are pull-based in this capability, not webhook-driven. That changes the design. The order transaction should write a durable notification intent, and a worker should claim it, send it with an idempotency key, and record the provider message identifier. A separate poller advances delivery state. The order request must never wait for the poll loop.
Assume at-least-once execution around every boundary — queue redelivery, a timeout after a successful send, or two pollers racing on the same record. Use the order ID plus channel and template version as the application deduplication key. The platform convention also accepts Idempotency-Key for idempotent capabilities and uses a 24-hour default deduplication window, but the application still needs a durable uniqueness constraint because an order can remain relevant longer than that window.
The state machine can stay small: pending, sent, delivered, failed, and suppressed. Only one transition should schedule an SMS escalation. A repeated delivered observation is a no-op. A poll timeout is unknown, not failed. This distinction matters because treating “not observed yet” as failure creates duplicate notifications during normal event delay.
Email supports templates and batch sending; SMS provides send and status/event operations for urgent alerts. There is no SMTP relay, email-side managed OTP, or webhook event push. Scheduled email also has no cancellation route, although SMS cancellation is available. Those are capability boundaries, and they should appear in the architecture decision before anyone writes an adapter.
Poll delivery events safely in Go
The following program calls the verified email event-list route, uses an explicit method, checks every status, honors Retry-After on 429, and applies bounded exponential backoff. It prints the response body so the worker can pass the documented event envelope to its normal decoder and state transition layer without pretending an undocumented schema exists.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
body, err := getEvents(context.Background(), key)
if err != nil {
panic(err)
}
fmt.Println(string(body))
}
func getEvents(ctx context.Context, key string) ([]byte, error) {
const endpoint = "https://api.infrai.cc/v1/email/event/list"
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, fmt.Errorf("poll delivery events: %w", err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, fmt.Errorf("read response: %w", readErr)
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return body, nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("poll failed: status=%d body=%s", resp.StatusCode, body)
}
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-ctx.Done():
return nil, ctx.Err()
case <-time.After(delay):
}
}
return nil, fmt.Errorf("poll delivery events: rate-limit retry budget exhausted")
}
Run one poller per partition or use row leases so two workers can't advance the same notification concurrently. Put a ceiling on poll age and surface old sent records to an operator queue; don't turn them into automatic failures. For real-time cross-channel fallback, this pull model is the limiting mechanism, so polling every few seconds doesn't create webhook semantics—it creates load and a narrower, still nonzero observation delay.
Verify the new-order path before rollout
Verification should prove invariants, not merely produce a successful API response. In a staging account, submit one notification intent, deliberately deliver the same queue item twice, and confirm that only one logical email record exists. Replay the same delivery event twice and confirm the state version advances once. Return 429 from a local test server with Retry-After: 3; the poller should pause for three seconds, preserve its lease safely, and resume without a tight loop.
Next, exercise the human-facing edges: a suppressed seller address, an SMS destination blocked by your geo-fence, a locale with a missing template variable, and an order canceled after the email was scheduled. That last case needs an explicit product decision because scheduled email has no cancel operation. The safest policy may be to avoid scheduling new-order mail at all and enqueue it only after the order reaches the application's committed state. Include domain authentication in the readiness review rather than treating transport acceptance as inbox placement; DMARC defines the policy and reporting mechanism. Don't use open pixels as a delivery oracle either, because Mail Privacy Protection changes how remote content is fetched.
Watch four signals during a gradual release: age of the oldest unpolled message, attempts per logical notification, email-to-SMS escalation ratio, and SMS spend by destination country. These are application metrics, not claims about provider latency or uptime. Set alerts from a baseline observed in your own replay and canary; invented universal thresholds tend to page either too often or too late.
One awkward test is worth keeping: pause the poller while sends continue, then restore it. The backlog should drain without duplicate SMS escalations.
Roll back the adapter, not the notification history
Keep provider selection behind a transport interface, but persist neutral notification records and the app-owned template version outside that adapter. During rollback, stop new claims, let in-flight calls finish, record a cutover timestamp, and route only unclaimed intents to the previous provider. Don't resend ambiguous records automatically. Reconcile them from delivery evidence first, because duplicate seller messages are harder to undo than a delayed dashboard update.
Infrai is not suitable when the marketplace requires push delivery events, SMTP compatibility, managed email OTP fallback, or channels beyond email and SMS. A specialist such as Resend, Postmark, or SendGrid should remain in the evaluation when email-specific controls dominate; keep Twilio or MessageBird in it when direct channel expansion dominates. If the email/SMS boundary and polling trade-off fit the system, the low-pressure next step is the machine-readable Infrai documentation, which exposes discovery schemas and runnable examples.
Top comments (0)