A multi-platform CRM should make common work feel consistent without pretending OnlyFans and Fansly are identical. The durable design is a normalized core plus explicit platform capabilities and raw identifiers at the edges.
This guide focuses on the data and job architecture behind an agency inbox, fan roster, earnings view, and automation system.
Start with tenant isolation
Every business object belongs to a tenant or CRM panel. Put crm_id in the primary access path for accounts, fans, conversations, messages, transactions, events, tags, and automation runs. Enforce tenant predicates in database queries rather than filtering after data is loaded.
API keys must resolve to exactly one tenant. Background jobs should carry the tenant and account identifiers in their payload. Never trust a client-supplied crm_id without verifying it against the credential.
Model accounts with platform identity
A minimal account record needs:
| Field | Purpose |
|---|---|
| crm_id | Tenant boundary |
| account_id | Your internal stable key |
| platform | onlyfans or fansly |
| platform_account_id | The normalized of_user_id value |
| username | Display and lookup |
| connection_status | Healthy, gated, disconnected, or error |
| last_synced_at | Freshness shown to operators |
| capabilities | Supported, limited, or unavailable features |
Use a unique constraint on crm_id, platform, and platform_account_id. Never assume IDs are globally unique across platforms.
Separate people from platform identities
One human fan can appear on both platforms, but usernames are not proof of identity. Create a platform_identity record for each observed account. Add an optional person record only when an operator has a legitimate, documented reason to link identities.
This avoids accidental cross-platform profiling and prevents a username collision from merging private conversations.
Normalize conversations and messages
The shared conversation table should carry tenant, creator account, platform identity, last-message time, unread state, and platform conversation ID. Messages need direction, created time, text, price/tip flags where supported, and the immutable platform message ID.
Preserve a compact raw_payload only when necessary for debugging or fields not yet normalized. Encrypt sensitive data at rest, define retention periods, and restrict who can search message content.
The Python API tutorial and Node.js tutorial show how to page through normalized chats safely.
Use a signed transaction ledger
Do not calculate earnings by blindly summing amount. A chargeback can be represented by a status change on the original row rather than a second negative row. Normalize a signed amount based on documented status, retain the original status, and make the platform transaction ID unique per creator account.
Maintain derived daily aggregates separately and rebuild them from the ledger when logic changes. This makes accounting corrections auditable.
Store capabilities as data
Feature flags should not be scattered across UI conditionals. Return a capability map such as:
{
"chats_read": "supported",
"dm_text_send": "supported",
"media_upload": "unsupported",
"mass_message": "unsupported",
"background_polling": "limited"
}The backend remains authoritative. The frontend uses the map to hide, disable, or explain an action. A 501 PLATFORM_NOT_SUPPORTED response should still be handled because capability state can change between render and action.
Review the Fansly quickstart for current platform boundaries and the Fansly automation guide for collector availability.
Design an idempotent sync pipeline
Use one queue job per tenant, account, and resource. Claim jobs with a lease so workers cannot sync the same resource concurrently. Each page follows this transaction:
- 1.Fetch a page using the stored cursor.
- 2.Normalize and upsert records by platform ID.
- 3.Update aggregates affected by those records.
- 4.Commit the next cursor and last-success timestamp.
- 5.Emit internal change events after the commit.
If the job crashes, repeating the page is safe. Add jitter, bounded retries, and per-account concurrency limits from the safe polling guide.
Combine webhooks with reconciliation
Consume signed webhooks into an inbox table with a unique delivery ID. Process them asynchronously, then run slower scheduled reconciliation against messages, subscribers, and transactions.
Store platform on every event. Monitor freshness and delivery health separately for OnlyFans and Fansly so one healthy collector cannot mask the other.
Build operator-safe writes
Writes need stronger controls than reads:
- An account-level enable switch.
- Role-based authorization.
- Preview for bulk audiences.
- Idempotency or duplicate-send protection.
- An immutable audit record.
- Explicit platform capability validation.
For messaging, separate drafting, approval, scheduling, and sending. A retry worker must know whether the upstream action completed before it repeats anything.
Report freshness, not just data
Every dashboard card should say when it was last updated and whether it came from cached, live, or partial data. Show an actionable state for 2FA, verification, rate limiting, disabled polling, and unsupported features.
This is especially important in a mixed roster: an agency total is misleading if five Fansly accounts are stale while OnlyFans accounts are current.
Rollout checklist
- Test one account per platform.
- Reconcile normalized output against each platform UI.
- Load-test with cached fixtures, not uncontrolled platform traffic.
- Verify tenant isolation with negative tests.
- Exercise 429, 401, 403, 501, timeouts, and duplicate events.
- Measure sync lag, queue age, error rate, and stale-account count by platform.
- Document retention, export, and deletion behavior.
Explore the OnlyFans API and Fansly API, verify current contracts in the documentation, and model account costs with pricing. The normalized layer removes repetitive integration work, but a trustworthy CRM still makes platform differences visible.
