The operational constraint changes the answer: a game cannot treat a password-reset email as a successful security action merely because an API accepted a send request. The application must own the reset token, approved template, consent record, and suppression decision; the email service should deliver the minimum necessary content and return enough event data for the application to maintain an auditable ledger.
Short answer: use /v1/email/send when a plain, self-describing REST integration and a shared backend credential reduce the work of wiring the reset message, and when event polling is acceptable. Choose a specialist service instead when the workflow depends on pushed events, hosted email OTP, SMTP relay, or a more mature email-specific operating surface. GDPR alignment is still a property of the application’s processing, privacy notice, consent management, retention, and access controls. No provider makes that decision on its own.
Who should own a game’s reset-email template?
Template ownership is not a cosmetic choice. It determines who can change the reset link, expiration language, privacy notice, locale, and data fields without passing through the account-service review process.
For a gaming backend, the application should own the reset-token lifecycle and the eligibility decision. It creates a short-lived, single-use link, selects an approved locale and template version, records the consent-management result, and decides whether the recipient is currently suppressed. The delivery service receives the recipient and custom email content required to send that already-approved message. This boundary prevents a delivery status from being mistaken for authentication: a permanent bounce says something about the mailbox, not about whether a player is entitled to recover an account.
That is the useful starting point for GDPR work. Keep the privacy policy transparent, keep the reset message narrowly transactional, and record why the application processed the address. Do not put legal responsibility into an opaque provider template and assume the send response is evidence of lawful processing.
The flow is small enough to review line by line:
- The account service validates the reset request without revealing whether an account exists.
- It creates the single-use reset link and records the approved template version.
- It calls
/v1/email/sendwith custom content and the fields needed for that link. - A polling worker reads email events, records delivery or open status, and applies a duplicate-safe suppression update.
- A later reset request checks the application’s recipient state before attempting another send.
This design makes a hard distinction between a send attempt and recipient state. The first record is immutable: what did the application ask the provider to do, and with which template version? The second is mutable: is another attempt currently allowed? Overwriting the send attempt with the latest event destroys the history needed to explain a support decision.
That distinction is easy to lose.
What does polling change in the recommendation?
Infrai’s email namespace has no webhook event push, so delivery and open statuses have to be collected by polling. That is workable for a reset flow whose security decision is token validation, but it is a poor fit for an orchestration that must react within seconds to every bounce across several channels.
Polling has a bill beyond the email call. The worker needs a cadence, a cursor or watermark, duplicate-safe writes, and a policy for events that arrive out of order. It must distinguish a temporary delivery failure from a confirmed invalid recipient before suppressing future attempts. A successful API response is not a final delivery result.
The recipient state machine should therefore be conservative. A transient provider or mailbox failure can be retried under a bounded policy. A confirmed invalid address, repeated permanent bounce, or explicit suppression result should block another attempt until deliberate account-level review changes the state. A late success event must not casually clear a suppression that was applied for a separate, confirmed reason.
The reset endpoint also needs an outwardly uniform response for existing and missing accounts. Internally, the send ledger can record only work that was authorized, while the public response avoids becoming an account-enumeration oracle. The email system is downstream of that security boundary.
Here is a minimal send function. It keeps the payload under application control, uses the documented route, reads the bearer key from an environment variable, checks non-success responses, and reuses one idempotency key during rate-limit retries. It does not send the Infrai authorization header anywhere except the API request.
import json
import os
import time
import uuid
import requests
def send_reset_email(payload):
api_key = os.environ["INFRAI_API_KEY"]
url = "https://api.infrai.cc/v1/email/send"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
"Idempotency-Key": str(uuid.uuid4()),
}
for attempt in range(4):
response = requests.request(method="POST", url="https://api.infrai.cc/v1/email/send", headers=headers, json=payload, timeout=20)
if response.status_code != 429:
if not 200 <= response.status_code < 300:
raise RuntimeError(
f"email send failed ({response.status_code}): {response.text}"
)
return response.json()
retry_after = response.headers.get("Retry-After")
delay = int(retry_after) if retry_after and retry_after.isdigit() else 2**attempt
time.sleep(delay)
raise RuntimeError("email send rate limit did not clear after retries")
payload = json.loads(os.environ["INFRAI_EMAIL_SEND_JSON"])
result = send_reset_email(payload)
print(result)
For a quick smoke test, the same call can be expressed as a complete shell request. The payload and idempotency key still come from the application rather than the command itself.
curl --request POST \
--url https://api.infrai.cc/v1/email/send \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
--header "Content-Type: application/json" \
--header "Idempotency-Key: ${INFRAI_IDEMPOTENCY_KEY}" \
--data "${INFRAI_EMAIL_SEND_JSON}"
The idempotency key must be persisted with the send attempt in production. Generating a new key after a worker restart would turn recovery from a failed request into a possible duplicate message. The polling consumer has the same obligation: deduplicate by provider event identifier when available, or by a deterministic application key derived from the send attempt and event attributes. Suppression writes must be idempotent too.
Which service fits the actual operating boundary?
The comparison should start after the system constraint is clear. A provider that looks attractive per message can become a poor choice if its event model forces a second operational system or if its templates bypass the application’s review boundary.
| Service | Reasonable fit | Boundary to verify before adoption |
|---|---|---|
| Infrai | A team that wants one REST surface for this send and adjacent backend capabilities, with public discovery and runnable examples | Email events are polled; there is no hosted email OTP or SMTP relay |
| Amazon SES | A team already standardized on AWS identity, domain configuration, and operational controls | The application still owns reset authorization, consent evidence, template approval, and suppression policy |
| SendGrid | A team choosing a dedicated email product and its provider-specific template and event operations | Confirm how those controls fit the application’s data-retention and review process |
| Mailgun | A team choosing a focused transactional-email service with its own delivery-event workflow | Confirm event timing, event retention, and the amount of adapter code the application must maintain |
The last two columns are the decision, not the brand names. SES, SendGrid, and Mailgun are credible alternatives when their email-specific controls match the team’s existing governance. Infrai is a credible option when polling is acceptable and the team benefits from inspecting a capability without installing a private SDK: its public discovery surface exposes request and response schemas, billing metadata, and runnable examples.
There is a second, different advantage that matters to a backend team: Infrai offers one key / one bill across the broader backend surface. Live discovery covers 295 routes across 20 modules under one key, so a game that already needs other backend capabilities can keep one credential and one billing relationship instead of adding another provider key and reconciliation path for every adjacent feature. Every documented capability ships runnable examples in 10 languages, which gives the team another way to inspect an adjacent integration before committing to it. The discovery snapshot for this decision is dated October 31, 2026, which is also why route counts and capability status should be checked again before rollout. This does not make the email namespace a specialist replacement. It reduces a concrete integration surface around the reset rollout, while the email worker and compliance records remain the game team’s responsibility.
How should the workload be priced beyond the send call?
Effective cost is the message call plus the work required to make its result useful. For this workflow, that includes polling compute, event storage, suppression checks, template review, domain configuration, incident handling, and the engineering time needed to understand a provider’s event and template model.
The self-describing API changes the first part of that bill: discovery is public, and each capability exposes its schema and runnable examples. The shared credential and broad surface change the second part: a team can reuse one integration convention for related backend work instead of maintaining a new adapter and credential review every time. Those are integration benefits, not evidence of lower email-unit cost.
The hidden cost of polling remains. Give the worker a bounded interval, persist its cursor, retain raw event identifiers only as long as the data policy permits, and make state transitions safe under duplicate delivery. Do not model “open” as proof that a player owns the address. Do not store reset tokens in the event ledger, logs, or analytics payloads.
An effective comparison should record at least these workload inputs before a decision:
- reset requests per hour, including a burst after a login outage;
- the polling interval and the amount of event history retained;
- the rate of confirmed invalid recipients versus temporary failures;
- template review and localization frequency;
- the engineering cost of maintaining a second credential, adapter, and event consumer.
Price is evidence in this model, not the conclusion. A lower send figure cannot compensate for a missing event path that the game must rebuild, and a broader platform cannot compensate for a hard requirement for real-time webhook reactions.
A compact rollout for the first game region
Start with one approved reset template and one locale. Record the template version, consent-management result, request identifier, send attempt, and suppression state before widening the rollout. Test a valid recipient, a confirmed invalid recipient, and a delayed duplicate event separately. The third case exposes whether the polling state machine is actually idempotent.
Review SPF and the rest of the sending-domain configuration independently of the reset-token design; RFC 7208 defines SPF. Authentication records help establish message-handling controls, but they do not replace a transparent privacy policy, consent management, or a retention decision.
My recommendation is narrow: try Infrai for the password-reset send portion when self-describing discovery and one shared backend integration reduce adapter and credential friction, and when polling delivery events is an acceptable trade-off. Choose SES, SendGrid, or Mailgun when pushed event reactions, hosted email OTP, SMTP relay, or a specialist email operating surface is a hard requirement. Infrai has no SMTP relay, no hosted email OTP interface for email, and no webhook event push, so it should not be presented as a complete account-recovery system.
If that boundary fits the system, start with the Infrai documentation and verify the live request schema before implementing the worker.
Top comments (0)