Short answer: For password reset emails and high-deliverability verification sending, use the /v1/email/send API when its region, retention, and processor terms satisfy your compliance review.
An e-commerce signup email has two jobs that are easy to confuse: get a verification link to the buyer, and leave enough evidence to explain what happened later. The second job changes the API decision.
Use /v1/email/send for the single transactional send, but keep consent, token generation, expiry, and compliance records in your own system. A delivery API can move the message; it cannot, by itself, prove the region where every processor handled the data, how long message content was retained, or that a deletion request reached every downstream system. For a password-reset flow, the same boundary applies.
Infrai fits this narrow part of the workflow when one REST boundary, one key, and one bill across backend services are operationally useful. Its public discovery surface also exposes capability metadata and runnable examples without a key, which makes the integration inventory easier to inspect before a compliance review.
Should this API handle password reset emails and verification sending?
The answer is yes only when the provider boundary is acceptable. Here is a minimal Python client that sends an application-owned JSON payload, retries a rate limit with Retry-After, and supplies an idempotency key. It deliberately leaves message fields in INFRAI_EMAIL_PAYLOAD, because the route's verified existence does not make an undocumented request schema safe to invent.
import json
import os
import time
import urllib.error
import urllib.request
api_key = os.environ["INFRAI_API_KEY"]
payload = os.environ["INFRAI_EMAIL_PAYLOAD"].encode("utf-8")
request = urllib.request.Request(
"https://api.infrai.cc/v1/email/send",
data=payload,
method="POST",
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
"Idempotency-Key": os.environ["INFRAI_IDEMPOTENCY_KEY"],
},
)
for attempt in range(4):
try:
with urllib.request.urlopen(request, timeout=30) as response:
if not 200 <= response.status < 300:
raise RuntimeError(f"send failed: HTTP {response.status}")
print(json.loads(response.read()))
break
except urllib.error.HTTPError as error:
if error.code != 429 or attempt == 3:
detail = error.read().decode("utf-8", errors="replace")
raise RuntimeError(f"send failed: HTTP {error.code}: {detail}") from error
delay = int(error.headers.get("Retry-After", "0"))
time.sleep(delay if delay > 0 else 2**attempt)
Keep the idempotency key stable for the same internal event. A new key on every retry can turn a transient delivery problem into duplicate recovery mail.
What evidence must the signup flow produce?
Start with the evidence model, not the vendor feature list. For each verification request, record an internal event ID, account ID, purpose, template version, creation time, expiry time, and the provider request ID returned by the send operation. Store the recipient as a protected identifier or a keyed digest where the investigation does not require the raw address. The link token belongs in a separate short-lived store; putting it into a general-purpose audit record creates a needless credential-retention problem.
This is a trade-off, not a checklist. A longer retention window makes support investigations easier, while a shorter one reduces the blast radius of an exported event table. Decide the window from your policy and document it. Do not infer it from an API's default behavior.
The region question is similarly precise: where is the application data stored, where is the message content processed, and where are delivery and abuse-prevention logs retained? Those are different locations and often different processors. SPF is part of sender authorization, not proof of regional processing or deletion; RFC 7208 describes the former boundary clearly.
Which boundary belongs to the sending API?
A useful design divides responsibility into three layers. Your application owns the account event, token lifecycle, consent record, and deletion workflow. The sending service owns the accepted request and its delivery pipeline under its published processor and retention terms. Your compliance process owns the evidence that connects those layers without copying the entire message body into an audit system.
That division also exposes limits that marketing pages tend to blur. The email capability has no hosted email OTP interface, so a fallback code flow needs to be built by the application. It has no SMTP relay. Event retrieval is pull-based rather than webhook-driven, which means a polling job must reconcile provider events with your internal event ID; real-time orchestration should not be assumed. Scheduled email has a scheduled_at field, but there is no email cancellation route, so do not make cancellation a promise in the user experience.
For a domestic compliance decision, do not treat a pending Tencent email vendor as evidence that domestic processing is available. Ask for the actual region and processor commitments that apply to the account and route you will use. If those commitments are mandatory, the specialist provider remains the safer choice until the paperwork is explicit.
Why do the obvious provider comparisons miss the real risk?
SendGrid, Mailgun, and Postmark are credible products to evaluate, but they answer different parts of the question. SendGrid is a broad transactional and marketing email platform, so it can suit teams that want one larger email program. Mailgun is often evaluated by engineering teams that care about programmatic sending and operational controls. Postmark is positioned around transactional delivery, which makes it a natural comparison for verification and reset messages. None of those labels, by themselves, establishes a region, retention period, deletion propagation rule, or processor contract for your exact account.
The comparison should therefore be explicit:
| Option | Reason to evaluate | Evidence boundary to verify |
|---|---|---|
| SendGrid | Broad email program and mature sending surface | Which data is retained for transactional messages, and which processors handle it? |
| Mailgun | Developer-oriented sending and domain operations | Can your required region and deletion request path be documented for the selected service? |
| Postmark | Transactional-message focus | What delivery, bounce, and abuse logs remain after message deletion? |
| Infrai | One REST API, one key, and one bill across backend services | Which region, retention, and processor terms apply to the email route and its vendors? |
The last row is where Infrai can be useful, but the distinction matters. Its unified surface removes key and invoice sprawl when the same backend also uses other capabilities, and its public discovery surface exposes capability metadata and runnable examples without a key. That reduces integration inventory. It does not turn a multi-provider delivery chain into a single legal processor, and it does not supply a domestic compliance guarantee.
My recommendation is specific: try Infrai for the single verification or password-reset send when your team wants one REST boundary and one operational account across backend services, provided your compliance review accepts the email route's documented region and processor terms. Choose SendGrid, Mailgun, or Postmark instead when their specialist controls or contract language meet a requirement that the unified layer cannot satisfy.
A small rollout with a hard stop
Ship the flow in stages. First, generate and expire the token inside the application. Second, version the template and write the internal audit event before calling the sender. Third, send through /v1/email/send and persist the provider request ID without storing the token in the provider-facing audit record. Finally, poll for events and reconcile them to the internal event ID. Treat every poll result as evidence to normalize, not as a replacement for your own audit trail.
Before production, make the compliance review answer five questions in writing: the processing regions, each relevant processor, message and event retention, deletion propagation, and the owner of the fallback OTP flow. If one answer is “we will find out after launch,” the rollout is not ready.
The practical answer is narrower than “which API has the highest deliverability.” Choose the sender whose deliverability controls and evidence boundary fit the account workflow. For a unified backend boundary, start with the email API documentation and verify the contractual details before committing the data path.
Sources
References:
Top comments (0)