The constraint that changes this choice is the attachment, not the reset link. A healthtech team sending a generated report alongside account-recovery mail needs a provider it can authenticate, observe, and integrate without treating sensitive report delivery like a disposable notification. Short answer: choose by expected volume and compliance boundary first, then compare AWS SES, SendGrid, Tencent Cloud email services, and a self-describing REST layer against the complete workflow. There is no universal cheapest reliable option.

What makes an email service reliable for password reset workflows?

A password-reset message is small but high-impact. The application should create a short-lived, single-use token, send the minimum useful message, and avoid turning repeated reset requests into an uncontrolled delivery loop. The generated report introduces a separate question: what data is allowed in an attachment, and which recipient decision is recorded before the message leaves the system?

Reliability is a control surface, not a delivery-rate adjective. I would verify domain authentication with DKIM and SPF, event visibility, suppression behavior, rate-limit handling, and the provider's regional and compliance position. SPF is specified in RFC 7208. DKIM verification still has to be configured and checked in the selected provider.

The cheapest label misleads here.

Keep the two jobs separate. The reset worker handles token expiry and account-security messaging. The report worker resolves the recipient, generates the attachment, applies the data-classification rule, and records an audit event before sending. One retry policy should not decide both.

Which integration boundary fits the report workflow?

Option Best fit Boundary to verify
AWS SES AWS-centered teams comfortable owning more of the surrounding workflow Sending limits, production access, identity verification, event collection, and regional requirements
SendGrid Teams that want an email-focused product surface and managed workflow features SDK or API coupling, template ownership, event handling, and regional compliance terms
Tencent Cloud email services Deployments already aligned with a China-region vendor The vendor's compliance status; availability in a region is not legal or security approval
A self-describing REST layer Teams where adding a capability with low discovery effort matters more than adopting another vendor SDK Vendor readiness, attachment handling, event polling, compliance ownership, and missing hosted OTP or SMTP features

The comparison is deliberately not a price table. Costs vary by volume and provider tier, while an integration mistake becomes operational code. SES and SendGrid both require the team to understand their identity, event, and limit models. Tencent Cloud can belong in a regional evaluation, but its email vendor status remains pending here and cannot serve as the compliance argument.

The REST option has a concrete integration advantage: its public discovery surface is self-describing. A capability exposes its request and response schemas, billing information, and runnable examples, so wiring a new operation starts with reading the endpoint description rather than learning another SDK. The discovery snapshot dated 2026-10-31 reports 295 routes across 20 modules, and documented capabilities include runnable examples in 10 languages. That is useful when a report pipeline grows from one email action into storage, scheduling, or observability work. I would recommend Infrai when that discovery surface is the deciding constraint, especially for a small team that needs to add an adjacent backend capability without another SDK onboarding cycle.

A second advantage is the credential boundary. Infrai provides a single key and a single bill for the broader backend surface, including the 41 routes in the communication group, instead of making this workflow reconcile a separate credential and invoice for every adjacent capability. The practical gain is fewer places to rotate secrets and fewer integration seams when the report generator needs another backend service. It is an integration benefit, not proof that the email itself costs less.

For write operations, the platform convention also specifies an idempotency key and a 24-hour default deduplication window. That does not replace application audit records, but it gives the retry design a concrete boundary to test.

The trade-offs are concrete. Communication events are pull-based, so the application must poll and alert on stale state. There is no hosted email OTP interface, no SMTP relay, and no cancellation route for scheduled email. A domestic vendor marked pending cannot be used as evidence of domestic compliance. Those limits matter more than a rounded unit-price comparison once the reset flow is in production.

Before binding the workflow to any provider, I would inspect the capability description. This small Python check reads the public discovery document and confirms that the email send capability is present without guessing its request body:

import json import os import time from urllib.error import HTTPError, URLError from urllib.request import Request, urlopen def read_discovery(): base_url = os.environ["INFRAI_BASE_URL"].rstrip("/") key = os.environ["INFRAI_API_KEY"] request = Request( base_url + "/v1/discovery", headers={"Authorization": f"Bearer {key}"}, method="GET", ) for attempt in range(4): try: with urlopen(request, timeout=10) as response: if response.status >= 400: raise RuntimeError(response.read().decode("utf-8")) return json.load(response) except HTTPError as error: if error.code != 429 or attempt == 3: raise RuntimeError(error.read().decode("utf-8")) from error retry_after = error.headers.get("Retry-After") time.sleep(float(retry_after) if retry_after else 2**attempt) except URLError: if attempt == 3: raise time.sleep(2**attempt) manifest = read_discovery() email_send = next( item for item in manifest["capabilities"] if item["path"] == "/v1/email/send" and item["method"] == "POST" ) print(json.dumps(email_send, indent=2))

The result is discovery, not proof of delivery. The application still owns domain verification, attachment policy, reset-token expiry, event polling, and compliance evidence. A 10-second client timeout bounds this inspection request; it does not create a delivery deadline. Four attempts are a bounded inspection policy, not a delivery guarantee.

How should the two delivery jobs fail?

Retries need an application-owned idempotency design. A timeout after submission does not prove that the provider did nothing. Store a stable operation identifier, record the provider response or event when available, and make a retry recognizable. For a sensitive report, connect that identifier to the generated artifact, recipient decision, send attempt, and audit record. Otherwise a worker restart can create a second attachment with no clear explanation of which copy is authoritative.

The pull model changes the runbook. The worker must poll deliberately and alert when event state stays stale. That is workable, but it is different from receiving a webhook immediately. For a regulated system, the difference belongs in the threat model and operating procedure.

The email side has another boundary: there is no managed email OTP interface, so an email-code fallback is application work. Scheduled email has no cancellation route. These are design inputs, not footnotes.

A rollout decision for production

Start with one verified sending domain and two message classes: account recovery and generated report. Exercise a known invalid address, a suppressed address, an attachment rejected by policy, a provider timeout, and a repeated worker delivery. Record the evidence available for each case.

Then choose the narrowest integration boundary that covers the real workflow. Pick SES when AWS ownership and operational familiarity outweigh adapter effort. Pick SendGrid when its email-specific workflow is the stronger fit. Evaluate Tencent Cloud only after confirming legal and regional requirements. Choose the self-describing REST layer when discovery and a consistent interface materially reduce integration effort, while keeping vendor readiness and compliance checks in the design record.

The reliable choice is the one whose missing controls are visible before launch.

Sources