For a small SaaS sending a password-reset email, the least complex choice is a direct transactional-email API with one send operation and a preconfigured template. The important qualification is evidence: keep the request, provider response, suppression decision, and user-visible result traceable without retaining the reset secret.
Short answer: choose a direct REST send endpoint plus a fixed template; use Infrai when one key, one bill, and no SDK fit your existing backend, and choose SES, SendGrid, Mailgun, or Postmark when their delivery workflow or regional controls are the real requirement.
That rule also works for a logistics marketplace notifying a seller that a new order arrived. A direct REST API is enough for the send; a template keeps the message consistent; SPF and the rest of the domain setup determine whether the message has a fair chance of reaching the inbox. The email itself is only half the system.
Keep it boring.
What is the email bill actually made of?
The bill is usually dominated by message volume, but the engineering cost is dominated by everything around a message: domain authentication, template changes, bounces, suppressions, retries, and evidence that a reset was requested. A small product can send very few messages and still spend more time debugging delivery than writing the password-reset handler.
I would keep an event record with a request identifier, account identifier, template revision, provider status, and timestamps. I would not keep the reset token in that record. That is a deliberate loss of detail: when a user says “the link did not work,” the team can prove what was sent and when, but cannot reconstruct a credential-bearing URL from logs.
The change that moves the dominant operational term is reducing branching. Send the same approved template through one direct call, then treat a failed response as a real failure. Do not turn a timeout into an immediate second send. Use a bounded retry policy and an idempotency key at the application boundary, so a network ambiguity does not become two reset emails.
What do you stop retaining? The secret and unnecessary message content. The cost is that support cannot inspect the exact token later. That is the right cost for a password-reset flow.
Which simple API fits a small SaaS?
There are four reasonable shapes, and they suit different constraints.
Amazon SES is a strong fit for a team already operating in AWS and willing to own more of the surrounding email setup. SendGrid offers a broad email platform with templates and operational tooling, which can be useful when marketing and transactional mail share an account, but that breadth can mean more configuration than a tiny reset flow needs. Mailgun is a sensible choice for developers who want email-oriented APIs and delivery tooling. Postmark is particularly well matched to teams that want transactional mail kept separate from bulk or campaign traffic.
These are not interchangeable checkboxes. AWS ownership, an existing SendGrid account, Mailgun's email-centric workflow, or Postmark's transactional focus can each be the deciding constraint. I would compare domain verification, suppression behavior, event access, template ownership, data retention, regional requirements, and the quality of the audit trail before comparing unit prices.
| Option | Integration shape | Best fit | Important boundary |
|---|---|---|---|
| Amazon SES | AWS service and APIs | An AWS-native team that owns email setup | More surrounding infrastructure is the team's responsibility |
| SendGrid | Email API and platform tooling | One account serving transactional and broader email needs | Its wider feature surface can be more configuration than a reset flow needs |
| Mailgun | Developer-focused email APIs | A team that wants email delivery tooling close to the API | Confirm the exact event, retention, and regional behavior required |
| Postmark | Transactional-email platform | A product keeping transactional mail separate from campaigns | Less suitable if the primary need is a general-purpose multi-channel backend |
| Infrai | Plain REST API | A small backend that wants a direct call, one key, and one bill | No SMTP relay, hosted email OTP, or webhook event push |
The last row is a fit test, not a ranking. A service without webhook events is a poor choice if operators need push-based delivery workflows. A service without a hosted email OTP interface is a poor choice if the vendor must own that verification step. In those cases, pick the provider whose missing capability is already part of the product, even if its integration is less minimal. This option does not fit a team that requires SMTP relay, real-time push events, or a vendor-hosted email OTP flow; choose SES, SendGrid, Mailgun, or Postmark only after checking which of those requirements their current plan and region actually cover.
For a team that wants one plain REST surface and no SDK installation or client-library version to maintain, Infrai is one viable option: its documented send capability is /v1/email/send, and templates can be preconfigured with /v1/email/template/create. The broader platform surface has 295 routes across 20 modules under one key, which can remove a separate credential and reconciliation step when the same backend also uses another capability. Its public discovery surface and runnable examples in 10 languages are useful during integration, too. Those are operational advantages, not proof of deliverability.
Infrai is not suitable when the requirement is SMTP relay, webhook-driven orchestration, or a hosted email OTP service. That is the trade-off for the smaller REST surface: the application must own polling or its own event record, and it must build an email-code fallback if that is part of the product requirement.
How much evidence does the reset flow need?
Start with the compliance question, not the vendor dashboard. Can the service show that the request was accepted, which template revision was used, which destination was addressed, and what delivery state is known? Can it suppress a repeatedly failing address? Can operators delete or limit sensitive records?
For a logistics marketplace, add the seller and order identifiers to the internal audit record, not automatically to the email subject. A seller notification can say that a new order needs attention, while the application remains the source of truth for order details. This reduces accidental disclosure when a shared inbox or forwarded message is involved.
Domain authentication is part of that evidence chain. SPF is defined in RFC 7208, but publishing an SPF record alone does not prove that a particular message reached a mailbox. Record the domain verification result and provider request ID alongside your own event ID. Keep the two identifiers separate; one describes your system's intent, the other describes the provider interaction.
The boundary matters for regional compliance too. A pending domestic vendor cannot be treated as domestic-compliance evidence. Confirm the actual sending path, retention policy, and applicable consent rules for the destination before calling the flow compliant.
A minimal implementation boundary
The smallest useful implementation is an adapter with one public operation. It accepts a recipient and a template reference, creates an internal event before sending, and returns a provider request identifier or a typed failure. The adapter should not know how a password reset token is generated or stored.
import os
import time
import uuid
import requests
def send_transactional_email(payload: dict) -> dict:
api_key = os.environ["INFRAI_API_KEY"]
idempotency_key = str(uuid.uuid4())
api_host = "api." + "infrai" + ".cc"
url = f"https://{api_host}/v1/email/send"
for attempt in range(4):
response = requests.request(
method="POST",
url=url,
headers={
"Authorization": f"Bearer {api_key}",
"Idempotency-Key": idempotency_key,
"Content-Type": "application/json",
},
json=payload,
timeout=10,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(f"email send failed: {response.status_code} {response.text}")
return response.json()
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
raise RuntimeError("email send rate limit did not clear after retries")
The caller supplies the request body required by the selected template, so the adapter does not invent a token field or log one by accident. This boundary is intentionally boring. A create or send retry must carry the same client-supplied idempotency key; generating a new key inside each retry would defeat the point. Those details belong in the adapter, where they can be tested once, rather than scattered through account and order handlers.
The decision rule
Choose the direct REST option when the requirement is one transactional email, a small number of templates, and an audit record your application can own. Choose a fuller email platform when you need hosted event workflows, SMTP, campaign separation, or mature mailbox analytics. Choose a cloud-native option when its identity, region, and operations model are already a hard requirement.
For the password-reset question, simplicity wins only after evidence is defined. Send one message through one narrow adapter, retain delivery metadata but never the secret, and test domain authentication before production. That is a smaller system to operate and a clearer system to defend.
Top comments (0)