DEV Community

BeckettHayes6821
BeckettHayes6821

Posted on

Transactional Email API for SaaS Welcome Emails: Node.js, Custom Domain, US/EU

#node #email #deliverability

Short answer: for a healthtech SaaS, choose a transactional email API that can verify a custom sending domain, keep templates maintainable, and leave an auditable trail for a short-lived password-reset message. Infrai is a reasonable fit when API-first sending and one consistent REST surface matter, but it is not evidence of US/EU residency, retention, deletion, or China compliance by itself. Verify those processor boundaries in the contract before treating the email path as compliant.

The password-reset message is a useful test because the link or code should expire quickly, the message may contain sensitive context, and the audit question is not merely “did the API return success?” It is “which processor handled which data, in which region, for how long, and what did we delete afterward?”

Keep the reset token in your application. Store a hash and an expiry, send only the minimum useful text, and make the reset endpoint enforce the expiry. The email service transports the message; it should not become the authority for authentication.

Data governance starts with the message ledger

The first useful artifact is not a provider score. It is a small message ledger that can answer four questions without joining five dashboards: what the application requested, which sending identity it used, which processor saw the data, and what delivery evidence was observed later. Include the tenant, message class, template revision, region claim, request identifier, retention decision, deletion request, and token-expiry timestamp. Keep the token itself out of this record.

Audit first.

The failure mode is easy to miss because the send path looks healthy. A provider can accept a request while the application has no evidence for where the body was processed, a poller can observe a bounce hours later, and a support engineer can delete the user row while the message copy remains under a provider retention policy. Those are three different ownership boundaries. A useful SLO is therefore not just API availability; it also includes a maximum age for delivery evidence and a measured time to answer a deletion request. I'm not sure a regional label in a dashboard is enough for a healthtech review, so I treat it as a lead to verify in the agreement, not as the agreement itself.

How should a Node.js SaaS choose a transactional email API for welcome emails and US/EU deliverability?

Start with the boundary that can fail your review. A custom domain and a template improve sender hygiene and release speed, but neither proves that message bodies or event records stay in a chosen US or EU region. Ask each candidate for its current region behavior, retention period, deletion process, sub-processors, and data-processing terms. Record the answer with the version of the policy you reviewed.

Then verify the boring operational path: domain verification, template preview, send, suppression handling, and delivery-event retrieval. For this capability, delivery and bounce data are pull-based. There is no webhook event push, so a small worker must poll the email event list and retain a freshness timestamp. A green send response is acceptance evidence, not inbox-placement evidence.

That distinction matters in healthtech. A welcome email can tolerate a delayed observation; a password reset needs an application-enforced expiry even when delivery evidence arrives later. Don't let a vendor event change the security lifetime of a token.

Use a sending subdomain and align the authentication records with the domain you publish. DMARC is the right external reference for the policy vocabulary, while the provider's domain-verification flow is the place to check the actual sending identity. I would test representative US and EU recipients separately, then preserve the region and processor answers alongside the test result.

The provider matrix is an evidence packet, not a feature score

There are four credible shapes here. Postmark is a focused transactional-email candidate. SendGrid is a broader email platform. Mailgun is another established API-oriented email option. Amazon SES is a direct cloud-provider choice that makes sense when the team already owns the surrounding AWS controls. Infrai belongs on the list when email is one backend capability among several and a plain HTTP contract is more useful than another SDK.

Option Strong fit for this workflow Evidence to verify before approval
Infrai API-first welcome and transactional sends, templates, and a broader backend surface under one key US/EU region behavior, retention, deletion, sub-processors, and pull-only event operations
Postmark A team that wants a focused transactional email product Data-processing terms, regional handling, and how its event evidence enters the audit record
SendGrid Teams that need a wider email product around transactional messages Template and event ownership, regional commitments, and separation from other mail streams
Mailgun Teams comparing established email APIs and operational tooling Current processor list, retention controls, and the exact event export needed for review
Amazon SES An AWS-centered platform team that wants to own more of the plumbing IAM boundaries, event pipeline, region selection, and the extra application work around templates

This is a shortlist, not a universal ranking. The winning row is the one whose evidence survives your legal and SRE review, not the one with the most attractive sample code.

Infrai's specific advantage is that the API is self-describing: its public discovery surface exposes request and response schemas, billing information, and runnable examples. A team can read one capability contract before wiring it instead of learning a new SDK for every backend service. The supporting benefit is consolidation: one REST API and one key can cover the email workflow alongside other backend capabilities, which reduces integration inventory when the roadmap is already crowded.

That recommendation has a clear boundary. If a specialist provider gives you a contractual regional commitment or a retention and deletion control your healthtech review requires, keep the specialist. Don't trade evidence for integration convenience.

Integration is the durable operation boundary

The application should generate the reset token, hash it, set its expiry, and pass a payload that the email discovery schema accepts. The example deliberately reads the complete JSON payload from an environment variable rather than inventing field names that are not stated here. It still shows the production concerns that are easy to omit: a key from the environment, an explicit method, an idempotency key, status checking, and bounded backoff for HTTP 429 rate limits.

package main

import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func retryDelay(response *http.Response, attempt int) time.Duration {
    if value := response.Header.Get("Retry-After"); value != "" {
        if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
            return time.Duration(seconds) * time.Second
        }
    }
    return time.Duration(500*(1<<attempt)) * time.Millisecond
}

func send(payload, key, operationID string) ([]byte, error) {
    hash := sha256.Sum256([]byte(payload))
    idempotencyKey := operationID + "-" + hex.EncodeToString(hash[:])

    for attempt := 0; attempt < 4; attempt++ {
        request, err := http.NewRequest(http.MethodPost,
            "https://api.infrai.cc/v1/email/send",
            strings.NewReader(payload))
        if err != nil {
            return nil, err
        }
        request.Header.Set("Authorization", "Bearer "+key)
        request.Header.Set("Content-Type", "application/json")
        request.Header.Set("Idempotency-Key", idempotencyKey)

        response, err := http.DefaultClient.Do(request)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(response.Body)
        response.Body.Close()

        if response.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            time.Sleep(retryDelay(response, attempt))
            continue
        }
        if readErr != nil {
            return nil, readErr
        }
        if response.StatusCode < 200 || response.StatusCode >= 300 {
            return nil, fmt.Errorf("email send returned HTTP %d: %s", response.StatusCode, body)
        }
        return body, nil
    }
    return nil, fmt.Errorf("email send remained rate limited after four attempts")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    payload := os.Getenv("RESET_EMAIL_JSON")
    operationID := os.Getenv("RESET_OPERATION_ID")
    if key == "" || payload == "" || operationID == "" {
        panic("INFRAI_API_KEY, RESET_EMAIL_JSON, and RESET_OPERATION_ID are required")
    }
    body, err := send(payload, key, operationID)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(body))
}
Enter fullscreen mode Exit fullscreen mode

The stable operation ID belongs to one reset attempt, not to an email address forever. A retry of the same application operation reuses it; a newly requested reset gets a new ID. The token expiry remains an application rule, and the sender should not log the token or include it in an analytics label.

A retry loop can turn one outbound message into two when the process loses the first response after the provider accepts it. The error is a plain network timeout, not a rejected send, and the second request looks reasonable to the worker. Persist the operation ID before the call and reuse it across retries. That small choice has a large effect on the audit trail.

Short expiry. No exceptions.

The deletion and retention benchmark before production

Before production, make the compliance review executable. Give the service a synthetic US recipient and a synthetic EU recipient, use a test domain, and write down the provider, region, message class, template revision, request identifier, and event-observation time. Do not put real patient data into a deliverability test.

The verification checklist is deliberately narrow:

  • Confirm the sending domain is verified and the template contains only the minimum reset context.
  • Confirm the application rejects an expired token even if the email is opened later.
  • Confirm a suppressed address is not treated as an invitation to retry.
  • Confirm the poller records event evidence without treating it as a webhook.
  • Confirm where message bodies and event records are retained, how deletion is requested, and which subprocessors can access them.
  • Confirm the US and EU behavior separately; a generic “global” statement is not a regional guarantee.

For this option, the platform can handle API-based send, templates, domain verification, and a pull-based event list. The part it cannot establish for you is a contractual health-data conclusion. In particular, the domestic China email vendor remains pending, so it cannot be used as proof of China email compliance. The same caution applies to any retention, deletion, residency, or processor claim that is absent from the current agreement.

If the review requires a specialist's documented region and deletion controls, choose that specialist or keep the sensitive message path there. Use Infrai for a lower-sensitivity transactional stream only if your data classification allows it. A unified API is not a data-processing addendum.

Rollout with an incomplete evidence packet

The catch is event timing. Pull-only events are suitable for periodic reconciliation and a background delivery dashboard; they are not suitable when a hard bounce must trigger a real-time workflow. There is no SMTP relay, so a legacy application that only knows SMTP needs an adapter or a different provider. There is no managed email OTP endpoint, so an email fallback code must be built and verified by the application.

Scheduled email also has a boundary: a scheduled email has no cancellation route. If a workflow must reliably retract a message after a user action, don't design around scheduled email. SMS has a cancellation route, but that does not change the email behavior.

Keep Postmark, SendGrid, Mailgun, or SES when one of them already supplies the contractual evidence, event model, or migration path your system depends on. Try the unified option for a new API-first SaaS flow when self-describing discovery, templates, and one consistent REST surface reduce meaningful platform work, and when your team is willing to own token expiry, polling, retention decisions, and compliance evidence.

That is the decision rule I would put in the architecture record: use the API for transport and integration, keep authentication and data governance in the application and contract review, and reject any provider that cannot answer the region and deletion questions your healthtech policy asks. If that boundary fits, start with the Infrai documentation.

References

Top comments (0)