OnlyFans API Rate Limits
OnlyFans API rate limits cap how fast you can send requests, measured in requests per minute (rpm). They are separate from your monthly credit budget: you can have credits left and still be throttled if you burst too hard. ofapis sets the ceiling by plan so a single noisy integration can't destabilize a linked account.
Limits by plan
| Plan | Rate limit | Monthly credits | Linked accounts |
|---|---|---|---|
| Free | 60 rpm | 250 | 1 |
| Starter | 100 rpm | 30,000 | 1 |
| Pro | 500 rpm | 120,000 | 5 |
| Enterprise | Custom | Unlimited | Unlimited |
The rpm ceiling is your burst throughput. Credits are your volume budget over the month. The two can diverge sharply: a mass DM to a segment is a single request regardless of recipient count — so it barely touches your rpm — yet it debits one credit per recipient, so a large blast is cheap against the rate limit and expensive against your credit budget.
What a 429 looks like
Exceed the per-minute ceiling and the API returns 429 Too Many Requests. A 429 is a failure response, so it is not charged a credit. Respect the Retry-After header when present — it tells you how long to wait before the next attempt.
HTTP/1.1 429 Too Many Requests
Retry-After: 8
Correct backoff
Do not retry immediately in a tight loop — that keeps you pinned at the limit. Use exponential backoff with jitter, and honor Retry-After when it is set.
import time, random, requests
def call(session, url, headers, max_retries=5):
for attempt in range(max_retries):
r = session.get(url, headers=headers)
if r.status_code != 429:
return r
wait = r.headers.get("Retry-After")
delay = float(wait) if wait else (2 ** attempt) + random.random()
time.sleep(delay)
r.raise_for_status()
The pattern: check for 429, prefer the server's Retry-After, otherwise fall back to 2**attempt seconds plus a random jitter so parallel workers don't retry in lockstep.
Design to stay under the ceiling
- Prefer webhooks over polling. Subscribing to signed webhooks replaces a stream of poll requests with pushed events, cutting both rpm pressure and credit spend.
- Batch server-side. Send a mass DM to a fan segment as one call instead of looping per recipient.
- Cache slow-changing data. Subscriber lists and profile details don't need re-fetching every second.
- Spread multi-account work. On Pro with 5 accounts, stagger jobs rather than firing all accounts at once.
Rate limits vs. credits
They are enforced independently. Hitting the rpm ceiling returns 429 and you simply slow down. Exhausting monthly credits declines calls until the next refill or an upgrade. Neither charges you for the rejected request. If you routinely brush the ceiling, that's usually a signal to move a polling path to webhooks or to move up a plan — see the cost breakdown.
FAQ
What is the rate limit on the free OnlyFans API plan?
The Free plan allows 60 requests per minute. Starter raises it to 100 rpm, Pro to 500 rpm, and Enterprise is custom. The rpm ceiling is separate from your monthly credit allowance.
Does a 429 response cost a credit?
No. Only successful calls (a 2xx with data) are metered at one credit. A 429 Too Many Requests is a failure response and is never charged.
How should I handle rate limit errors?
Retry with exponential backoff and jitter, and honor the Retry-After header when the response includes it. Never retry in a tight loop, which keeps you pinned at the limit.
Are rate limits the same as my monthly credits?
No. Rate limits (rpm) cap burst throughput per minute; credits are your monthly budget of successful calls. You can be throttled with credits to spare, and you can run out of credits well under the rpm ceiling. See pricing.