> ## Documentation Index
> Fetch the complete documentation index at: https://docs.preuve.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Quotas and Billing

> The API consumes your existing Preuve account quotas. No separate API billing.

The Agent API is an access channel, not a separate product: every call draws on the same account balance and quotas as the web app.

## What each call consumes

| Call | Consumes |
| - | - |
| `scanType: "starter"` run | Never charged. Free-tier and regional accounts: one scan from the Starter scan allowance. Paid accounts (Founder, Lifetime, premium): unlimited, under a silent fair-use ceiling |
| `scanType: "deep"` run | See the waterfall below |
| Enrich (core sections) | Nothing extra - included in the run |
| Deep modules | Nothing extra - included in the paid deep report (capped at one successful generation per module) |
| Poll / export | Nothing |

## Deep scan quota waterfall

A deep run claims quota in this order:

1. **Active subscription** (Radar Pro, etc.) - decrements your monthly subscription scan counter.
2. **Lifetime plan** (Lifetime Pro / Business) - decrements your monthly lifetime scan counter (5 or 10 scans/month; plans bought before October 1, 2026 keep 10 or 20). When the monthly counter is exhausted, the run falls back to tokens if you have any.
3. **Tokens** - deducts 1 token from your balance, recorded in the transaction ledger.

No quota and no tokens returns `402 INSUFFICIENT_TOKENS` - the run fails before any analysis starts, and nothing is charged.

## Safety nets

* **Automatic refunds**: if a run fails before the analysis actually starts (service disabled, dispatch failure, ...), whatever it claimed - token, lifetime scan, subscription scan, Starter scan - is refunded.
* **Idempotent retries**: re-POSTing a `clientRunId` whose run failed before dispatch retries it without double-spending. A run that started always returns its stored outcome.
* **Explicit `scanType`**: agents cannot spend paid quota by accident; deep is always an explicit choice.
* **Failed modules never consume the per-module cap**; only a successful generation does.

## Rate limits

| Limiter | Limit |
| - | - |
| Run creation | 10/min per account |
| Concurrency | 3 starter / 2 deep analyses in flight per account (single runs; batches are bounded by size) |
| Batch creation | 10/min per account |
| Agency creation | 10/min per account (shared with Run creation) **and** 10/min per Agency workspace |
| Enrich | 12/min per account + analysis |
| Daily ceiling | Rolling 24h cap on run creation per account (`429 DAILY_LIMIT_REACHED`, `limit` field) |

Rate limits key on your account, not on the individual API key or the caller IP, so neither rotating IPs nor creating extra keys widens any window - every key on an account draws on one shared budget. Repeated *failed* authentications are the exception: those are throttled per IP, since there is no account to attribute them to. Calls arriving through the [hosted MCP server](/mcp-server) are exempt from the per-IP budgets - every remote MCP user would otherwise share that server's single egress IP - but they are not exempt from the limits above. An MCP connector holds a key on your account like any other, so its runs draw on the same per-minute windows and the same daily ceiling as your direct API calls.

A `429 RATE_LIMITED` from any of these limiters carries a `Retry-After` header with the exact number of seconds until the window resets. See [Errors](/errors).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.