Connections

Only what's provable in code today — no planned contracts.

What Platform gives

• The domain event journal. events/journal.py is the single legal writer of the domain_event table (append + read_since). Other products read from this journal instead of querying Platform's internal tables directly — it's the spine the rest of the system is built on.
• A reconnect entry point. The ?reconnect=<external_account_id> parameter on the accounts page is a URL contract other surfaces can link into (e.g. a "connection lost" banner) to land a user directly on the right account's reconnect dialog.

What Platform takes

• Club's money events, projected into a shared table. money_projection.py reads Club's money.* event stream and writes rows into platform_transactions — deleting and rebuilding one owner+platform's rows at a time. Platform owns the mechanics of this projection; it does not own the meaning of the money, which stays Club's.
• Club's fan and subscription data, read-only, to order sync work. fan_priority.py reads spend, subscription state, and message activity from Club's tables to decide which fan's chat gets scanned first. It changes nothing in Club's data — it only orders Platform's own sync queue.

What reads Platform's data, from outside Platform

• Club reads the raw sync store to re-fetch signed media URLs. ops/fansly_media_fetch.py joins against the platform_sync_raw_snapshots table with raw SQL (not the ORM) to recover signed CDN URLs for platform_fans.avatar_url and platform_content.cover_url display — this bypasses Platform's own resolvers entirely, so it won't show up in an import-based audit of who depends on Platform.

What's next

Looking for the actual request/response shapes behind any of this? See the API reference.