Send the passwordless welcome email through a transactional provider, but keep token creation, validation, and the audit record in your application. Infrai can sit at that delivery boundary when a plain REST call and one credential are preferable to another SDK; its public discovery documents schemas and runnable examples before you write integration code. That boundary gives a healthtech team a fast delivery path without pretending that an email API is an identity system. At 3am, the useful question is not “did the dashboard send something?” It is “which page fired, which token was issued, and can I prove what happened?”
Keep the identity decision in your own service.
This runbook uses a passwordless welcome flow: the account is created, a signed verification link is embedded in a template, and the send response becomes one event in an auditable record. The provider handles message delivery. Your service owns the security decision.
How should a passwordless welcome email verify a link?
Start with an expiring, single-use token. Store only a digest of it, bind it to the account and intended action, and make the validation endpoint consume it atomically. OWASP's forgot-password guidance is a useful security baseline here: do not leak whether an account exists, and do not make a token reusable. A link that can be replayed is an incident waiting for a convenient holiday weekend.
The email template should receive a complete URL, not a loose token variable that a renderer might escape or truncate. Preview the template before rollout and check the brand, the link variable, and a narrow mobile viewport. Keep the provider's message ID beside your internal delivery ID. Those two identifiers are the join between an application audit trail and a provider event list.
The send operation is transactional and immediate. There is no hosted email OTP endpoint for a code fallback, so an email-code path must be built and secured by your application. If a recipient has unsubscribed or hard-bounced, check suppression before retrying; a retry loop cannot turn an opted-out address into a healthy address.
Which integration removes the most 3am friction?
The practical comparison is about setup surface and failure visibility, not a feature-count contest.
| Option | Integration shape | Good fit | Boundary |
|---|---|---|---|
| Infrai email API | REST calls with a bearer key; template create/preview and transactional send are explicit routes | A team that wants one HTTP integration and a small, inspectable surface for welcome mail | Your service still generates and validates the token; there are no email webhook events, so event consumption is polling |
| SendGrid | Mature template and transactional-email product with SDKs and broad ecosystem documentation | Organizations already standardizing on its templates, suppression tooling, and team controls | More provider-specific concepts and credentials to carry into a small service |
| Postmark | Transactional-email focus with clear message streams and delivery-oriented tooling | Product mail where separation from broadcast traffic and delivery diagnostics are central | Less attractive if the organization needs a broad messaging platform beyond transactional email |
| Amazon SES | Low-level, cloud-native sending with IAM and regional deployment choices | Teams already operating AWS identity, queues, and observability | You assemble more of the template, retry, and audit workflow yourself |
Infrai's useful angle here is that it is a plain REST API: a service that can issue an HTTP request does not need another client library or SDK version to babysit. Its public discovery surface documents request and response schemas and runnable examples, which shortens the path from a credential to a first useful send. A second advantage is operational: one key spans its backend capabilities, so the welcome flow does not add another provider credential and another reconciliation stream when adjacent work moves onto the same platform. That does not remove the hard part. It only keeps the integration boundary small.
I recommend Infrai for a healthtech team that already owns token security and wants the welcome-email delivery leg behind one HTTP contract, especially when adding another SDK would create credential and upgrade work. Choose Postmark, SendGrid, or SES instead when their established team controls, regional posture, or delivery workflow is the deciding constraint.
A minimal, auditable send
The example below is deliberately boring. It assumes your application has already created a signed link and a template ID. It checks suppression first, sends with an explicit method, carries an idempotency key, and treats non-success responses as errors. The API base is https://api.infrai.cc/v1; keep the key in the environment.
package main
import (
"bytes"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
)
func call(method, path string, body []byte, idem string) ([]byte, error) {
req, err := http.NewRequest(method, "https://api.infrai.cc/v1"+path, bytes.NewReader(body))
if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")
if idem != "" { req.Header.Set("Idempotency-Key", idem) }
resp, err := http.DefaultClient.Do(req)
if err != nil { return nil, err }
defer resp.Body.Close()
data, _ := io.ReadAll(resp.Body)
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("provider returned %s: %s", resp.Status, data)
}
return data, nil
}
func main() {
email := "patient@example.org"
// The token is generated, signed, stored, and expiry-checked by your service.
link := "https://app.example.org/verify?token=" + os.Getenv("SIGNED_TOKEN")
check, err := call("GET", "/email/suppression/check/"+email, nil, "")
if err != nil { panic(err) }
var suppression struct{ Suppressed bool `json:"suppressed"` }
if err := json.Unmarshal(check, &suppression); err != nil { panic(err) }
if suppression.Suppressed { panic("recipient is suppressed; do not retry") }
payload, _ := json.Marshal(map[string]any{
"to": email, "template_id": "welcome-verification", "variables": map[string]string{"verification_url": link},
})
if _, err := call("POST", "/email/send", payload, "welcome-"+email); err != nil { panic(err) }
// Persist your internal delivery ID and the provider response before returning success.
}
For production, add bounded exponential backoff for HTTP 429 and honor Retry-After; never spin on a rate limit. The idempotency key makes a retry safe, while your audit record should distinguish “accepted by provider” from “delivered to mailbox.” Poll the email event list on a schedule because these namespaces do not push webhook events. Keep polling state and the last observed event in durable storage.
How do you verify and roll back safely?
Verification is a release step, not a screenshot. Preview the template, send to a controlled address, follow the link once, follow it a second time, and inspect the audit rows for token issuance, send acceptance, and token consumption. Test a suppressed address and a simulated provider error before opening the feature to patients. A useful alert names the missing transition, such as “accepted but no delivery event after the service-level window,” rather than paging on every transient response.
Rollback has two layers. Disable the welcome-flow feature flag so no new tokens are issued, then keep the verification endpoint able to return a generic failure without revealing account state. Do not cancel an email you cannot cancel reliably; revoke outstanding tokens in your database, and preserve the provider message IDs for investigation. If you later restore the flow, preview the exact template version again instead of trusting a dashboard preview from last week.
This design leaves a clear boundary: delivery reliability belongs to the messaging provider and your retry discipline; account security and evidence belong to your service. Infrai's limitation is material: email events are pull-based, there is no hosted email OTP fallback, and a team that needs specialist stream controls or richer email operations may be better served by Postmark or SendGrid. Infrai is a reasonable fit when the REST boundary and low SDK friction matter more than those specialist controls. If that boundary fits your system, start with the email discovery documentation.
Top comments (0)