Browser sessions

The API also accepts a session cookie, issued when you sign in through a browser — the web portal, or the Sign in button on /reference. It is an alternative to a bearer token, not an addition to one.

Name	session_id
Flags	HttpOnly, SameSite=Lax, Secure, Path=/
Bound to	The browser that created it

Two consequences worth knowing:

• HttpOnly means JavaScript cannot read it. A single-page app on the same origin does not need to: the browser attaches the cookie to every same-origin request automatically. There is nothing for your code to store or send.
• The session is bound to the browser that created it. A cookie replayed from a different client is rejected and the session is dropped, so copying one out of a browser to use in a script does not work — and would fail closed rather than silently.

Sessions are shorter lived than device tokens and renew themselves while you are active, so a browser signed in and left alone will eventually need to sign in again.

The header always wins

If a request carries both an Authorization header and a session cookie, the header is used and the cookie is ignored. It is only consulted when no header is present — so an explicit token always overrides whatever the browser happens to be carrying.

For API clients, use a bearer token. The cookie exists for browsers: it cannot be obtained without a browser sign-in, cannot be moved between clients, and is not renewable from a script.