Transactional Email

Use case: reliably deliver user-facing transactional messages (password resets, receipts, confirmations) with template rendering, provider failover, and precise usage accounting.

Why SendPromptly

• Centralize event ingestion (single POST /api/v1/events) and fan-out to email providers.
• Template rendering with size caps (100KB) to prevent oversized messages.
• Provider failover and health checks to improve deliverability.
• Exponential retry schedule to handle transient failures without double-counting usage.

Example flow

1. Application emits an event user.signup to POST /api/v1/events with Authorization: Bearer <ENV_TOKEN> and Idempotency-Key: <uuid>.
2. SendPromptly resolves active email templates, renders the message, and creates a delivery_run.
3. DeliverEmailJob selects the configured provider and attempts delivery; retries occur at 0s, +1m, +10m, +1h, +6h if needed.
4. Usage is incremented once on first successful delivery for the delivery_run.

Example payload

{
	"event_key": "user.signup",
	"payload": { "name": "Alice", "signup_url": "https://app.example/verify" },
	"recipient": { "email": "[email protected]" }
}

Operational tips

• Keep templates concise to stay under the 100KB rendered cap.
• Use provider Test Connection in the portal after adding credentials.
• Monitor delivery runs in the Message Log to see attempt history and failure reasons.

Getting started

• Create an Environment and token in the portal, add an Email Provider under Provider Connections, and send a test event via the Quickstart instructions.