Rate Limits
The API applies tiered rate limits at the application layer. HTTP API requests and MCP tool calls use the same API key, tier permissions, and rate-limit bucket.
Production Tiers
| Tier | Limit | Bucket | Notes |
|---|---|---|---|
| Public | 5 per 7 days | Per IP | No key required. |
| Registered | 20 per 7 days | Per API key | Free self-serve signup tier. |
| Paid | 500 per 7 days | Per API key | Paid parser tools, extraction caches, and warm workflows. |
MCP traffic is not a separate quota. If an agent calls get_metric through MCP and a script calls /api/metric with the same key, both requests draw from the same tier bucket.
Playground Limits
The playground is a shared demo surface for warm-cache inspection. It is intentionally tighter than production keys and adds a fixed-window session bucket so direct shared-key calls cannot bypass visitor-level throttling.
| Limit | Purpose |
|---|---|
| Per-IP SlowAPI bucket | 30 requests per hour from one address |
| Per-session fixed window | 10 requests per hour for a browser or direct caller using X-Playground-Session |
| Cache-only guard | Blocks cold work before fetch, parse, or LLM calls can run |
Production Guidance
- Treat 429 responses as retry-after events, not parser failures.
- Use registered or paid keys for workflows that need repeated period sweeps.
- Prefer
get_metric_seriesover many single-periodget_metriccalls when the model needs a time series. - Use one key per deployment or agent pool when you want rate-limit accounting to map cleanly to a consumer.