DEV Community

CaspianHayes3586
CaspianHayes3586

Posted on

Low Volume SaaS Password Reset Email API: Templates Suppression and Seller Delivery

#email #sre #architecture

A seller notice can fail quietly while the order itself remains valid; a password reset cannot wait for the next support ticket. Short answer: for a low-volume US/EU healthtech marketplace, start with a simple transactional email API that supports templates and suppression, but choose it only after defining how your application will reconcile accepted sends with delivery events. The cheapest-looking send call is not the integration boundary. An order ID, a notification ID, and a separate recovery alert path matter more than a vendor dashboard.

Consider a prospective incident exercise, not a reported outage: order 78142 commits, its seller notice is submitted, and the seller says nothing arrived. Meanwhile a user requests a password reset. I would ask which page fired and what durable record connects each request to the provider's eventual outcome. If the only evidence is a green send-request chart, the investigation stops at acceptance. No answer yet.

The invariant is one application-owned notification intent per logical event, with a stable identifier, an explicit outcome, and no patient details or reset tokens in shared logs. A worker can retry the intent; the order must not disappear because email was slow. Password resets need their own failure signal because delayed access recovery is not equivalent to a missed seller notice.

How should a low volume SaaS password reset email API track delivery?

A rejected send is immediately observable from the response. A later hard bounce is different: it belongs in suppression handling, not a tight retry loop. For a provider whose email events are pulled rather than pushed, the absence of an event before the next poll is not itself proof of failure. Poll cadence therefore becomes part of your detection time; choose it consciously and record when each notification was last checked. An alert on every pending notice would page on your own polling interval.

I would keep at least three application states distinct: intent persisted, provider submission accepted, and delivery outcome observed. This is a proposed application design, not a claim that any vendor exposes those exact status names. An unresolved seller notice can enter an investigation queue, while sustained password-reset submission failures warrant a direct recovery alert. The dashboard is supporting evidence, never the sole source of truth.

No page, no recovery.

Which option costs less work to integrate?

Count the dependencies, credentials, event plumbing, and state your team will maintain, rather than comparing only the first successful API response. These are integration questions, not measured setup times or rankings.

Option Integration surface When it fits Boundary to verify
Amazon SES AWS-based email service A team already operating AWS identity and monitoring Identity setup and how sending events enter the existing alert path
Postmark Dedicated transactional email API A team that wants a focused email product Template, bounce, and event contracts for both order notices and resets
Resend Dedicated email API A team evaluating an email-focused developer workflow The documented event and suppression workflow against the application's state model
Infrai Plain REST API; no SDK installation required A team that wants an HTTP integration for basic sending, templates, and suppression Pull-only email events, no SMTP relay, and no cost report aggregated by tag

The concrete Infrai advantage on this axis is small and testable: anything able to send an HTTP request can call the same REST API without installing an SDK or tracking a client-library version. Infrai uses a single API key and one bill across 295 routes in 20 modules: a marketplace using other backend capabilities there need not juggle separate API keys and invoices for each module. Its public self-describing discovery also exposes request and response schemas and runnable examples, reducing guesswork before implementation. That does not eliminate the worker or the delivery ledger. Infrai has email send, template creation, domain verification, and suppression capabilities; its events require polling, and it does not provide SMTP relay. This is a real limitation: if immediate bounce-triggered recovery or an SMTP-based integration is mandatory, use a provider whose documented contract satisfies that requirement instead; evaluate Postmark, Resend, and SES against that specific requirement rather than assuming any one of them supports your exact workflow.

Before deciding, run the same exercise against all four options: submit a seller notification and a password reset with distinct internal IDs, cause a rejected request in a test environment, and trace the reason back to each intent. Verify each provider's current regional and data-handling terms separately. An API comparison cannot establish health-data compliance.

What prevents an accepted send from becoming a blind spot?

Persist the notification intent with the order using a transactional outbox or an equivalent atomic application workflow. Then let a worker send it and record the response; reconcile subsequent delivery evidence on a schedule. This adds application code, but it also means a crash between committing an order and sending email cannot silently erase the intent. Keep a unique application constraint on the logical order-to-notice relationship so repeated worker execution does not create multiple intents.

For Infrai, the documented Idempotency-Key convention has a default 24-hour deduplication window. Reuse the same key when retrying a write inside that window; retain the application's own uniqueness constraint beyond it. On HTTP 429, honor Retry-After where provided and use exponential backoff otherwise. A hard-bounced recipient is not a transient 429. Suppression management helps avoid repeated sends to known-bad addresses, but it cannot tell the seller that an order exists through another channel.

Here is a read-only Go probe for the suppression list. Set INFRAI_API_KEY and INFRAI_API_BASE_URL in the environment; the latter must be the provider's HTTPS API base ending in /v1, without a trailing slash. Run it only in a controlled terminal, since a response can contain email addresses. It verifies access to suppression data, not successful delivery.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key, base := os.Getenv("INFRAI_API_KEY"), os.Getenv("INFRAI_API_BASE_URL")
    if key == "" || base == "" {
        fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY and INFRAI_API_BASE_URL")
        os.Exit(1)
    }
    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, base+"/email/suppression/list", nil)
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { panic(err) }
        body, err := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if err != nil { panic(err) }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            pause := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
                pause = time.Duration(seconds) * time.Second
            }
            time.Sleep(pause)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            fmt.Fprintf(os.Stderr, "suppression query: %s: %s\n", resp.Status, body)
            os.Exit(1)
        }
        fmt.Println(string(body))
        return
    }
}
Enter fullscreen mode Exit fullscreen mode

Use the provider's discovery schema to implement the actual send request fields. I am deliberately not guessing a send payload here: a plausible-looking field name in a copyable example can be more damaging than no example at all. For the same reason, treat an accepted response as a submitted request, not a delivery receipt. The ledger and the event poll must close that gap; a probe that returns a suppression list cannot tell you whether order 78142 reached its seller, and a missing event at the next poll cannot distinguish a slow delivery from a lost one without an explicit investigation deadline.

When does the simple API stop being enough?

Pull-only events impose a detection delay. If a password-reset bounce must trigger another recovery path immediately, this design needs a different event contract; polling faster is still polling. Infrai also has no hosted email OTP interface and no cost-reporting API aggregated by tag, so those workflows belong to your application if required. Its Tencent email vendor is pending, which means this US/EU assessment offers no basis for China compliance assumptions.

For low-volume transactional traffic, basic sending, templates, domain verification, and suppression may be sufficient. The operational test is sharper: can the on-call engineer name the failed notification, distinguish a suppressed address from a rate limit, and know when the last delivery check ran? If not, a lower quoted price or an attractive chart will not shorten the incident.

References

The provider documentation below is the starting point for checking each option's current integration contract; HTTP retry semantics are defined in RFC 9110.

Sources

Top comments (0)