OnlyFans API Cost
The cost of an OnlyFans API integration comes down to one question: how many successful calls will your app make per month? ofapis is metered by credit, not by seats, so the bill tracks the work your code does rather than the size of your team. This page explains the model and how to forecast spend — for the plan table itself, see pricing.
What one call costs
A call costs one credit by default, and every read is that one credit — there is no premium tier of endpoints to watch out for. Four writes cost more, because each drives substantially more work upstream:
| Call | Credits |
|---|---|
| Everything not listed below | 1 |
POST /accounts/{id}/media |
5 |
POST /accounts/{id}/scheduled/posts |
3 |
POST /accounts/{id}/scheduled/messages |
3 |
POST /accounts/{id}/chats/{chatId}/messages |
2 |
POST /accounts/{id}/mailings/{id}/trigger |
0 at the call — the run debits per recipient |
The five-credit row is the one that stings when something goes wrong: a 413 on a vault upload is checked inside the handler, after metering, so an oversized file burns all five.
Failures are mostly free, with one edge worth knowing. Credits are taken before a request reaches the handler: a 401, 402, 403 or 429 is refused before that happens, and a 409, 424 or 5xx is refunded automatically — so an expired session or an upstream outage never lands on your invoice, and retrying it costs nothing. A 400, 404, 413, 415 or 422 is charged, because the request was authorised and ran; the payload was the problem. Validate locally instead of probing; the status-by-status breakdown of what refunds and what does not is worth reading before you write a retry loop. Every debit and refund shows in a real-time ledger.
Why per-call, not per-seat
Seat-based "unlimited" pricing hides its cost in per-account fees that grow with an agency roster. Per-call pricing keeps the bill proportional to activity: a dormant creator costs nothing, and a busy one costs in line with its traffic. That changes how you budget a roster — how an agency is actually structured works through the credit maths per creator. The free-failures rule also means OnlyFans-side outages don't land on your invoice.
Estimating your monthly cost
Because credits map one-to-one to actions, you can size a plan straight from your workflow. Three facts drive most of the math:
- A mass DM to a segment is one HTTP request but is billed per recipient —
recipientCount × perRecipientWeight, one credit per fan by default. Runpreviewto see the cost before triggering. - Inbound webhook deliveries are not metered at all, so replacing a poll loop with push removes thousands of empty poll charges and adds nothing back.
- A welcome DM on every new subscriber is cheap per fan but scales with churn, so count it off your signup rate rather than your API traffic.
| Workload | Approx. credits / mo |
|---|---|
| One creator, event-driven via webhooks | 2,000–8,000 |
| One creator, active messaging bot polling | 30,000–60,000 |
| Weekly mass DM to 3,000 fans | ~12,000 (campaign spend alone) |
| Small agency, 5 creators, mixed automation | 80,000–150,000 |
Campaign volume is usually the line that decides your plan: a single weekly blast to a mid-sized audience can outweigh all of your day-to-day API traffic combined. If your calendar is built around scheduled PPV drops, size the plan off the recipient counts in that calendar and treat everything else as rounding.
The single biggest cost lever is polling. Checking one chat every minute is ~43,000 calls a month on its own; moving that path to webhooks can cut it by an order of magnitude.
Mapping cost to plans
| Plan | Price | Credits / mo | Effective ceiling |
|---|---|---|---|
| Free | $0 | 250 | Prototyping |
| Starter | $39 | 30,000 | One active creator |
| Pro | $159 | 120,000 | Up to 5 creators |
| Enterprise | Quote | Volume pricing | High-volume + SLA |
Credits refill monthly. If you exhaust them mid-month, calls are declined until the next refill or an upgrade — nothing is charged past your plan, and upgrades apply immediately.
Credits are your monthly volume budget, and they are not the same ceiling as the per-minute request limit that governs how fast you may spend them; the 60/100/500 rpm windows are a separate constraint you can hit with credits to spare.
Keep the bill down
Prefer webhooks over polling, batch broadcasts server-side, and cache slow-changing data like subscriber lists. Together these usually move a workload down a plan tier. Deciding which jobs are worth running at all is the cheaper lever still — what OnlyFans automation can and cannot do sorts the work that has an endpoint from the work that does not. For the full comparison, see the pricing page or read how the API works.
FAQ
How much does the OnlyFans API cost to start?
Nothing. The Free plan includes 250 credits a month and one linked account with no credit card. Paid plans begin at $39/mo (Starter) and $159/mo (Pro); Enterprise is custom. See pricing.
Do I pay for failed API calls?
Most of them, no — but not all. A 401, 402, 403 or 429 is refused before metering, and a 409, 424 or 5xx is debited then refunded automatically, so expired sessions and upstream OnlyFans errors cost nothing. A 400, 404, 413, 415 or 422 is charged at the endpoint's full weight, because the request ran and the payload was the problem — which means a 413 on a media upload burns all five credits.
What is the cheapest way to run a high-volume integration?
Use signed webhooks instead of polling, and batch broadcasts server-side. Inbound deliveries are not metered at all, so an event costs nothing where the poll that would have found it costs a credit every time it runs — polling is the largest single cost driver for most bots.
Is a mass DM billed per recipient?
Yes. Triggering a mailing debits recipientCount × perRecipientWeight credits — one per fan by default — even though the dispatch itself is a single HTTP request. Call the mailing preview endpoint first: it returns the recipient count and estimated cost before you commit.