Account & Billing · 2 min · Updated 2026-08-24

API rate limits

The ingest and API rate limits we actually enforce, and the one cap that is plan-dependent

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.

EndpointLimitCounted per
POST /ingest120 requests/minIngest token
/analytics/*120 requests/minClient IP
/auth/* (login, signup, refresh, password reset)10 requests/minClient IP
GET /entitlements60 requests/minIngest token
Free teardown tool10 requests/hourClient 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.

Track your real costs

Calculators estimate. The dashboard shows what you actually spend and where you can save.