Skip to main content
POST /v1/session mints a backend session: the same access + refresh token pair the web app gets on sign-in, for the account behind an OAuth access token. It’s how a native or first-party client (the desktop app, for example) reaches the protected /api surface and the realtime collaboration socket without a second interactive sign-in.
This is a deliberate privilege step-up: the session it mints is not scoped like the OAuth grant that authorized it. It carries the full privileges of the signed-in account, regardless of which scopes the token was granted. Only exchange a token you control, and only when your integration genuinely needs the full account surface rather than the scoped /v1 API.
Restricted to OAuth access tokens (flowy_oat_…): a workspace API key (secret or publishable) gets 403. This is not documented in the public OpenAPI spec; everything below is verified directly against the handler.

Request

No request body. Send the OAuth access token as the bearer:
cURL

Response

user is the same account object the web app’s sign-in returns (id, name, email, workspace id, credit balances, …), not the leaner object Get the account returns. token and refresh_token are a standard access/refresh pair; use refresh_token the same way the web app does to renew the session before expires_in seconds elapse.

Errors

Last modified on August 29, 2026