Dashboard session (cookie + CSRF)

BrowserUser signs in

Session + CSRF cookiesLogin sets httpOnly session cookie and a readable CSRF cookie

APIAccepts login, returns 200

BrowserLater mutating request (e.g. POST) sends session cookie automatically + X-CSRF-Token header

Session + CSRF cookiesHeader value must match CSRF cookie's value

APIValidates cookie + matching header, then proceeds

Scripts & integrations (bearer token)

Script / IntegrationHolds access_token from login response

Authorization: Bearer <token>No cookies, no CSRF header needed

APIValidates token, proceeds

Authentication

How SocialPulse authenticates the dashboard and API callers: bearer tokens, session cookies, and CSRF protection.

Two ways to authenticate

The dashboard itself authenticates via an httpOnly session cookie, set on login and never readable by JavaScript. Scripts, integrations, and server-to-server callers instead use the access_token returned in the login response body as a standard Authorization: Bearer header — no cookie required.

CSRF protection on cookie sessions

Because the session cookie is attached automatically by the browser, every state-changing request (anything other than GET/HEAD/OPTIONS) authenticated via that cookie must also echo a CSRF token in an X-CSRF-Token header. The token is issued once at login (as a non-httpOnly cookie and in the response body) and doesn't need to be re-fetched. Requests authenticated with a bearer header instead of the session cookie are not subject to this check — there's no ambient credential for a third-party site to ride along on.

Token lifetime

Access tokens expire after a fixed window; sign in again to obtain a new one. There is no public self-registration endpoint — every account is provisioned through an invitation from a Tenant Admin or Platform Admin.