# The Only API — OnlyFans & Fansly API **200+ endpoints** for agencies and developers: CRM routes plus OnlyFans passthrough routes. One API key, two platforms — **OnlyFans and Fansly via one normalized API**. Your CRM panel is the tenant boundary. Each panel manages a set of connected creator accounts (one "slot" per account), each with its own persisted session and proxy. ## Platform support: OnlyFans and Fansly Every connected account has a `platform` of either `onlyfans` or `fansly`. All three connection routes — `POST /accounts/login`, `POST /accounts/login/cookies`, `POST /accounts/login/verify-otp` — accept a `platform` field in the request body (`"onlyfans" | "fansly"`, default `"onlyfans"`). Once connected, the account id is returned as `of_user_id` regardless of platform. That same value is the `{of_user_id}` path parameter and the `user-id` header everywhere in this spec. **Which surface supports which platform:** | Surface | OnlyFans | Fansly | | --- | --- | --- | | CRM data routes (`/accounts/...`, `/fans`, `/events`, `/webhooks`, `/automations`, `/exports`) | yes | yes | | Transparent passthrough (`/api2/v2/*`) | yes | **no — rejected** | | `POST /accounts/{of_user_id}/payout-requests`, `/campaigns/{campaign_id}/claimers` | yes | **no — rejected** | Requests to `/api2/v2/*` carrying a `user-id` that belongs to a Fansly account are rejected with an `unsupported` error. Use the platform-neutral CRM data routes instead (`/notifications`, `/balances`, `/chats`, `/purchases`, `/subscribers/cached`, ...), which are Fansly-aware. ## Two surfaces ### 1. Transparent passthrough — `/api2/v2/*` (OnlyFans only) A thin, signed proxy. OnlyFans' own response body is passed through unchanged, but always wrapped in a small envelope: every `/api2/v2/*` response is `{ success, status_code, data }` (plus `relogin: true` when the session was refreshed mid-request). Check `success` first, then read the OnlyFans payload -- including `list`/`hasMore` on paginated endpoints -- from `data`. On error, `success` is false, `status_code` carries the upstream HTTP status, and `data` holds an `error` object with `code` and `message`. Throughout this spec, each `/api2/v2/*` response schema describes the shape of `data` (see the `OFPassthroughEnvelope` schema, and the vault endpoints for worked examples that show the full envelope). OnlyFans' API requires **signed headers** (`sign`, `time`, `app-token`) that rotate constantly, plus a live session cookie, plus a residential/datacenter proxy. We handle all of that. You hit our endpoints with a single `X-API-Key` + a `user-id` header, and we: 1. Load the saved session for that account (cookies, `x-bc`, `x-hash`) 2. Route the request through the account's proxy (so OF sees the same IP that logged in) 3. Generate fresh signed headers server-side using the current OF signing algorithm 4. Forward to `onlyfans.com/api2/v2/...` 5. Return the raw JSON response ### 2. Normalized CRM layer (OnlyFans + Fansly) On this surface responses **are** normalized — OnlyFans and Fansly rows are projected to the same shape, and several routes are server-side aggregations with no platform equivalent to pass through: - **Cached reads that cost zero platform requests** — `/subscribers/cached`, `/subscribers/new`, `/subscribers/stats`, `/transactions/cached`, `/fans/{fan_id}/transactions/cached`, `/campaigns/{campaign_id}/claimers/cached` - **Async refresh + backfill jobs** — `POST /subscribers/refresh`, `POST /transactions/refresh`, `POST /campaigns/refresh`, `POST /backfill`. Each returns `202`; poll the matching `/refresh/status` route or listen on `GET /events/stream`. - **Cross-account earnings aggregation** — `GET /earnings/summary` - **Fan CRM** — `GET /fans` with tags, notes, and per-fan cached transactions - **Messaging** — `/chats`, `/chats/{with_user_id}/messages`, `POST /messages/mass` (mass DMs), `/ppv-stats` - **Data export jobs** — `/exports`, producing a downloadable ZIP - **Webhooks** — `/webhooks` with a delivery log and test fire - **Automations** — event-triggered actions, `/run-now`, run history - **Real-time events** — `GET /events` (poll) and `GET /events/stream` (SSE) - **Hosted MCP server** — `GET /api/whoami` resolves an API key to a panel; `PATCH /api/crm/{crm_id}/mcp/unsafe-proxy` toggles whether the MCP server may issue non-GET requests (off by default) Also included: session management with automatic re-login, per-account proxy routing, and server-side request signing — the combination behind our zero-ban track record. ## Connecting an account ### (A) Session paste — recommended **OnlyFans** — grab the session cookies (`sess`, `auth_id`, optionally `fp`) from a logged-in browser (**DevTools → Application → Cookies → onlyfans.com**), send them once with a proxy, and we store the session server-side. You never pass cookies again. ``` POST /accounts/login/cookies X-API-Key: X-Proxy: http://user:pass@host:port (required for OnlyFans) { "platform": "onlyfans", "sess": "", "auth_id": "", "fp": "" } ``` **Fansly** — paste an auth token instead of cookies. `X-Proxy` is optional here. ``` POST /accounts/login/cookies X-API-Key: { "platform": "fansly", "auth_token": "", "fansly_session_id": "", "fansly_client_id": "" } ``` Proxies can be HTTP or SOCKS5 — `socks5://user:pass@host:port` (or `socks5h://` for proxy-side DNS) works anywhere a proxy is accepted. ### (B) Credentials (email/username + password) We handle the full login flow: Cloudflare init, Turnstile solve, signed login request, 2FA prompt if required. ``` POST /accounts/login X-API-Key: X-Proxy: http://user:pass@host:port (required for OnlyFans, optional for Fansly) { "platform": "onlyfans", "email": "...", "password": "...", "use_captcha": true } ``` For `platform: "fansly"` the `email` field accepts a **username or an email**. If the platform demands 2FA, the response includes `requires_2fa: true` (Fansly additionally returns `twofa_type`). Submit the code via `POST /accounts/login/verify-otp`, passing the same `platform` and the same identifier you logged in with, plus an `X-Proxy` header. ## Using the passthrough after connection Once an OnlyFans account is connected, every `/api2/v2/*` request needs: - `X-API-Key: ` — **required** - `user-id: ` — **required**; which account to act as. Omitting it returns `400 user-id header is required`. - `X-Proxy: ` — optional; overrides the proxy saved at login time The URL path mirrors the OnlyFans endpoint: ``` GET /api/crm/{crm_id}/api2/v2/users/me GET /api/crm/{crm_id}/api2/v2/subscriptions/subscribers?limit=10&type=active POST /api/crm/{crm_id}/api2/v2/chats/{fan_id}/messages (body: { "text": "hi" }) ``` Full working example: ```bash curl "https://theonlyapi.com/api/crm/crm_abc123/api2/v2/users/me" \ -H "X-API-Key: " \ -H "user-id: 482687148" ``` That's it. No cookie header, no signing, no proxy rotation — the saved session does the work. There is **no** cookie-bootstrap on this surface: the account must already be connected via `POST /accounts/login` or `POST /accounts/login/cookies`, otherwise the call returns `403 Account not found or does not belong to this CRM panel`. ## Picking an account from your panel `GET /accounts` lists connected accounts and their ids. Add `?include_session=true` and each entry also carries a `session` block with `sess`, `auth_id`, and `proxy`. Either use those values directly, or just pass the `of_user_id` as the `user-id` header and let us resolve the rest. `DELETE /accounts/{of_user_id}` disconnects an account and frees its slot. ## Session lifecycle Sessions are persisted per CRM panel. If the platform invalidates a session (password changed, suspicious-activity lockout), we auto-retry with stored credentials when possible. If re-login fails, the endpoint returns `relogin_failed` — reconnect the account. ## Authentication & API keys Send `X-API-Key` on every request. Keys are tied to your CRM panel — losing one is like losing a password. A panel has one **primary** key (named `Default`) plus unlimited **secondary** keys: - `GET /api-keys` — list all keys (active + revoked) with usage counts. Full key bodies are never returned. - `POST /api-keys` — mint a secondary key. **Primary key only.** The full key is returned **exactly once**, in this response, and is never retrievable again. - `DELETE /api-keys/{key_id}` — revoke a secondary key. **Primary key only.** The primary `Default` key cannot be revoked — rotate it instead. - `GET /api-keys/{key_id}/usage` — per-key usage detail (30/90-day series, month + all-time totals, endpoint breakdown). - `POST /rotate-key` — rotate the caller's own key. The old key dies immediately; the new key is returned once in the response body. Calling `POST /api-keys` or `DELETE /api-keys/{key_id}` with a secondary key returns `403`. `GET /api/whoami` resolves an API key to its `crm_id` — this is how the hosted MCP server turns a bearer token into a tenant. ## Webhook signature verification Every webhook delivery is a `POST` to your URL carrying these headers: | Header | Value | | --- | --- | | `X-OnlyAPI-Signature` | `sha256=` | | `X-OnlyAPI-Timestamp` | Unix timestamp in seconds — the same value that was signed | | `X-OnlyAPI-Event` | The event type, e.g. `new_tip` | | `X-OnlyAPI-Delivery-Id` | Unique id for this delivery attempt | The signed message is **not** the raw body on its own. It is the timestamp, a literal `.`, then the raw request body: ``` message = "{X-OnlyAPI-Timestamp}." + raw_body signature = "sha256=" + HMAC_SHA256(webhook_secret, message).hexdigest() ``` Verify it against the `X-OnlyAPI-Signature` header using a constant-time comparison: ```python import hmac, hashlib def verify(secret: str, timestamp: str, raw_body: bytes, received: str) -> bool: message = f"{timestamp}.".encode() + raw_body expected = "sha256=" + hmac.new(secret.encode(), message, hashlib.sha256).hexdigest() return hmac.compare_digest(expected, received) # timestamp = request.headers["X-OnlyAPI-Timestamp"] # received = request.headers["X-OnlyAPI-Signature"] # raw_body = request.get_data() # bytes, before any JSON parsing ``` Sign the **raw** bytes exactly as received — re-serializing the parsed JSON can change the byte sequence and the signature will not match. ## Base URL `https://theonlyapi.com/api/crm/{crm_id}` `{crm_id}` is your panel ID, found in the dashboard → Settings. Routes that are not scoped to a panel (`GET /health`, `GET /api/whoami`, `POST /api/auth/*`, `POST /api/crm/register`) live at `https://theonlyapi.com` instead and are documented here with their full path. ## Plans & pricing - **Free** — $0/mo. 1,000 API calls/month. Read `GET /usage` for your real `accounts_limit` rather than assuming a slot count. - **Slots** — $20 per slot per month ($15 per slot at 15+ slots). 1 slot = 1 connected account. Unlimited API calls. - **Enterprise** — custom pricing, custom limits, dedicated support. Check current consumption with `GET /usage` (returns `plan`, `api_calls_used`, `api_calls_limit`, `accounts_used`, `accounts_limit`). An `api_calls_limit` of `-1` means unlimited. ## Rate limits Per-minute HTTP rate limits apply on every plan as anti-flood protection, independently of the monthly call quota: - **Default:** 1000 requests/minute - **Sensitive routes** (writes, key management, mass DMs, exports): 100 requests/minute - **Login routes** (`/accounts/login`, `/accounts/login/cookies`, `/accounts/login/verify-otp`): 20 requests/minute - **`POST /api/auth/login`:** 6 requests/minute - **`GET /health`** and **`GET /events/stream`** are exempt Exceeding a limit returns `429`. Platform-side rate limits still apply per account (roughly 1 req/sec bursts are fine, sustained >5 req/sec will get an account flagged) — we don't enforce those, so pace your live calls and prefer the `/cached` routes, which cost zero platform requests.

Register Telegram groups

Authorization

Request Body

Response Body

200application/json

`application/json`