Concepts

• Platform account — one connected OnlyFans/Fansly account. Identified by an opaque platform_account_id (prefix pa_) that is never equal to, and never parsed from, a workspace's owner_id — the two are different identifier spaces on purpose, so a mix-up fails closed instead of leaking another tenant's row.
• Connect attempt — a best-effort diagnostic record of one OnlyFans connect try (stage: validated / connected / failed / egress_unverified, plus the proxy verdict and exit IP). It exists so a stuck connect can be diagnosed after the fact — it is not the login flow itself.
• Native login — the actual OnlyFans connect flow: a real browser session walks through consent, progress, and a wait step before landing on done.
• Session lane — the piece of the account-activity system that tracks a live browser session's lifecycle for one connected account.
• Activity lease — a short-lived claim that says a particular process is actively using an account's session right now, so two workers don't step on the same live session.
• Request governor — the queue that decides whose sync work runs next for a given account: claim → reservation → spread, so heavy fan scans don't starve each other or the live UI.
• Browser profile — the persistent browser identity (fingerprint, cookies, storage) bound to one connected account.
• Egress / proxy rebind — changing which network path (proxy) a connected account's browser traffic goes through, without breaking its live session.
• Sync engine — the pipeline that pulls raw data off a connected account: an adapter talks to the site, a dispatch hands out work, a claim reserves a unit of work, evidence is the raw bytes kept as proof, and a manifest describes what a run is allowed to touch.
• Domain event journal — an append-only log (events/journal.py) that is the one legal writer of the domain_event table. Other products read from it instead of querying Platform's internal tables directly.

What's next

Ready to connect an account? See Connect an OnlyFans account.