The Only API exposes Fansly through the same normalized CRM surface used for OnlyFans. Your application can list accounts, read chats and messages, inspect synced transactions, and build cross-platform reporting without translating every response into a second data model.
Normalization does not mean every platform feature is identical. The raw /api2/v2 passthrough is OnlyFans-only, and several Fansly write or real-time capabilities are intentionally gated. This quickstart stays inside the supported CRM layer.
Before you connect
Create a panel, store its CRM ID and API key in a server-side secret manager, and use a test Fansly creator account. Never collect creator credentials in a client-side application or log them.
The safest path for a human operator is the dashboard Accounts flow. It handles password login, a possible 2FA challenge, slot checks, and connection state. Developers automating an internal onboarding flow can use POST /accounts/login with platform set to fansly, but must apply the same credential controls.
{
"email": "[email protected]",
"password": "read-from-a-secret-store",
"platform": "fansly"
}The email field can also contain a Fansly username. A successful response returns platform=fansly and an of_user_id; normalized routes use that field name for both platforms.
Handle 2FA as a state transition
If the response contains requires_2fa=true, do not repeat the password request. Prompt the operator for the current code and POST it to /accounts/login/verify-otp with the same identifier and platform=fansly.
{
"email": "[email protected]",
"otp_code": "123456",
"platform": "fansly"
}The parked challenge expires. If verification reports that the session is missing or expired, restart login instead of retrying the same code indefinitely.
Some accounts can require email verification rather than a numeric 2FA code. In that case the API returns an explicit verification state; the operator must complete the platform step or use the supported token connection path.
Confirm the account
curl "https://theonlyapi.com/api/crm/$ONLY_API_CRM_ID/accounts" \
-H "X-API-Key: $ONLY_API_KEY"Select the item whose platform is fansly and store its of_user_id as the account identifier. Avoid choosing the first account in a mixed panel.
Read conversations
The same normalized chat routes work for Fansly:
curl "https://theonlyapi.com/api/crm/$ONLY_API_CRM_ID/accounts/$ACCOUNT_ID/chats?limit=20&offset=0" \
-H "X-API-Key: $ONLY_API_KEY"Then read a conversation with GET /accounts/{of_user_id}/chats/{with_user_id}/messages. Follow hasMore rather than assuming that a short page is the end.
One-to-one text DMs are supported through the normalized send route. Media upload and attachments are not currently wired for Fansly, and mass messaging is not equivalent to one-to-one send. Design the UI from the capability matrix instead of displaying a control that will return PLATFORM_NOT_SUPPORTED.
Read transactions and subscribers
Fansly wallet transactions sync into the normalized transaction cache. Start a refresh when needed, wait for the asynchronous job, then read GET /accounts/{of_user_id}/transactions/cached with limit and offset.
Subscriber sync is also platform-aware, but Fansly fields and lifecycle semantics differ from OnlyFans. Use the normalized cached response and its status fields; do not apply OnlyFans-only raw payload assumptions.
Understand real-time availability
On-demand reads can work while Fansly background polling or the real-time WebSocket listener is disabled at deployment level. Check account capability and polling state before promising instant updates. The Fansly webhooks and automations guide shows how to build a truthful fallback.
Build one platform-aware client
Store platform on every account and every platform-owned record. Route normalized features through shared code, then gate platform-specific actions explicitly. Never send a Fansly account ID to the OnlyFans-only /api2/v2 passthrough.
For the complete schema, follow building a multi-platform CRM. To keep scheduled reads safe, apply the rate limits and polling guide. The broader Fansly API overview, current documentation, and pricing should be reviewed together before production onboarding.
