Sessions & re-login

A connected account's session lives on our side, scoped to your panel. You send an of_user_id; we load the cookies, x-bc and x-hash, route through the account's proxy, sign the request, and forward it.

What we store

Retrieve the session block for an account with GET /accounts?include_session=true. You rarely need to — the point of the API is that you do not handle these values.

Automatic re-login

Platforms invalidate sessions for all sorts of reasons: a password change, a suspicious-activity lockout, a login from elsewhere, or simple expiry.

When we detect an invalidated session mid-request, we re-login using the stored credentials and retry the request transparently. When that happens on the passthrough, the response carries an extra flag:

{ "success": true, "status_code": 200, "relogin": true, "data": { … } }

relogin: true means the call succeeded, but the session behind it was rebuilt. Nothing is required of you — it is a signal, not an error.

When re-login fails

If we cannot recover the session — no stored credentials, credentials no longer valid, or 2FA now required — the endpoint returns 401 with relogin_failed. Once the credential circuit-breaker trips it also carries needs_reconnect: true and reason: "invalid_credentials".

needs_reconnect is the actionable flag, and it is also surfaced per account on GET /accounts — poll that rather than waiting for a call to fail. The account needs reconnecting:

curl -X POST "$BASE/api/crm/$CRM/accounts/login/cookies" \
  -H "X-API-Key: $KEY" \
  -H "X-Proxy: http://user:pass@host:port" \
  -H "Content-Type: application/json" \
  -d '{"platform":"onlyfans","sess":"<fresh sess>","auth_id":"<of user id>"}'

Reconnecting clears the re-login block, but not the polling pause. Re-enable it explicitly:

curl -X PATCH "$BASE/api/crm/$CRM/accounts/$OFUID/polling" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"enabled": true}'

The failure counter only resets on a successful poll, so if the underlying problem is still there the first failure after re-enabling re-trips the threshold and pauses it again.

Detecting it before your users do

Two approaches, in order of preference:

1. Subscribe to polling_paused via webhooks or SSE. You find out within a poll cycle.
2. Watch for relogin_failed on your own calls, and surface it as a reconnect prompt rather than a generic error.

Why the proxy matters

OnlyFans associates a session with the network it was created from. If requests for that session start arriving from a different IP, it gets invalidated — which is why X-Proxy is required when connecting an OnlyFans account, and why we route every subsequent request for that account through the same proxy.

Changing an account's proxy after the fact is supported:

curl -X PATCH "$BASE/api/crm/$CRM/accounts/$OFUID/proxy" \
  -H "X-API-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d '{"proxy": "http://user:pass@newhost:port"}'

Expect the session to need re-establishing if the new proxy exits from a noticeably different location. See Proxies.