Rate limits

Request and concurrency limits by plan.

Request limits by plan

These limits describe how many requests your plan can admit across endpoints. They do not guarantee fresh-data delivery at that speed on any one endpoint. Account limits are shared by your keys; source capacity is shared across customers.

PlanRequests/min per keySimultaneous per keyRequests/min per accountSimultaneous per account
Free6005060050
Starter600501,200100
Pro1,200751,800125
Growth1,8001002,400150
Business2,4001503,600200

Limits use a sliding 60-second window. Both the key and its account must have room; adding keys does not increase the account ceiling. Business allows up to 40 requests a second per key and 60 across the account on average; bursts can still reach either ceiling. Exceeding either answers 429 RATE_LIMITED with a retry-after header holding the seconds to wait — nothing is charged. REST, MCP and dashboard requests share these buckets. A refusal names which limit was met in error.details.scope.

Monthly and annual subscriptions receive the same request limits. An upgrade takes effect when the subscription becomes active; a scheduled cancellation keeps its limits until the paid period ends. Complimentary subscriptions use their assigned tier. Purchased credits increase your balance, not your request limits. Accounts with legacy paid access but no current subscription retain Starter limits.

These are API admission ceilings, not guaranteed throughput for every endpoint. Source-specific rate limits, included allowances, concurrency and spending protections still apply across all customers. Slow or capacity-limited sources may need lower concurrency and backoff.

JavaScript — bounded backoff
async function callWithBackoff(url, init, tries = 5) {
  for (let attempt = 1; ; attempt++) {
    const res = await fetch(url, init);
    if (res.status !== 429 && res.status !== 503) return res;
    if (attempt >= tries) return res;
    const after = Number(res.headers.get('retry-after') ?? 2 ** attempt);
    await new Promise((r) => setTimeout(r, after * 1000));
  }
}

Planning fresh-data workloads

Requests per minute counts how many calls start in a time window. Concurrency counts calls still running. A slow request occupies a concurrency slot for longer; allowing more simultaneous calls does not raise a source’s per-minute allowance.

For example, a source allowing 20 requests per minute has 20 shared slots, not 20 per customer. Ten customers sending equal traffic to it would share those slots. One API request may also need multiple source calls for pagination, retries or combined results. Cached results avoid those source calls.

A higher plan gives your account more API headroom. It does not reserve dedicated source capacity or make every endpoint faster. There is no useful single average speed across all endpoints: a batch focused on one limited source behaves differently from requests spread across several sources.

Explicit forced refresh (fresh=1 or no-cache) has a separate limit of 30 requests per minute per key on every plan. Ordinary cache misses and expired entries also fetch fresh data without using that forced-refresh bucket.

Start with low concurrency, honor retry-after, and increase gradually for your actual endpoint mix. A rate refusal is not a queued request: your client must retry. Check endpoint capacity notices and contact us before planning sustained bulk traffic.

Free accounts

Free accounts share a limit of 600 supplier-backed requests per minute and 50 concurrent requests across API keys, the dashboard, MCP and scheduled monitors. Creating another key does not increase it. Cached results do not consume supplier capacity.

Free accounts also have a daily allowance of up to 300 supplier attempts. Retries and failed upstream calls count toward this protection, but failed calls do not spend your monthly credits. Shared free-service capacity can temporarily pause new work; retry later. Paid subscriptions have separate capacity.

Active complimentary subscriptions receive subscription capacity too. Daily allowance refusals identify the account or shared capacity limit and give the midnight UTC reset time. Zero-credit catalogue reads (utility/endpoint, utility/endpoints, utility/quickstart and utility/llms) use the general key and account limits without consuming Free scraping capacity.

A verified, non-disposable email is required for the 150 free credits. If an address is incorrectly flagged, contact support. Account settings and monitor controls remain available.

Headroom headers

Routed JSON responses report the tightest remaining headroom among the key and account limits applied to this request. Free supplier-backed calls also include the Free account limits; cache hits and catalogue reads use the general limits. Early refusals, batch wrappers, SSE and idempotent replays may omit these headers. Request rate and concurrency are separate limits and can have different scopes.

HeaderMeaning
x-ratelimit-limitThe constraining request-window cap for your plan. The scope header identifies the bucket.
x-ratelimit-remainingRequests still available after admitting this request.
x-ratelimit-scopekey, account or free-account.
x-ratelimit-resetUnix time, in seconds, at which the oldest request in the window ages out and a slot returns.
x-concurrency-limitThe constraining in-flight cap for your plan. The scope header identifies the bucket.
x-concurrency-scopekey, account or free-account.
x-concurrency-remainingIn-flight slots still free as this request entered.
x-ratelimit-key-limit / x-ratelimit-account-limitBoth plan request ceilings, even when the other bucket has less remaining headroom.
x-concurrency-key-limit / x-concurrency-account-limitBoth plan concurrency ceilings.

On a 429 the refused ceiling reads 0 remaining and retry-after says how long to wait: until the window resets for the request rate, one second for concurrency, because a slot frees the moment any in-flight request returns. If the shared limiter store is unreachable, production refuses admission with a 503 until shared limits can be enforced again. No credits are charged.

Monthly credit allowance

Your subscription provides one monthly credit allowance. There is no additional rolling monthly limit on social-content or transcript requests. Requests pause when your credits run out; upgrade your plan or wait for the next monthly reset.

Request and concurrency limits still apply, including to retries. Failed requests consume no customer credits.

Measured workload and launch guidance

On 15 September 2026, a six-minute production test completed 1,800 requests at five requests per second with no errors: 80% cached social-profile reads and 20% account-balance reads. The observed p95 was 144 ms for cached reads and 164 ms for balance reads, from one test client.

This test does not establish uncached scraping throughput, burst capacity, a daily request guarantee or a number of supported users. Start with low concurrency, honor retry headers and increase traffic gradually. Check each endpoint for limited-capacity notices before bulk or scheduled use. Contact support to review sustained workloads.

Other 4xx/5xx you should plan for

503 with retry-after also appears when an endpoint’s upstream is failing and its circuit breaker is cooling down — same backoff handling as a 429. Per-key spending limits (set per key in the dashboard) answer 402 KEY_LIMIT_EXCEEDED. The full roster with remedies is on the Errors page.

First call in under a minute

150 free credits and a ready-made key the moment you sign up. No card.