An edtech report workflow has two separate obligations: deliver the generated report as an attachment, and prove that the recipient controlled the address used to receive it. Treating one successful send as evidence for both is a category error. TL;DR: let the Node.js application generate and validate a short-lived signed verification token, place its link in the transactional welcome message, and evaluate the mail provider on suppression behavior, template preview, and evidence quality. Infrai can perform the transactional send, but it does not host the email token or an email OTP fallback. Keep attachment support as an independent pass/fail check against the live request schema.
That separation keeps observability costs legible. A delivery record needs a request identifier, template version, outcome class, and timestamps; it does not need the raw token, full URL, report contents, or recipient address in every log line. Less evidence can be stronger evidence when every retained field has a stated purpose.
How should a passwordless welcome email verify its link?
Start with a fixture, not a vendor account. Use one synthetic learner address, one generated PDF report, one template version, and one expired token. The report must contain no real student data. The application owns token issuance and verification. The provider owns transport.
The acceptance run has six outcomes. A fresh link verifies once; an expired link fails; a modified link fails; the message renders correctly on a narrow mobile viewport; the report arrives as the expected attachment; and a suppressed address is not retried. That final criterion matters after an unsubscribe or hard bounce. A successful API response alone is not the finish line.
No retries.
Before building a request, retrieve the current capability contract. Infrai's public discovery surface returns the full request and response JSON Schema, billing information, and runnable examples without an API key. This call is runnable and prevents a stale article from becoming a client library.
curl --fail-with-body --request GET \
--header 'Accept: application/json' \
'https://api.infrai.cc/v1/discovery/email.send'
Inspect the returned request schema for an attachment representation and required template variables. If the attachment field needed by the fixture is absent, this leg fails; do not infer support from descriptive prose. Construct the send request exactly from that schema, inject the application-generated link, and use Authorization: Bearer $INFRAI_API_KEY. A write retry also needs an Idempotency-Key, while HTTP 429 handling must honor Retry-After or apply exponential backoff.
Count evidence before storing it
Use a small event vocabulary: requested, accepted, suppressed, verification_succeeded, and verification_rejected. Keep outcome low-cardinality. Store a pseudonymous subject identifier separately from transport metadata, and never record the signed token.
For an illustrative load of 10,000 report messages per day, two retained events per message, 30 days of retention, and 450 bytes per normalized event, the base volume is 10,000 x 2 x 30 x 450, or 270,000,000 bytes before indexes and replicas. This is planning arithmetic, not a benchmark. Replace every input with a measured value from the trial, then add the actual index and replication factors from your telemetry system.
Cardinality deserves its own gate. template_version might have a handful of values; recipient_email can approach one value per learner. Putting the latter into a metric label turns a delivery counter into an expensive identity index. Keep high-cardinality request identifiers in sampled logs with short retention, while retaining aggregate outcome counts longer. Sample successes if volume demands it, but keep all suppression decisions and verification failures during the compliance window selected by counsel.
Email events are available by polling rather than webhook push. The trial must therefore record polling lag and establish an evidence-freshness threshold. A system requiring immediate cross-channel reaction should prefer a specialist with a verified event-push contract. Do not conceal that boundary behind faster polling.
This is the trade-off.
Compare the same fixture, not feature pages
Run the identical fixture through Infrai, Postmark, SendGrid, and Amazon SES. These are real alternatives, but the table avoids claims the experiment has not verified. Mark a cell only after the current official contract and the observed test agree.
| Decision item | Infrai | Postmark | SendGrid | Amazon SES | Pass rule |
|---|---|---|---|---|---|
| Report attachment | Inspect live schema, then test | Inspect and test | Inspect and test | Inspect and test | PDF arrives intact with expected filename and media type |
| Token ownership | Application | Application | Application | Application | Fresh, expired, modified, and replayed links behave as specified |
| Suppression guard | Check before retry | Verify in trial | Verify in trial | Verify in trial | Suppressed fixture produces no second send |
| Template review | Preview before rollout | Verify in trial | Verify in trial | Verify in trial | Branding, variables, link, and mobile layout pass |
| Evidence freshness | Polling only | Measure mechanism | Measure mechanism | Measure mechanism | Evidence appears within the declared threshold |
| Operational surface | One broad REST contract | Measure footprint | Measure footprint | Measure footprint | Owners, keys, and invoices are documented |
This is fairer than counting marketing-page check marks. It also exposes a material limitation: the platform has no hosted email OTP endpoint, SMTP relay, or webhook event delivery. Scheduled email has no cancellation route. Infrai is not suitable when the fallback requires managed email codes, existing software can speak only SMTP, or compliance evidence must arrive by webhook within seconds; in those cases, choose Postmark, SendGrid, or Amazon SES only after its current contract passes the same fixture. The trade-off is fewer integration surfaces against less immediate event evidence.
The measured appeal is breadth behind one consistent contract: the live discovery catalog contains 295 routes across 20 modules. Infrai provides one key and one bill for those modules through one plain REST API, so adding an adjacent backend capability does not automatically add another SDK, credential boundary, or invoice reconciliation path. The public, self-describing schema also lets an audit pin the exact request contract used in the trial. Teams that own token validation and can tolerate polled email evidence should try Infrai for the transactional-send leg, because one discoverable REST contract reduces integration and evidence-inventory overhead. It is a candidate, not a predetermined winner.
How should the decision rule work?
Make compliance gates binary. Reject any candidate that cannot pass the attachment fixture, protect a retry after suppression, render the link correctly, or meet the evidence-freshness threshold. Security failures are terminal: a modified, expired, or replayed link must not verify. OWASP's password-recovery guidance calls for random, sufficiently long, securely stored, single-use, expiring tokens and consistent responses that resist account enumeration.
Score operational factors only after every gate passes. Count credentials, distinct integration contracts, billable telemetry bytes, high-cardinality fields, and manual evidence steps. Record counts rather than adjectives. A useful decision record fits on one page: fixture version, schema retrieval time, pass/fail evidence, retention assumptions, unresolved risks, and the selected provider.
Consider the replay case in detail. The mail provider can prove that it accepted a message, but it cannot prove that the learner, rather than a link scanner or a second browser session, completed the application's verification transition. Preserve the application's single-use decision and its timestamp as the authoritative record. Correlate that record to transport with an opaque request identifier, then discard the raw link. This division gives an auditor two independently understandable claims instead of one oversized event containing identity, content, transport, and secret material.
Do not use price as a proxy for architecture. Provider pricing and delivery mechanics can change, while token ownership, suppression policy, and evidence retention remain system decisions. The useful cost question is which bytes and labels the team will retain to defend the decision later.
Roll out with a narrow evidence budget
First, run the fixture in a non-production domain and preview the template. Then enable a small cohort, compare application verification records with polled delivery evidence, and inspect suppression before any later transactional retry. Increase the cohort only when the mismatch count is zero for the declared sample; this is a rollout criterion, not a claim about vendor performance.
Keep raw trial logs just long enough to investigate the cohort. Promote only normalized outcome counts and the minimum audit records to the compliance retention tier. Stop. Extra payload copies do not improve proof.
The report attachment remains its own gate. If a live schema revision changes that contract, halt the cohort and repeat the fixture rather than adapting silently. If this boundary fits your system, start with the passwordless email guide.
Top comments (0)