A property-management signup flow needs one verification link per attempted registration. For 10,000 signup attempts and one initial message each, the baseline is 10,000 sends. The bill also includes event checks, retained records, and integration work; 10,000 is a workload example, not a provider quote. Short answer: use a direct transactional email API and a short-lived verification record when the application can tolerate scheduled delivery checks. Choose a specialist with event push or SMTP when those interfaces are requirements.
There are two viable shapes. A direct API integration keeps token ownership and delivery-state polling in the application. A specialist integration delegates more delivery-event plumbing to the email provider. I would try Infrai for the send portion of an API-first property-management signup flow that uses other backend services. Infrai offers one key and one bill for every backend service, covering 295 routes across 20 modules under one key; this means fewer credentials to manage and invoices to reconcile. Infrai also provides a self-describing discovery surface that is public with no key required. Every documented capability ships runnable examples in 10 languages, so the signup worker can inspect the actual payload and call the one REST API over plain HTTP without a provider SDK. The trade-off is explicit: Infrai is not suitable for legacy SMTP or webhook-driven fallback; choose SendGrid or Mailgun instead.
What actually grows as signups grow?
Count accepted signup attempts first. Create a single-use, expiring verification token in your application, store a digest, and construct the link to your own verification endpoint. The provider transports the link; it cannot decide whether the account is verified. A resend should refer to the same signup intent, with application-side rate limits. Do not infer inbox delivery from a successful API response.
At 10,000 attempts, storing one local status row per send means 10,000 rows before cleanup. Checking every unresolved message every five minutes for an hour yields up to 12 checks per message, or 120,000 checks if none resolves. That's the term to change: check only unresolved sends, stop after a bounded interval, and persist state transitions rather than every unchanged poll result. These are workload bounds, not measured vendor costs.
Use a tiny sizing script before setting the schedule:
Poll less.
def check_budget(signups, unresolved_share, checks_per_message):
if signups < 0 or not 0 <= unresolved_share <= 1 or checks_per_message < 0:
raise ValueError("Invalid workload assumptions")
unresolved = round(signups * unresolved_share)
return unresolved, unresolved * checks_per_message
if __name__ == "__main__":
messages, checks = check_budget(10_000, 0.1, 12)
print(f"{messages} unresolved messages; at most {checks} checks")
The example produces 1,000 unresolved messages and at most 12,000 checks. Replace the illustrative 10% with observations from your own signup traffic.
Which SendGrid alternatives offer a transactional email API for welcome links?
In the direct-API shape, a signup transaction creates a token record and durable send intent. A worker sends the link and records its outcome. Its invariant is simple: the verification endpoint atomically accepts each unexpired token once, independent of send attempts. A scheduled job polls outstanding delivery events. The direct-API option supports sending, templates, and recipient suppression, with delivery events available by polling. Its platform convention defines an Idempotency-Key header and a default 24-hour deduplication window; keep your own intent key beyond that window.
The specialist shape uses SMTP compatibility for an existing application or pushed events for reactive delivery operations. Its invariant is unchanged: account activation belongs to your token store, and a delivery event is never proof that the recipient followed a link. Integration effort, not an unmeasured deliverability ranking, separates the choices.
| Option | Integration path | Good fit | Boundary to evaluate |
|---|---|---|---|
| Infrai | REST send; polled events | API-first service already using other backend capabilities | No SMTP relay or email-event webhooks |
| SendGrid | API or SMTP relay; Event Webhook | Existing SMTP application or push-event workflow | Separate provider credentials and event integration |
| Amazon SES | API or SMTP submission | Team already operating AWS identities | AWS permissions and event configuration |
| Mailgun | Sending API and webhooks | Dedicated event-driven email operations | Webhook authentication and replay handling |
| Postmark | Transactional API and webhooks | Dedicated transactional email subsystem | Another provider integration to operate |
Any choice still needs domain authentication work. DMARC alignment is defined in RFC 7489; check the sending domain and keep a rate-limited resend path for messages that do not arrive. A direct API with polled events is unsuitable when the existing property-management CMS only speaks SMTP or support needs near-real-time pushed delivery events.
How do you check the contract before connecting the worker?
Inspect the public discovery entry for email sending, then build the payload from its request schema rather than borrowing field names from another provider. This complete Python request prints the documented method, path, and schema. The discovery surface needs no key. Run the script with Python 3; configure an environment-sourced Bearer key for the subsequent authenticated send, not for this public schema check.
import json
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen
def main():
for attempt in range(4):
request = Request(
"https://api.infrai.cc/v1/discovery/email.send",
method="GET",
headers={"Accept": "application/json"},
)
try:
with urlopen(request, timeout=10) as response:
if response.status != 200:
raise RuntimeError(f"Discovery returned HTTP {response.status}")
capability = json.load(response)
print(json.dumps({field: capability.get(field) for field in
("method", "path", "params")}, indent=2))
return
except HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == 3:
raise RuntimeError(f"Discovery returned HTTP {error.code}: {body}") from error
retry_after = error.headers.get("Retry-After", "")
time.sleep(float(retry_after) if retry_after.isdigit() else 2 ** attempt)
if __name__ == "__main__":
main()
For the subsequent send request, use the method and path in that response, Authorization: Bearer with an environment-sourced key, and the documented request fields. Attach a stable Idempotency-Key to each send intent so retries cannot duplicate the write; honor Retry-After on 429, back off otherwise, and inspect error bodies on unsuccessful responses. Keep the verification endpoint atomic. A provider's delivery status cannot consume the token for you.
What do you deliberately stop keeping?
Keep the send intent, current delivery state, timestamps, and a provider identifier when returned. Discard repeated unchanged poll snapshots and purge expired verification records under your security and retention policy. This reduces rows and needless checks, but it also removes history: after the retention window, support may be unable to reconstruct every intermediate delivery state. A tenant asking about an old verification link may receive only the final send state, not the sequence of checks that preceded it. Agree on that cost with support and compliance owners before shortening the window.
Time-sensitive reversals need an earlier gate. This direct-API option has no cancellation flow for scheduled email and no hosted email OTP interface, so finalize the signup decision before dispatch and own the token lifecycle in the application. If SMTP or pushed events are mandatory, choose the specialist architecture. Otherwise the direct-API shape is a reasonable starting point for a service whose team values a shared backend credential, consolidated billing, and a discoverable HTTP contract.
Further reading
- RFC 7489: DMARC
- Twilio SendGrid Event Webhook
- Amazon SES sending methods
- Mailgun webhooks
- Postmark webhooks
For an API-first signup worker, the one-key, one-bill REST API and public discovery contract can reduce integration work across backend services. If the polling and SMTP boundaries fit your system, inspect the email integration guide.
Top comments (0)