The Fanvue API gives a creator, or an app the creator approves, programmatic access to their own account: chats and mass messages, posts, vault media, custom lists, tracking links, follower and subscriber data, earnings insights and, for agencies, the same operations across the creators they manage. Fanvue's current developer documentation says access works through OAuth 2.0 apps that KYC-verified creators create, and that Fanvue does not use API keys, even though an older Help Centre article still describes an API-key waiting list.
This is not a coding tutorial. It explains what can be automated, what each permission exposes, what Fanvue expects from anyone who ends up holding your data and how to avoid the credential scam Fanvue has warned creators about. If you are still deciding which people should touch your account at all, start with our guide to Fanvue manager accounts.
API keys or OAuth: three documents, three descriptions
Search for the Fanvue API and you will find documents written at different stages of its rollout. They disagree on the most basic question, which is how you get access:
- The Help Centre article Creator Settings: Request API keys says Fanvue does not offer API keys for general use, that a request puts you on a waiting list and that keys are distributed in phases with no set timeline.
- The API Access & Usage Policy, last updated on 5 February 2026, still defines an API key sent in an X-Fanvue-API-Key header, allows one active key per user, fixes a key's scopes when it is issued and says keys cannot be retrieved after creation. It also governs OAuth third-party applications and warns that access may be limited to approved users during rollout.
- The developer documentation answers “Looking for an API key?” by saying Fanvue does not use them: a user authorises an app through OAuth 2.0 and the app receives a short-lived access token. Only creators who have completed KYC can create apps and manage credentials.
Fanvue's May 2026 blog post on the API sides with the documentation: sign up as a creator, complete identity verification, then create an OAuth app. The most sensible reading is that the documentation describes how access works now, the policy sets the rules of use you agree to, and the help article predates the OAuth model. If your own account shows something different, ask Fanvue support before you build anything.
What the API can reach
Every request is checked against scopes, the permissions a user grants an app. The scopes documentation lists them by resource:
| Resource | Scopes | What they open up |
|---|---|---|
| User | read:self | Your own profile and basic account details |
| Chat | read:chat, write:chat | Conversation history, new chats and sending messages |
| Fan | read:fan | Fan-related data held on the platform |
| Creator | read:creator, write:creator | Creator profile, content and creator settings |
| Experience | read:experience, write:experience | Fan-facing experiences delivered through apps |
| Media | read:media, write:media | Vault files, uploads and vault folder management |
| Posts | read:post, write:post | Reading, creating and editing posts |
| Insights | read:insights | Analytics and earnings metrics |
| Tracking links | read:tracking_links, write:tracking_links | Listing, creating and deleting tracking links |
| Agency | read:agency, write:agency | Agency details, team members and invitations |
The policy's list of permitted operations fills in the detail: sending mass messages, managing custom lists and vault folders, reading top-spending fans and subscriber counts and, for agencies, creating posts and running chats for the creators they manage. Two things are missing from that list: changing payout methods, and changing the account's email, password or ownership. Fanvue's payout options article separately says only the creator can manage payout methods.
Use-case table: what to automate and what it risks
| Task | Possible via the API? | Main risk | Permission needed |
|---|---|---|---|
| Earnings and subscriber dashboard | Yes | Revenue data becomes visible to whoever hosts the dashboard | read:insights, read:creator |
| Sync fans into a CRM | Yes | Fans' personal data leaves Fanvue and becomes the app builder's responsibility | read:fan, read:creator |
| Draft and send replies | Yes | Replies go out unreviewed or without a required AI disclosure | read:chat, write:chat |
| Mass message a segment | Yes | A wrong list sends the message to the wrong fans at once | write:chat |
| Publish or schedule posts | Yes | Content that breaks Fanvue rules is published under your name | write:post |
| Upload media to the vault | Yes | Files you lack rights to, or unlabelled AI material | write:media |
| Create tracking links | Yes | Low; mostly clutter and campaigns credited to the wrong source | write:tracking_links |
| Invite agency team members | Yes, for agencies | New people gain access to every managed creator | write:agency |
| Change payout methods | Not listed | Not applicable | None documented |
| Collect other creators' content | No | Breaches Fanvue's bans on scrapers and automated extraction | Not permitted |
Two clauses frame every row. Fanvue's General Terms ban bots, scrapers and automated scripts used to access the platform or get around moderation, pricing or access controls, and say Fanvue is not responsible for tools that are not authorised or integrated through official channels; the API is the official channel. The same terms also forbid accounts controlled by automated means, while Fanvue's own API blog promotes autonomous agents that message fans on a creator's behalf. Keep a person reviewing what any automation sends, and ask Fanvue to confirm in writing before running anything close to fully automatic.
Automation does not change the content rules either. If a workflow writes messages or produces media with AI, Fanvue's disclosure requirements still apply, as our Fanvue AI creator rules explain. And if you are choosing between platforms partly on tooling, our OnlyFans vs Fanvue comparison notes that OnlyFans's Acceptable Use Policy bans scraping its site.
How access works in practice
At a high level, getting from a creator account to a working connection takes six steps:
- Hold a Fanvue creator account and complete KYC; the credentials documentation says fans cannot reach the Builder area at all.
- Create an app in the Builder, also called the Developer Area. Fanvue issues a Client ID and a Client Secret, and the Secret is shown only once, at creation.
- Register the redirect URI your app uses and pick the smallest set of scopes that covers the job; the scopes you select must match the ones your code requests.
- Authorise the app with the account it will act on. The authentication overview says access tokens typically last about an hour and that refresh tokens rotate and can each be used once.
- Test on a separate test creator account; the testing guide says there is no sandbox, so paid flows involve real money.
- If you would rather not write code, the documentation describes an MCP server that connects AI assistants through the same OAuth sign-in, with no keys to paste, plus an n8n integration for low-code workflows.
Rate limits differ between documents too. The policy states 100 requests per 60 seconds per key, while the rate-limit page says the default was raised to 200 requests per 60 seconds for each user of each app, with lower limits on a few endpoints. Whoever builds your integration should read the X-RateLimit headers on each response rather than hard-coding either figure.
The credential scam Fanvue warned creators about
In January 2026, Fanvue's policy changelog reported social-engineering attempts in which malicious services asked creators to create third-party applications and share the credentials, opening the way to unauthorised access to creator accounts and data. The API policy now prohibits creating an app at anyone else's request, sharing client secrets, redirect URIs or webhook callback URLs, and pointing those settings at domains you do not control. Its security section lists the warning signs:
- A chatbot or automated service asks you to create an application for it.
- AI features, automation or analytics are offered in exchange for creating an app.
- Someone asks you for a redirect URI, a webhook URL or a client secret.
- You are pressed to act quickly, or to pass the service on to other creators.
A legitimate service has its own registered app and asks you to connect through the standard Connect with Fanvue sign-in, where you see and approve the scopes it wants. Some third-party dashboards also put Fanvue's name in their branding while stating in small print that they are not affiliated with Fanvue, so read the footer and the consent screen before connecting anything. If you have already created an app for someone, the changelog's recovery steps are to revoke access under Settings > Account > Third Party Apps Consent, delete the app under Creator Tools > Build and contact Fanvue support.
Who is responsible for your fans' data
Once data leaves Fanvue, responsibility moves with it. The data section of the API policy says anyone who builds or operates an app that accesses user data becomes a data controller or processor for it, with duties that include a lawful basis for processing, security measures, limited retention, answering data subject access requests, telling Fanvue about breaches, publishing a privacy policy and complying with UK GDPR, EU GDPR and other applicable law.
When you authorise an app, the policy says the app builder, not Fanvue, controls how your data is used from then on, and that Fanvue's responsibility ends once the data is shared. Connecting Fanvue to outside tools such as Slack, Zapier, CRMs or AI services also makes you answerable for those services' terms, and reselling or redistributing API access or data needs Fanvue's authorisation. For a creator whose agency runs a CRM, that means asking who will hold your fans' data, where it is stored and how it is deleted when the relationship ends. Our guide to choosing a secure agency tech stack covers the questions to put to any tool vendor.
Credential and token checklist
Hand this list to whoever builds or hosts your integration, and tick it off together before the app goes live. It draws on Fanvue's credentials page, its security guide for developers, the authentication overview and the security section of the API policy.
- The Client Secret went into a secrets manager or environment variable the moment it appeared, because Fanvue will not show it again.
- The Client Secret, access tokens and refresh tokens live on a server, never in a browser, a mobile app or a public code repository.
- The app requests only the scopes its features use; a reporting dashboard has no need for write permissions.
- Redirect URIs and webhook callbacks point only at domains you own and control.
- Every incoming webhook is checked against its X-Fanvue-Signature header before anything acts on it.
- After each refresh the new refresh token replaces the old one, and only one refresh runs at a time.
- Development and production use separate apps, and testing happens on a separate creator account.
- Logs never contain tokens, secrets or fans' personal data.
- A register lists each app, who controls it, the scopes it holds and the date it was approved.
- Third Party Apps Consent is reviewed on a set schedule and anything unused or unfamiliar is revoked.
- A leaked or suspect Client Secret is rotated immediately, with a planned cutover because the old secret stops working.
- No app is ever created, and no credential shared, because someone else asked for it.
Limits of this guide
This explainer follows Fanvue's developer documentation, API policy, blog and Help Centre on 1 October 2026. Those documents already disagree about keys and rate limits, and Fanvue says access may be limited during rollout and that API versions are deprecated over time, so check the documentation and your own account before relying on any detail here.
It is not a substitute for a developer reviewing your integration or for legal advice on data protection. If an app will store fans' personal data, have a privacy professional in your jurisdiction review it, and make sure the app is registered by whoever will operate and control it, as the API policy requires, rather than created on someone else's behalf.