Rate limits & quotas
Per-minute HTTP limits, the monthly call quota, and the platform-side limits we do not enforce for you.
Three separate limits apply, and they are independent of each other.
1. Per-minute HTTP rate limits
Anti-flood protection, applied on every plan. Keyed on your API key (falling back to client IP when no key is present).
| Scope | Limit |
|---|---|
| Default — most reads, and the passthrough | 1000 / minute |
| Sensitive — writes, key management, mass DMs, exports | 100 / minute |
Login — the three connection routes and all four /api/auth/* routes | 20 / minute |
POST /api/auth/login | additionally 6 / minute per email address, stacked on the 20/minute above so an IP-rotating botnet still cannot brute-force one account |
GET /health, GET /events/stream | exempt |
Exceeding one returns:
{ "error": "Rate limit exceeded", "retry_after": "1000 per 1 minute" }with HTTP 429. Current state is exposed on X-RateLimit-* response headers, so
you can back off before hitting the wall.
Fixed window, not sliding
Limits use a fixed window, so a burst that straddles a minute boundary can briefly appear to allow double the nominal rate. Do not rely on that.
2. Monthly call quota
Every counted request increments a per-panel monthly counter.
| Plan | Connected accounts | API calls / month |
|---|---|---|
| Free | 10 | 1,000 |
| Slots — $20/slot/mo ($15 at 15+) | 1 per slot | unlimited |
| Enterprise | custom | custom |
Check consumption:
curl "$BASE/api/crm/$CRM/usage" -H "X-API-Key: $KEY"{
"plan": "slots",
"api_calls_used": 18432,
"api_calls_limit": -1,
"accounts_used": 3,
"accounts_limit": 15
}GET /api/crm/{crm_id}/usage is authoritative for your panel — read it rather than
assuming plan defaults. An api_calls_limit of -1 means unlimited. Exhausting a
finite quota returns 429.
Quota is not charged on every request: only calls that actually reach the platform count. Cached reads, async-job status polls and background polling are free.
Adding an account beyond your slot count returns 403 (not 429):
{ "error": "Account limit reached (1). Buy a slot to add another account.", "accounts_limit": 1 }3. Platform-side limits — your responsibility
This is the one that actually gets accounts banned, and we do not enforce it for you.
OnlyFans and Fansly rate-limit per account. Bursts of roughly 1 request/second
are fine; sustained traffic above about 5 requests/second will get an account
flagged. Every /api2/v2/* call and every live (non-cached) CRM read reaches the
platform.
Pace your live calls
Prefer the /cached routes, which serve from our own store and cost zero
platform requests:
/subscribers/cached · /subscribers/new · /subscribers/stats ·
/transactions/cached · /fans/{fan_id}/transactions/cached ·
/campaigns/{campaign_id}/claimers/cached
Refresh them on a schedule with the async refresh jobs rather than reading live in a loop. See Cached reads.
Handling 429 correctly
import time, requests
def call(session, method, url, key, **kw):
for attempt in range(6):
r = session.request(method, url, headers={"X-API-Key": key}, timeout=60, **kw)
if r.status_code != 429:
return r
# Prefer the server's hint; otherwise back off exponentially.
wait = float(r.headers.get("Retry-After") or 2 ** attempt)
time.sleep(min(wait, 60))
return rDistinguish the two 429 causes before retrying: a per-minute limit clears
within the minute, but an exhausted monthly quota will not clear by retrying
at all. Check the error string, or call /usage.
Exemptions
Panels can be granted a rate-limit exemption or a quota override. Both are set server-side by us, not through the API — contact support if your workload needs one.