Current first-party cookie
| Name | Why it exists | Current behavior |
|---|---|---|
| vi_access_token | Mirrors the current customer access token so Next.js middleware can gate protected routes before the app finishes loading. | Set by frontend code after login or refresh, written as a first-party cookie, and cleared on logout. In the current frontend code it can be written with up to a 30-day max age even though the underlying access token is short-lived and refreshed separately. |
Other browser storage used by the app
- localStorage stores the customer access token, refresh token, selected workspace, and cached UI state such as billing and onboarding snapshots.
- sessionStorage stores FounderSpace's separate internal auth value.
What the current frontend does not set
- No separate refresh-token cookie in the customer auth flow.
- No dedicated CSRF cookie in the current frontend implementation.
- No separate analytics or advertising cookie is required for the core customer auth and route-gating flow described on this page.
Third-party pages
Official social-platform authorization pages, identity providers, or payment/check-out pages may set their own cookies while you are on those domains. Those cookies are controlled by the third party, not by this frontend.
Contact
Questions about browser storage or cookies? Email privacy@viengine.social.