OnlyFans Automation: The Complete Guide

OnlyFans automation means moving repetitive account work — replying, broadcasting, scheduling, segmenting — out of a browser tab and into code. The useful question is not "can this be automated" but "does this job have an endpoint behind it, and does automating it pay for the credits it burns". This page answers both against ofapis, a REST automation API at https://api.ofapis.com/api/public/v1 with one Bearer token and per-call billing.

What has an endpoint, and what does not

This is the part most guides skip. Automation is bounded by the API surface, so start from the surface — and use the right-hand column to jump straight to the job you came for:

Two consequences follow. First, tips are not a separate object: a tip arrives as a chat message with isTip: true, so tip handling is message handling, not ledger handling. Second, anything shaped like "automatically optimise sends by revenue per fan" has no input to optimise on — you would have to derive the number yourself from messages you have already read, and store it, before the automation is even possible.

One more boundary worth knowing before you design anything: message.received is the only webhook event type that exists. There is no subscriber.created, no tip.received, no post.published. Every other trigger you want is a polling job you write yourself.

The three tiers, in rising order of risk

Read. Sync chats, subscribers, lists and vault media into your own store. Reads sit at the default weight of one credit per call, change nothing upstream, and are the only tier where a bug is cheap. Everything else depends on it, because you cannot act on fans you have not indexed. This is also the tier where pulling data over an API rather than scraping stops mattering as a philosophical point and starts mattering as an uptime point.

React. Point a webhook at your handler and answer inbound messages. The event carries chatId and the message body, and conveniently the chatId you reply to is the fan's numeric user id — the same id you see as withUser.id in GET /chats — so no lookup step sits between receiving and replying. Webhook deliveries are not API calls, so they cost zero credits; only your reply is billed. Setup is covered in webhook setup.

Write on a schedule. Mass DMs and scheduled posts. Writes are not priced like reads, so this is where money is made and where money is lost. POST /accounts/{id}/scheduled/posts and .../scheduled/messages weigh 3 credits each, POST /accounts/{id}/chats/{chatId}/messages weighs 2, POST /accounts/{id}/media weighs 5. The plain unscoped reply, POST /chats/{chatId}/messages, stays at 1. And a mailing trigger weighs 0 on the call itself, then debits one credit per recipient — full table in the credit model.

The first automation that pays for itself

A welcome DM to new subscribers. It is the highest-value automation on almost every account and — because there is no subscriber event — it is a polling diff, not a webhook. The detection variants and the ledger that stops a fan being greeted twice are covered in welcome message automation; the short version:

import os, time, requests

BASE = "https://api.ofapis.com/api/public/v1"
H = {"Authorization": f"Bearer {os.environ['OFAPIS_TOKEN']}"}
ACCOUNT = 42

seen = load_seen_ids()                   # from your DB, never an in-process set
while True:
    # GET /accounts/{id}/subscribers?type=active&limit=100&offset=…, paged on hasMore/nextOffset
    current = set(active_subscriber_ids(ACCOUNT))
    fresh = sorted(current - seen)
    if fresh:
        send_at = time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime(time.time() + 120))
        requests.post(
            f"{BASE}/accounts/{ACCOUNT}/scheduled/messages",   # 3 credits per call
            headers={**H, "Idempotency-Key": f"welcome:{ACCOUNT}:{fresh[0]}:{len(fresh)}"},
            json={"text": "Thanks for subscribing — tell me what you're into 🙂",
                  "price": 0, "userIds": fresh, "scheduledAt": send_at},
        ).raise_for_status()
    save_seen_ids(current)
    time.sleep(300)

Three details that are load-bearing. seen must be durable — an in-memory set re-greets your entire fan base after a restart, which is the single most common way this automation gets an account reported. scheduledAt must be a future ISO-8601 instant or the call returns 400, and a 400 is charged, not refunded. And the Idempotency-Key means a retried POST replays the original response with Idempotency-Replayed: true instead of sending the DM twice.

Paging and the {"data": {"list", "hasMore", "nextOffset"}} envelope behind active_subscriber_ids are in the subscribers API; the full version of this job, including copy and send windows, is in welcome message automation.

What it costs to leave running

Credits are the real constraint, not rate limits. One GET /subscribers page is one credit, so the loop above at a five-minute interval is 288 calls a day, about 8,700 a month, for a single creator with under 100 active fans. A creator with 1,400 fans needs 14 pages per sweep and burns roughly 120,000 credits a month — the entire Pro allowance — doing nothing but looking for new subscribers.

The fix is not a bigger plan, it is a cheaper loop: sweep page one every five minutes and the full list once an hour, since new subscribers land on the first page. That drops the same job to about 9,000 credits a month. Run the arithmetic before you ship any always-on poller; the credit model rewards sharp intervals and punishes lazy ones.

Rate limits are a separate budget: 60 requests per minute on Free, 100 on Starter, 500 on Pro, counted per token per minute. A 429 is rejected at the gateway before anything is metered, so throttling costs you latency, not credits — see rate limits for the backoff you should be using.

What to automate second

Once welcomes are live, the ranking that holds for most accounts is: the re-engagement bump to fans who have gone quiet, the content calendar, then segmented drops. Chat automation comes last and comes partial — route and draft with chatter software, but keep the human on the close. If you are running this across several creators rather than one, the staffing, handoff and ledger side is on running an agency. Full details of every route are in the API documentation.

What you should not automate

Pricing negotiation inside a DM. Any decision that needs a number the API does not expose. And any send you have not costed: a mailing to 5,000 recipients debits one credit per recipient — 5,000, not one — so a blast you fire by reflex is a four-figure credit event. Always POST .../preview first and read estimatedCost back before you trigger.

Retrying a trigger is the other thing to keep out of a retry loop. The 409 guard only covers a mailing that is still IN_PROGRESS; trigger one that has already completed and it recounts the audience, debits again and sends the message a second time. Guard that call in your own code, not in the API's.

FAQ

Can you automate OnlyFans DMs?

Yes. You can read threads with GET /chats/{chatId}/messages, reply with POST /chats/{chatId}/messages, and DM fans who have no open thread by passing their userIds to POST /accounts/{id}/scheduled/messages. You cannot automate judgement — keep a human on pricing and anything a fan would notice as scripted.

Is there an OnlyFans webhook for new subscribers?

No. message.received is the only event type ofapis emits, so new-subscriber detection is a polling diff against GET /subscribers?type=active. Any vendor advertising a long menu of event types is describing something they have not built.

How many credits does an always-on automation use?

A read weighs one credit, so the polling interval sets that part of the bill: a five-minute poller is roughly 8,700 calls a month per page fetched, against 30,000 credits on Starter and 120,000 on Pro. Writes weigh more — 3 for a scheduled post or message, 2 for an account-scoped chat message, 5 for a media upload. Mass DMs are the real exception: the trigger call itself weighs 0 and then bills one credit per recipient, so one blast can cost more than a month of polling.

What can't be automated through the ofapis API?

Anything without an endpoint: earnings and statistics, tracking links, the public post feed, and transaction history. Tips are visible only as chat messages flagged isTip. If a workflow depends on one of those numbers, you have to derive and store it yourself from data you have already pulled.

Do I need to write code to automate OnlyFans?

Not necessarily — the API is plain Bearer-authed HTTP, so Make, n8n and Zapier can drive it with no custom connector. Code becomes worthwhile once you need durable state, such as the seen set above, which a no-code flow handles badly.

Pick the page for your job: welcome DMs · auto-reply bot · mass DM API · PPV campaigns · post scheduling · fan segments and lists · multi-account agency setup · the full route surface · plans and allowances