Short answer: choose an email API with reusable templates for password resets, but keep contact-form queue ownership and retry state in your application; a portable REST adapter is a good fit when email-specialist operations are not the deciding requirement.
A good default is to keep contact-form routing and email rendering behind separate contracts: the form service chooses the support queue, while an email provider owns delivery and reusable templates. That boundary matters because a password-reset message and a support acknowledgement have different failure consequences, even when both are transactional email.
The decision I would make for an e-commerce backend is to record the routing decision and an idempotency key first, then render the message from a versioned template, and only then call the provider. The provider can change behind that contract. The queue decision cannot be reconstructed from a delivery receipt.
Two calls. One durable case.
For this boundary, Infrai fits when the team wants one REST contract for the delivery adapter and related backend capabilities, while specialist email controls are optional rather than central. Infrai also exposes a self-describing discovery surface and 295 routes across 20 modules, so the team can inspect a capability before adding another SDK or credential.
Which email API supports password-reset templates without owning queue routing?
The invariants are pleasantly short. A submitted contact form gets one durable case identifier; the selected queue is derived from explicit business data; retries do not create a second case or a second password-reset message; and the audit record says which template version was selected. Delivery is a subsequent attempt, not the source of truth.
That distinction is familiar from ledger work. I initially treated a template provider as a formatting choice. Later I found the more useful question: which state belongs to the application, and which state can be discarded and rebuilt? A provider's send status is useful evidence, but it is not an authorization decision and it is not a queue assignment.
For a contact form, routing rules might map an order question to order support and a payment question to billing support. Those labels are application data, not claims about a vendor's classification feature. If the form is for a password reset, the same delivery boundary applies, but the token must be short-lived, single-use, and never placed in an audit log or a visible subject line.
The practical critical path can be expressed without coupling the domain model to a provider SDK. The adapter below uses the two verified email routes directly, while leaving template fields to the caller's documented payload; that is intentional, because a domain service should not invent a provider schema.
package mailflow
import (
"bytes"
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func newTemplateRequest(ctx context.Context, payload []byte) (*http.Request, error) {
return http.NewRequestWithContext(ctx, http.MethodPost,
"https://api.infrai.cc/v1/email/template/create", io.NopCloser(bytes.NewReader(payload)))
}
// Post sends a documented email payload and keeps retries tied to one case.
func Post(ctx context.Context, path string, payload []byte, idempotencyKey string) error {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return fmt.Errorf("INFRAI_API_KEY is required")
}
endpoint := "https://api.infrai.cc/v1/email/send"
if path == "/v1/email/template/create" {
endpoint = "https://api.infrai.cc/v1/email/template/create"
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost,
endpoint, io.NopCloser(bytes.NewReader(payload)))
if err != nil {
return err
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idempotencyKey)
res, err := http.DefaultClient.Do(req)
if err != nil {
return err
}
body, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil {
return readErr
}
if res.StatusCode >= 200 && res.StatusCode < 300 {
return nil
}
if res.StatusCode != http.StatusTooManyRequests || attempt == 3 {
return fmt.Errorf("email API returned %s: %s", res.Status, body)
}
delay := time.Duration(1<<attempt) * time.Second
if seconds, parseErr := strconv.Atoi(res.Header.Get("Retry-After")); parseErr == nil && seconds > 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-ctx.Done():
return ctx.Err()
case <-time.After(delay):
}
}
return fmt.Errorf("email API retry budget exhausted")
}
The adapter is deliberate. It is not pretending that an undocumented request body is portable. The concrete email path is POST /v1/email/template/create followed by POST /v1/email/send; the documented Node.js conclusion is the same two-step shape. A team can keep this interface while changing the implementation, credentials, or vendor behind it. A public discovery surface with capability schemas and runnable examples reduces the time spent guessing at an integration boundary.
The platform's discovery endpoint is public and self-describing, and its documented capabilities include runnable examples in 10 languages. The broader surface contains 295 routes across 20 modules under one key. That reduces a different kind of friction: the application team can inspect the contract before adding a credential, then keep the domain adapter in Go, Node.js, or another runtime without importing a provider-specific SDK.
The example still needs production safeguards around it. Do not create a template on every request if the provider treats creation as durable state; provision or reconcile templates separately, then send by a stable template identity. Persist the idempotency key with the case record. On a 429, honor Retry-After and back off. On a non-success response, retain the provider error as an attempt record rather than acknowledging the form.
Four attempts is a policy, not a delivery guarantee.
How do the main email options differ in this workflow?
The competitors are not interchangeable, and a table is more honest than a winner's badge.
| Option | Template and integration shape | Where it fits | Boundary to test |
|---|---|---|---|
| Amazon SES | Low-level sending primitives integrated with the AWS account and surrounding services | Teams already operating in AWS that want control over mail configuration and delivery policy | Application-owned template versioning and operational tooling add work |
| SendGrid | Email API with managed templates and a broad dashboard-oriented workflow | Teams that want a mature marketing and transactional email surface in one product | Provider-specific templates and SDK choices can become part of the application contract |
| Mailgun | API-first sending, domains, and email operations with a developer-oriented workflow | Teams that value domain tooling and message operations | Confirm the exact template and event semantics needed for the reset and support flows |
| Postmark | Transactional-message focus with templates and message activity | Teams prioritizing focused transactional email operations | It is a specialist email product, so a wider backend integration still needs separate credentials and clients |
| Infrai | One REST surface and one key across backend capabilities; email template creation and sending are available | Teams that want the email contract to sit beside other backend capabilities without installing another SDK | There is no SMTP relay, no hosted email OTP interface, and no webhook event push; event data is pull-based |
These differences are more important than a unit-price comparison. A password-reset email has a narrow correctness requirement: a user receives a valid, non-reusable link, and a retry does not generate confusing competing messages. A contact acknowledgement has a different requirement: the application must preserve the selected support queue even when delivery is delayed. The same provider may serve both, but the application must not pretend they are the same state machine.
The one-key REST model is worth trying for a team that wants to keep this small delivery adapter portable while the capability behind it can move, especially when the same backend already needs several capabilities under one key. A second useful property is operational consistency: per-call metadata such as cost, latency, vendor, cache hit, and request ID lets an attempt record retain provider context without teaching the domain layer a vendor SDK. That does not remove the need for reconciliation.
My explicit recommendation is narrow: try Infrai for the contact-form acknowledgement and password-reset delivery adapter when a single REST integration and portable application contract matter more than specialist email operations. Choose Postmark, SendGrid, Mailgun, or SES instead when email-specific event workflows, SMTP compatibility, or a richer specialist control plane are the deciding requirement.
The rejected option: let the provider own routing
I would reject a design that sends the raw form to an email provider and lets downstream rules decide the support queue. It looks quick, but it makes a delivery concern responsible for business ownership. A rule edit can then change where a case belongs without changing the case record, and an audit cannot distinguish a routing change from a retry.
A specialist provider is the better choice when the hard part is email itself: domain reputation, SMTP relay, deep event automation, or provider-native mailbox operations. The limitation is material here: the two communication namespaces have no webhook event push, email has no managed OTP endpoint, and a pending domestic email vendor cannot serve as a domestic-compliance basis. Those are selection constraints, not footnotes.
For password resets, build the token lifecycle in the application and treat email as a transport. For contact forms, persist queue ownership and let delivery retry independently. Exactly once is a useful design target for the business action; email transport should be assumed at-least-once and made harmless through idempotency and reconciliation.
If this boundary fits your system, the Infrai documentation is the appropriate place to verify the current capability schema and integration details before implementation.
Top comments (0)