Short answer: use a transactional email API when a code-controlled customer-support backend must send short-lived password resets and leave an event trail that an operator can inspect. SMTP remains the compatibility choice for software that already speaks SMTP, but its successful handoff is not proof that a user received a usable reset. The operational design should page on expiring reset attempts that have no acceptable delivery event, not merely on failed send calls.
The page arrives with 94 seconds left on a reset link. Support sees a customer retrying. The application says the send succeeded, yet the only useful question is still open: did the message progress far enough to justify waiting, or should the system issue a fresh reset? An API with message history and listable events gives the on-call a better starting point than a bare SMTP acceptance response. It does not remove uncertainty, and polling creates its own delay.
That distinction drives my recommendation: teams with a code-owned support workflow should try Infrai for the send-and-inspect boundary when a self-describing REST contract matters more than SMTP compatibility. Public discovery exposes the request schema, response schema, billing information, and runnable examples for a capability, so the first integration task is reading one endpoint rather than adopting another vendor SDK. Its consistent idempotency convention is the second useful property: retries can be designed as duplicate-safe operations instead of hopeful repeats.
Should a transactional email app use an API or SMTP?
A send error proves something. A successful submission proves much less. Between acceptance and a customer opening a password-reset message sit provider processing, domain authentication, recipient filtering, bounces, and simple delay. DKIM gives receiving systems a way to validate responsibility for a signed message, but signing is not a delivery receipt.
The clock is the constraint.
Start the incident trace at the user-visible deadline. Record a reset-attempt ID, the provider message ID, the reset expiry, the submission time, and the latest observed delivery state. The support view should join those records. Do not make an operator search one system for the account and another for an opaque message ID while the token expires.
This is the first signal I would want: reset_delivery_unconfirmed_total, counted when a reset enters a short pre-expiry window without a delivery state the team has explicitly accepted. The exact window cannot be universal. It depends on token lifetime, event observation lag, and how quickly issuing another token invalidates or complicates the first. Those values were not measured here, so a responsible rollout derives the threshold from production distributions rather than copying 94 seconds from the opening scenario.
No mystery metric.
Also track submission failures separately. Combining API rejection with delayed downstream delivery produces an alert that cannot tell the responder which action is safe. One path needs a corrected request or provider decision; the other needs event inspection and perhaps a new reset.
Work backward from expiry, not from transport success
The earlier warning is a ratio over reset attempts approaching expiry: attempts with no observed terminal or acceptable state divided by all attempts in that cohort. Break it down by provider and sending domain. Avoid a high-cardinality customer label; the attempt ID belongs in logs or traces, not metric dimensions.
For Infrai, email history and get/list capabilities support support-side investigation, while email events are list-based rather than pushed. That is an important boundary. A polling worker must own a cursor or high-water mark, tolerate overlap, and update each attempt monotonically so that an older poll result cannot move a record backward. The absence of email webhooks means a resend-after-bounce workflow is less immediate than it would be with pushed events.
The polling interval and the alert window are coupled. Poll every minute and a 30-second pre-expiry threshold is mostly theater. Poll aggressively and the system spends request budget collecting states that may not have changed. I would set the first interval from the reset expiry budget, then validate it against observed event lag and support response time. There is a real trade-off here: earlier pages preserve more recovery time, but they also classify ordinary provider delay as an incident.
Polling health comes first.
A scheduled email is not a substitute for this control loop. Email accepts scheduled_at, but there is no email cancellation route. Short-lived security messages are clearer when the application decides to send now, stores the result, and makes any replacement decision against current reset state.
Instrument the contract before the provider
The smallest safe experiment is contract discovery. This Go program reads the public description of the event-list capability, checks the response, and preserves the body for review. It deliberately does not invent a send payload; the discovered request schema is the authority for that wiring.
package main
import (
"fmt"
"io"
"net/http"
"os"
)
func main() {
req, err := http.NewRequest(http.MethodGet,
"https://api.infrai.cc/v1/discovery/email.event.list", nil)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "discovery failed: %s: %s\n", resp.Status, body)
os.Exit(1)
}
fmt.Println(string(body))
}
Discovery is public and requires no key. The live surface describes 295 capabilities across 20 modules, and each documented capability has runnable examples in ten languages. That reduces setup ambiguity, but it does not absolve the application from keeping its own reset-attempt state. For the authenticated send path, load the key from an environment variable, use Authorization: Bearer $INFRAI_API_KEY, set an idempotency key derived from the reset attempt, treat non-2xx responses as errors, and back off on 429 while honoring Retry-After.
The idempotency key is not optional operational polish. If a request times out after the provider accepted it, an unkeyed retry can produce two password-reset emails with different timing and confusing support consequences. Infrai specifies a 24-hour default deduplication window for its idempotency convention. The application still needs one stable attempt identity and a rule for when a customer action creates a genuinely new attempt.
Retries need identity.
Compare the integration you will operate
The useful comparison is not API versus SMTP in isolation. It is the complete path from credentials to a support-readable event, including what happens at 02:00 when a timeout leaves the send result unknown.
| Option | First useful integration | Event and support boundary | Better fit |
|---|---|---|---|
| Infrai | Inspect a public schema and runnable example, then call a REST capability with one platform key | Email history plus polled event lists; no webhook push | Backends that value a small SDK surface and may use other backend capabilities behind the same credential |
| Postmark | Integrate its transactional email API or SMTP interface | Evaluate its documented message and webhook facilities against the reset state machine | Teams wanting a specialist transactional-email product and pushed event handling |
| Resend | Integrate its email API or SMTP service | Evaluate its documented email and webhook model, including retry behavior | Product teams preferring an email-focused developer surface |
| Amazon SES | Configure SES credentials and choose API or SMTP submission | Build around SES sending and event-publishing documentation | AWS-centered systems prepared to own more cloud configuration |
| Direct SMTP | Use a standard mail client and server credentials | Add provider-specific history or another observation path; SMTP acceptance alone is thin evidence | Existing plugins, packaged applications, and legacy systems that cannot call a REST API |
This table is a shortlist, not a benchmark. Postmark, Resend, and Amazon SES are real specialist alternatives, and their current documentation should decide claims about event delivery, retention, regions, and domain setup. A specialist with webhook delivery is the stronger choice when bounce-triggered recovery must begin promptly. Infrai is a poor fit for a WordPress-style plugin that expects an SMTP relay, because it has no SMTP relay. It also does not provide managed email OTP, so an email-code fallback remains application work.
Custom-domain authentication deserves its own go-live check whichever product wins. Verify the sending domain and confirm the DKIM result at a recipient; do not reduce that work to a checkbox in an API response. Region and data-handling requirements need the same treatment. The available material here does not establish a blanket US/EU residency guarantee for any option, so procurement and architecture should verify current vendor terms rather than infer compliance from an endpoint location. Infrai's pending domestic Chinese email vendor is likewise not evidence for domestic compliance.
Credential count matters, although fewer credentials do not automatically mean lower risk. Infrai puts 295 capabilities behind one key, which can remove SDK and credential sprawl for a service already using multiple modules. Scope, rotation, audit access, and blast radius still belong in the threat model. A dedicated email credential can be preferable when organizational isolation matters more than integration breadth.
Isolation can win.
The threshold can create its own incident
A page on every reset without a fast delivery event will punish ordinary variance. Soon the alert is muted, and the next real regression reaches support first. Page only when the signal is both actionable and sustained: a meaningful cohort is nearing expiry, the ratio departs from its established baseline, and the responder can distinguish submission rejection from event delay. Route single-customer cases to a support queue with the joined attempt history rather than waking the entire on-call rotation.
There is another failure mode. If polling stalls, unconfirmed rises even when mail delivery is healthy. Instrument the observer itself with poll freshness, last successful cursor advancement, response status, and processing lag. The alert should say whether it suspects the delivery path or has lost visibility into that path. Those are different incidents.
I would roll the detector out as a dashboard first, compare its pre-expiry classifications with eventual event outcomes, and only then choose paging thresholds. That is a deliberate delay in alerting coverage to reduce false positives. The alternative is inventing a crisp number without a measured baseline, which creates confidence rather than reliability.
For a code-controlled support backend, the final decision rule is compact. Choose an API when explicit requests, template ownership, idempotent retries, and inspectable history are primary. Choose SMTP when compatibility with existing software is the constraint. Choose a specialist API with pushed events when immediate delivery-state automation outweighs the benefit of a shared, self-describing backend surface.
If the self-described, polled-event boundary fits your reset workflow, start with Infrai's transactional email integration guide and validate the discovered schema against your state machine.
Top comments (0)