---
title: Rate Limits
description: Ceilings by area, headers to watch, and how to behave at the limit.
---

Limits are per account (summed across keys) and sized so a well-behaved agent never notices them.

| Area | Limit | Notes |
|---|---|---|
| All requests | 10,000/day (Free), 100,000/day (Pro) | The global envelope |
| `/context/candles`, `/context/funding` | 60 req/min | Immutable data — cache by `release` and you'll rarely re-fetch |
| `/context/scan`, `/context/setup` | 20 req/min | Recomputed on engine cadence; polling faster returns the same `computed_at` |
| `POST /runtime/backtests` | concurrent cap (2 Free / 6 Pro) | `429 limit_exceeded` when the slots are full |
| `POST /runtime/executions` | venue and account limits apply | Synchronous typed order actions; retries require the same `Idempotency-Key` |
| Deployment polling (`GET :id`, `/metrics`) | 120 req/min | Enough for several bots at seconds-cadence |

## Headers

Every authenticated response carries the state you need to self-regulate:

```
x-ratelimit-limit: 10000
x-ratelimit-remaining: 8114
x-ratelimit-reset: 2026-07-29T00:00:00Z
```

A `429` adds `retry-after` (seconds). Honor it exactly — retrying earlier extends the window.

## Behavior at the limit

- Reads fail fast with `rate_limited`; nothing queues silently.
- **Running deployments never throttle.** Limits govern the control-plane API; your strategy's own venue connection is its own budget, unaffected by how often you poll us.
- Limit counters run on UTC-day boundaries (`x-ratelimit-reset` is always a UTC timestamp). Authenticated requests count whatever their outcome, with two exceptions: `401` and `429` responses don't consume budget — a retry loop can't burn your day.

## Webhooks (committed, post-launch)

Deployment lifecycle events are exactly what webhooks exist for, so they're on the committed roadmap rather than a maybe: a `POST /account/webhooks` endpoint delivering `deployment.started`, `deployment.stopped`, `deployment.error`, `deployment.restarted`, `deployment.expired` (`alive_until` lapse), and `backtest.finished`, signed with a per-endpoint secret. Until it ships, poll `GET /runtime/deployments/:id` at minutes-cadence and `/metrics` only when acting on the answer.