Rate limits are the same on every plan
Rate limits are per-endpoint infrastructure limits, not a plan tier. Free, Team and Enterprise organizations all get the same numbers.
| Endpoint | Limit | Counted per |
|---|---|---|
POST /ingest | 120 requests/min | Ingest token |
/analytics/* | 120 requests/min | Client IP |
/auth/* (login, signup, refresh, password reset) | 10 requests/min | Client IP |
GET /entitlements | 60 requests/min | Ingest token |
| Free teardown tool | 10 requests/hour | Client IP |
Batch size
One POST /ingest request carries between 1 and 1,000 events. That is a fixed server-side schema limit and it is identical on every plan.
You rarely need to think about it: the Python wrapper batches for you, flushing every 5 seconds or once 50 events are buffered, whichever comes first (flush_interval_s and flush_threshold). At the default settings, 120 requests/min is roughly 6,000 events a minute per token.
The one limit that is plan-dependent
Free organizations can track 1,000 events per month. The count is server-side, against the time we received the event, and it resets monthly.
Past the cap, /ingest returns 402 Payment Required and the wrapper stops sending for the life of that process - a cap rejection is deterministic, so retrying it would only be noise. Paid plans have no monthly cap.
Exceeding a rate limit
A rate limit returns 429. The wrapper requeues the batch and retries with exponential backoff, starting at 1 second and doubling up to 60. Events wait in a durable local queue (bounded by queue_max_events, 10,000 by default) and go out once the limit resets, so a burst costs you latency rather than data.