Status and early access

The service is in early access. This page says what that means so you can decide what to build on it.

What early access means#

One server. The API, the dashboard, this site and the database run on a single server with one persistent disk. There is no failover and no second region. A restart or a deploy interrupts requests for a short time.
No uptime commitment. There is no service level agreement and no public status page yet. You can check a server yourself: GET /health answers while the process is up and GET /ready also checks the database (it answers 503 when the database is unusable).
Limits reset on restart. Request rate limits, login throttles and sign-up limits are kept in memory. Stored data, scheduled drafts and pending webhook retries are in the database.
Backups are on the same disk. See security.
Prices are illustrative. They can change before launch, and paid checkout has not been exercised against live payment accounts. The Free plan works today. There is no tax invoicing (GST or VAT).
Legal pages are drafts. The terms, privacy policy and acceptable use policy carry a visible banner: they have not been reviewed by a lawyer.
The API is v0. Fields and routes can still change; the changelog records changes.

The feature availability table is generated from the code and is the authority. In short:

Area	State
Everything marked Available in the table	Works, in the dashboard where one makes sense and in the API.
Features marked API only (forward, scheduled send, search, attachments)	Work through the API and SDKs where marked; no dashboard screen yet.
Sending from and receiving on your own domain	Not connected. DNS record generation and verification work. See domains.
TypeScript SDK, Python SDK, LangChain toolkit, local MCP server	Work from the repository folders; not published to npm or PyPI.
Hosted MCP at `/mcp`	Works; see MCP.
IMAP and SMTP client access, AgentID sign-in	Not built and not planned.

Make your sends idempotent (Idempotency-Key) and your webhook handler idempotent (svix-id), so a retry after an interruption is harmless.
Keep the events log in mind: after downtime, GET /v0/events replays what you missed, and webhooks retry for up to eight attempts.
Keep your own copy of anything you cannot lose. Treat the service as a delivery and receiving layer, not an archive.
Read errors and troubleshooting so your code handles 429 and 5xx with backoff.