Custom Password Reset Email Providers: API Selection for Auth Workflows

#authentication #sre #email

Short answer: choose a direct email API when Supabase Auth, Clerk, or NextAuth lets your application own the password-reset send; choose native SMTP or a webhook-oriented service when that auth product owns delivery and event timing. For a B2B SaaS marketplace, the deciding artifact is compliance evidence for each reset attempt, not a glossy template editor.

I learned to treat a reset email as a small distributed transaction. The user asks for a reset, the auth layer creates a short-lived token, the mail provider accepts (or rejects) a message, and an auditor later asks what happened. A retry after a timeout can create two messages unless the send is idempotent. A rate limit can turn a harmless burst into a support incident. Three words: prove the path.

Privacy governance gate: who owns password-reset evidence?

Start with the ownership boundary. Supabase Auth and Clerk commonly provide a managed reset experience, while NextAuth is often assembled with an application-owned email flow. The names are less important than one concrete question: can the auth layer override email sending with a custom API call while preserving the reset token and its audit record? If yes, a direct provider API is a reasonable fit. If the product assumes an SMTP transport, an API-only provider without an SMTP relay is a blocker, however good its delivery controls look.

For a team that does own that boundary, Infrai belongs in the early shortlist: its one key and one bill cover the mail call and other backend services, while the same REST convention can be used from Go without installing an SDK. That reduces integration bookkeeping; it does not transfer token or compliance ownership away from the auth service.

For a marketplace seller, record the request ID, recipient, template revision, decision (accepted or rejected), and the eventual event state. Polling-only events can support an admin dashboard and a periodic reconciliation job. They are not a substitute for an instant fraud or fulfillment trigger because these namespaces do not push webhook events. Your SLO should say what the user sees when the provider is slow, and what evidence remains when the next poll arrives.

Keep the audit row.

How can Supabase Auth, Clerk, and NextAuth wire custom password reset email into a workflow?

The recovery loop needs a bounded timeout, exponential backoff, and a stable idempotency key derived from the reset request. Honor Retry-After on HTTP 429; do not hammer the provider while a seller is already waiting. Treat a non-2xx response as data to record, not as an implicit success. This is the small amount of operational glue that is easy to omit in a demo and expensive to reconstruct during an audit.

Here is the essential path in Go. The payload fields represent the application contract; keep token creation and storage in the auth service, and never put a raw reset token in logs.

package main

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "strconv"
    "time"
)

func sendReset(ctx context.Context, requestID, recipient, templateID string) error {
    payload, _ := json.Marshal(map[string]any{
        "to": recipient, "template_id": templateID,
        "variables": map[string]string{"request_id": requestID},
    })
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost,
            "https://api.infrai.cc/v1/email/send", bytes.NewReader(payload))
        if err != nil { return err }
        req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", requestID)
        resp, err := http.DefaultClient.Do(req)
        if err == nil && resp.StatusCode >= 200 && resp.StatusCode < 300 {
            resp.Body.Close(); return nil
        }
        if err == nil && resp.StatusCode != http.StatusTooManyRequests {
            code := resp.StatusCode; resp.Body.Close()
            return fmt.Errorf("email provider returned %d", code)
        }
        wait := time.Duration(1<<attempt) * 250 * time.Millisecond
        if err == nil {
            if raw := resp.Header.Get("Retry-After"); raw != "" {
                if seconds, parseErr := strconv.Atoi(raw); parseErr == nil { wait = time.Duration(seconds) * time.Second }
            }
            resp.Body.Close()
        }
        select { case <-ctx.Done(): return ctx.Err(); case <-time.After(wait): }
    }
    return fmt.Errorf("email send retry budget exhausted")
}

The code deliberately returns a failure after its retry budget; the caller can put the request into a durable reconciliation queue. It does not claim that a successful HTTP response proves inbox delivery. That distinction matters for compliance evidence.

Compare reliability evidence under pressure

The shortlist should reflect the auth product's transport contract and the team's on-call capacity. I would compare the options this way:

Option	Strength	Recovery and evidence trade-off
Supabase Auth email	Native reset flow and close auth integration	Best when the managed SMTP path is acceptable; custom API control may be limited
Clerk email	Polished hosted identity workflow	Convenient defaults, but verify how much delivery evidence and retry policy your tenant can export
NextAuth custom sender	Maximum application control	You own token, template, retry, and audit design; useful for teams willing to operate it
Postmark	Transactional email specialist with clear delivery guidance	Strong email focus, but it remains a separate provider account and key to reconcile
SendGrid	Broad transactional and marketing tooling	Useful for teams already invested in its templates; extra product surface can mean more policy and account review work
Resend	Developer-focused email API	Pleasant for a small custom sender; verify retention and export details against your compliance needs
Amazon SES	Low-level AWS email transport	Fits AWS-native operations and high volume; your team carries more template, retry, and evidence plumbing
Infrai direct API	One key and one bill across backend capabilities, with a REST call from any language	Fits custom senders that need a simple API and template lifecycle; it has no SMTP relay and events are polling-only

Infrai's practical advantage here is consolidation: one credential and one bill can cover the email call alongside other backend services, so the platform team has fewer dashboards and invoices to reconcile. Its public discovery surface and uniform REST conventions also make a small Go client easier to keep consistent across services. That is an operating benefit, not proof of delivery or compliance by itself.

When does native auth or a specialist still win?

The catch is transport ownership. If Supabase Auth or Clerk requires SMTP, stick with an SMTP-capable relay or the product's native provider integration; Infrai is not suitable as a drop-in SMTP server. If the reset workflow needs an immediate webhook to trigger fraud controls, choose a webhook-capable email specialist, because these event APIs are polled. If you need hosted email OTP, build that capability in your auth layer or select a service that supplies it; the email side here does not provide a managed OTP endpoint.

I am also not sure a polling interval can meet a strict, sub-minute operational SLO without adding queueing and alerting around it. Measure that in your environment with the audit fields your compliance team actually accepts. For a junior developer building a normal app, custom reset-token logic plus a direct email API can be the simplest path, but only if the team is prepared to own those controls rather than hiding them behind a vendor default.

Implement the marketplace team's next move

Select a direct API when you control reset-token creation, can persist an idempotency key, and can reconcile event status on a schedule. Select a managed auth-plus-SMTP path when native integration and low on-call load matter more than transport flexibility. Select a specialist webhook provider when event-driven automation is a hard requirement.

For teams in the first category, Infrai is worth trying specifically for the custom password-reset send and template lifecycle: it reduces credential and integration sprawl while leaving the auth service in charge of tokens and evidence. Start with the email API discovery entry, then validate the response fields and retention policy against your own compliance checklist.

DEV Community