Docs
Reference
Rate Limits

Rate Limits

All API endpoints are rate-limited per API key. Two independent limits apply: a request-count rate limit (DoS guardrail) and a daily usage cap (spend ceiling).

Request-count limits

TierRequests/minRequests/day
Free6010,000
Pro300500,000
Max300500,000
EnterpriseCustomCustom

Daily usage cap

Each tier has a daily usage cap well above normal use (Max's is 4x Pro's; Enterprise has none). Grandfathered Starter keys keep their existing request limits (120 requests/min, 50,000 requests/day).

The daily usage cap prevents runaway agent costs. When the cap is reached, the API returns 429:

{
  "error": "Daily usage cap reached",
  "error_code": "daily_cap",
  "tier": "pro",
  "resets_at": "2026-04-22T00:00:00.000Z"
}

The cap resets at midnight UTC.

Rate limit headers

Every API response includes standard rate limit headers:

HeaderDescription
RateLimit-LimitMaximum requests per window
RateLimit-RemainingRequests remaining in current window
RateLimit-ResetUnix timestamp when the window resets

Exceeding the limit

If you exceed the per-minute rate limit:

{
  "error": "API rate limit exceeded. Please slow down.",
  "retry_after_seconds": 60
}

If you exceed the per-day limit:

{
  "error": "Daily API limit reached. Upgrade your plan for higher limits.",
  "retry_after_seconds": 3600
}

Back off and retry after the retry_after_seconds interval. See Errors for full retry guidance.

Best practices

  • Cache responses - Follow data updates periodically, not in real time. Caching responses for 30-60 minutes is usually sufficient.
  • Use time windows - Query with ?since=24h instead of polling every minute. See Parameters for supported formats.
  • Batch where possible - A single GET /v1/follows/new returns new follows across all tracked accounts. No need to query per-account.
  • Check headers first - Read RateLimit-Remaining before making requests to avoid hitting 429s.
  • Use webhooks - For agent workflows, subscribe to push notifications instead of polling.