Email infrastructure
Know which delivery controls are live, gated, or still in rollout.
Use the REST API for application email. Other sending options require workspace approval and setup. Check access before choosing a connection or delivery option.
Capability map
The current integration and rollout boundaries.
- REST API: the generally available, retry-safe send path with caller-supplied idempotency keys.
- SMTP submission: built for a controlled rollout but not available yet or publicly reachable. Send with the REST API today.
- Managed delivery: provider adapters, an outbox, normalized delivery events, and suppression enforcement.
- Dedicated IP assignment: an operator-gated beta for eligible Scale and Enterprise tenants.
- Dedicated-IP warm-up: automation is off by default and requires explicit setup for an approved dedicated IP.
- Status webhooks: signed, tenant-scoped delivery callbacks with configurable bounded retries.
Send isolation
Message category selects a bounded route.
The REST request accepts six categories: security, billing, transactional, briefing, marketing, and third-party. They map to security, billing, transactional, briefing, and marketing outbox lanes, then to critical, transactional, or bulk provider streams.
Queue and stream isolation protects scheduling priority and policy handling. Shared IP plans still share physical sender reputation, so queue isolation must not be described as a guarantee that one traffic class can never affect another. Dedicated IP routing requires separate operator approval and production evidence.
Managed warm-up
Warm up an approved dedicated IP gradually.
Start with a small sending volume and increase it gradually. Dedicated IP access requires approval and setup. Progress depends on delivery, bounce, complaint and deferral results, rather than a fixed timetable.
Automated warm-up is off by default and must be set up explicitly for your approved IP. Pausing automated warm-up keeps the current sending limits in place. Warm-up does not guarantee inbox placement.
Delivery evidence
Accepted messages and downstream outcomes are different facts.
A 202 response means the REST API accepted the message into the send pipeline. Tenant-scoped message logs and events then record accepted, queued, delivered, deferred, bounced, or complained outcomes. Final delivery should be read from those events, not inferred from API acceptance.
Status webhook subscriptions sign a canonical JSON payload with HMAC-SHA256 and a per-endpoint secret. Their retry budget is configurable from 1 to 10 attempts and defaults to 3; exhausted deliveries enter a dead-letter state for operator-visible follow-up.
Reliability and retention
Use the published policy and plan catalog.
Review the service terms for availability commitments and use message status to follow accepted sends.
Published availability terms apply to accepted API requests through the send pipeline. SMTP is not publicly reachable and has no separate availability commitment. Plan log-retention targets are 7 days on Free, 30 on Starter, 90 on Growth, and 365 on Scale. Confirm the current policy for your workspace.
Read next
- Developer documentation: current REST request and idempotency contract.
- SMTP submission: the beta protocol and activation gates.
- Service levels: availability terms and evidence sources.
- Public status: coarse component health and current incidents.
- Pricing: plan limits, eligibility, and retention.