> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dairo.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Plans & pricing
> Start free, scale on standard tiers, and move to enterprise when you need governance controls, metered billing, and higher limits.
Most teams run well on Dairo's standard plans — a fixed monthly allowance of
sending and storage, self-served from checkout. The enterprise tier adds
governance controls, metered pay-as-you-go billing, and limits beyond the
standard ceilings, for high-volume, security-conscious, or compliance-bound
senders.
The core product is identical on every plan. Whatever tier you're on, you send,
receive, schedule, and verify with the same API, SDKs, CLI, and MCP server — and
you can read your live usage from a single endpoint any time, so the numbers your
bill is built from are never a surprise.
Enterprise is configured per account and isn't self-served from checkout —
[talk to us](mailto:sales@dairo.app) about volume, governance requirements, and
pricing.
## Standard plan limits
Every plan carries an allowance, enforced on your account and reported by
`whoami` under `limits`. These are the standard tiers; enterprise limits are set
by contract.
| Plan | Inboxes | Domains | Emails / month | Storage |
| ------------ | ------- | ------- | ---------------- | ------- |
| `free` | 5 | 1 | 1,000 | 1 GB |
| `developer` | 25 | 3 | 15,000 | 10 GB |
| `startup` | 250 | 25 | 200,000 | 100 GB |
| `scale` | 1,000 | 100 | 500,000 | 250 GB |
| `enterprise` | Custom | Custom | Custom (metered) | Custom |
The `Emails / month` allowance counts inbound messages and accepted outbound
recipients together, against `limits.emailsPerMonth`. Check your live tier and
remaining headroom any time under [reading your meter](#read-your-meter).
## What enterprise unlocks
Enterprise accounts keep everything the standard plans have and add four things:
* **Audit logs** — an immutable, account-wide trail of governance actions (keys,
domains, inboxes, and webhooks created or deleted), each with its actor and
source IP. Audit logs and per-key IP allowlisting both live under
[audit logs](/compliance/audit-logs).
* **API-key IP allowlisting** — lock a key to trusted IPs or CIDR ranges,
deny-by-default, so a leaked secret is useless from anywhere else.
* **Pay-as-you-go billing** — metered billing on negotiated per-unit rates, with
optional commitment and overage instead of a fixed tier. See
[standard vs. enterprise billing](#standard-vs-enterprise-billing).
* **Higher limits** — more inboxes, domains, monthly volume, and storage than the
`scale` ceilings — plus priority support and a named account team.
Scopes, scheduled sending, idempotency, webhooks, and the full API surface are the
same on every plan. Enterprise doesn't gate the core product — only the governance
and metered-billing features above, plus higher limits. Every plan sends over the
same shared, actively-monitored [IP pool](/platform/dedicated-ips).
## What gets metered
Dairo records three metered dimensions as you use them:
| Dimension | Unit | What counts |
| ---------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Outbound email | Per accepted recipient | Each accepted recipient of a send. A message to 3 recipients meters as 3. |
| Printed letters | Per letter | Each letter accepted for print and mail, priced by pages, delivery, and destination. See [letter pricing](/letters/pricing). |
| Structured-inbox extractions | Per extraction | Each inbound message a [structured inbox](/receiving/structured-inboxes) turns into fields. |
On the enterprise pay-as-you-go tier you're charged per unit on each, at your
contract rate. Inbound messages and stored bytes aren't separate line items:
inbound counts toward your monthly email allowance (`limits.emailsPerMonth`,
alongside outbound recipients), and stored bytes count against your storage limit
(`limits.storageBytes`).
[Scheduling a send](/sending/sending-email#schedule-for-later) doesn't change
what's metered: a scheduled send is counted once, when it's accepted for delivery
— the same as an immediate send. A send you cancel while it's still `scheduled`
never goes out, so it never meters.
## How usage is counted
A few rules keep your bill predictable:
* Usage counters update continuously as work is accepted — a recipient accepted
for delivery, a message received, bytes stored — not only at month's end.
* A [broadcast](/audiences/audiences) meters per recipient the same way a direct
send does.
* A retried send carrying the same `Idempotency-Key` resolves to one accepted
send and meters once — see [idempotency](/concepts/idempotency).
## Read your meter
`whoami` reports your plan, current-period usage counters, and limits — the same
numbers your bill is computed from. Check it any time; agents should check it
*before* large operations.
```bash title="cURL" theme={null}
curl https://api.dairo.app/v1/whoami \
-H "Authorization: Bearer $DAIRO_API_KEY"
```
```ts title="TypeScript" theme={null}
const me = await dairo.whoami();
console.log(me.plan, me.usage); // counters for the current billing period
```
```python title="Python" theme={null}
me = dairo.whoami()
print(me.plan, me.usage)
```
```bash title="CLI" theme={null}
dairo whoami
```
Each `usage` counter measures your current-period activity against the matching
value in `limits`:
| Field | Meaning |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| `outboundEmailsThisMonth` | Accepted recipients sent this period — the per-recipient meter, and part of your monthly email allowance. |
| `inboundEmailsThisMonth` | Messages received at your [inboxes](/receiving/inboxes) this period. Counts toward the monthly email allowance. |
| `emailsThisMonth` | `inboundEmailsThisMonth + outboundEmailsThisMonth`, checked against `limits.emailsPerMonth`. |
| `storageBytes` | Active stored bytes right now, checked against `limits.storageBytes`. |
| `storageBreakdown` | `storageBytes` split into `messageBodyBytes`, `attachmentBytes`, `fileBytes`, and `expiringFileBytes`, plus an `activeStorageObjects` count. |
| `inboxes` / `domains` | Point-in-time counts checked against `limits.inboxes` / `limits.domains`. |
| `period.monthStart` | UTC start of the current monthly period the counters accrue from. |
```json theme={null}
{
"plan": "scale",
"period": { "monthStart": "2026-06-01T00:00:00Z" },
"limits": { "inboxes": 1000, "domains": 100, "emailsPerMonth": 500000, "storageBytes": 268435456000 },
"usage": {
"inboxes": 12,
"domains": 3,
"emailsThisMonth": 18420,
"inboundEmailsThisMonth": 6120,
"outboundEmailsThisMonth": 12300,
"storageBytes": 4194304
}
}
```
**For agents:** treat usage counters as a budget signal. The
[MCP server](/agent-first/mcp-server) exposes `get_account_info` with
`{ "action": "usage" }` and `{ "action": "storage" }` so an agent can check
remaining headroom before a large send or upload and back off when it's near a
threshold.
## Standard vs. enterprise billing
The standard plans (`developer`, `startup`, `scale`) bundle a fixed monthly
allowance and are self-served. Enterprise replaces the fixed ceilings with
negotiated limits and metered pay-as-you-go billing, and adds the governance
controls above.
| | Standard plans | Enterprise |
| ----------------------- | --------------------------------------------- | ---------------------------------------------------------------- |
| Billing | Fixed monthly tier with an included allowance | Pay-as-you-go on negotiated rates, optional commitment + overage |
| At a limit | Hard quota error on the affected operation | Absorbed as metered overage, not blocked |
| Sending IPs | Shared, actively-monitored pool | Same shared, actively-monitored pool |
| Audit logs | Not available | Account-wide, immutable, paginated |
| API-key IP allowlisting | Not available | Per-key IP/CIDR allowlist, deny-by-default |
| Onboarding | Self-served | Account team and provisioning managed for you |
On standard fixed-tier plans, exhausting an allowance (for example
`limits.emailsPerMonth` or `limits.storageBytes`) returns a clear quota error on
the affected operation rather than silently billing overage. The enterprise
pay-as-you-go model bills your real volume instead:
Every accepted recipient, letter, and extraction is recorded as it happens,
across all your keys and inboxes.
Your contract sets the per-unit price on each dimension, typically stepping
down as committed volume grows.
A common shape is a monthly commitment covering an expected baseline at a
favorable rate, with usage beyond it billed as overage at the agreed rate.
Usage across every dimension rolls up into a single end-of-period invoice,
itemized by dimension and reconcilable against your `whoami` counters and
[delivery tracking](/sending/outbound-tracking).
Your bill, invoices, and payment method live in the dashboard:
* **Where to see it.** The dashboard's Usage and Billing pages show current-period
metered usage, a projected cost, and your invoice history. The billing portal
downloads invoice PDFs and manages your payment method. Billing is a dashboard
action, not part of the API — no API key required.
* **Cadence.** Metered usage accrues continuously and rolls up per calendar-month
period (`period.monthStart` in `whoami`). Subscription charges and metered
overage are invoiced at the end of each period, and counters reset to zero when
the next one starts.
* **Projected cost.** The dashboard layers a cost projection over the raw counters
— your current-period outbound count times the per-recipient rate, plus any plan
base. It's an estimate on every plan and becomes your actual metered charge on
the enterprise pay-as-you-go tier. Exact rates are set by your plan or contract.
* **What's in a metered event.** Each accepted unit is recorded as a single
billable quantity, de-duplicated so an idempotent or retried send is never
counted twice. No recipient addresses and no message content are ever included —
only the billable count and minimal context.
* **Managing your subscription.** Cancel, reactivate, or change plan from the
dashboard. A cancellation is scheduled for the end of the current period by
default and is reversible until then, so you keep what you've paid for through
the period.
## Controlling spend
Pay-as-you-go bills for what you use, so an unbounded loop or runaway agent shows
up as real spend. Two controls do the heavy lifting:
* **Cap automated sending with [send budgets](/agents/reputation).** A budget is a
hard ceiling Dairo enforces on an account, a key, or an agent. The next send
that would cross the line is refused before it goes out — the first move for any
automated sending.
* **Make retries safe with idempotency.** A retried send carrying the same
`Idempotency-Key` resolves to one accepted send and meters once, so a retry
storm can't double your bill.
Beyond those, check the meter before large sends: read `whoami` (or the MCP
`get_account_info` `usage` action) and compare `usage.emailsThisMonth` against
`limits.emailsPerMonth`, backing off when you cross your own threshold. Give each
service or agent its own [API key](/get-started/authentication) so usage is
attributable and a misbehaving key can be revoked on its own. And reconcile
metered sends against delivery outcomes so a spike in bounces or complaints
surfaces before it becomes both a bill and a reputation problem.
## Moving to enterprise
Enterprise pays off when you need sustained high volume, governance controls
(audit logs, IP allowlisting), metered billing, or limits beyond `scale`. Email
[sales@dairo.app](mailto:sales@dairo.app) with your expected volume, governance
requirements, and which features you need; Dairo configures the plan and
negotiates rates. Your code doesn't change — the enterprise features layer onto
the same API, SDKs, CLI, and MCP server you already use.
## Next steps
How Dairo's shared, actively-monitored IP pool works.
The audit trail and API-key IP allowlisting.
Cap automated sending with hard budgets.
Reconcile metered sends against delivery outcomes.