1. Essential authentication cookie
The API sets axiom_session for local HTTP development or __Host-axiom_session for HTTPS/production. It identifies an authenticated session, has a default maximum age of 24 hours and is HttpOnly, so page JavaScript cannot read it. Production cookies are Secure. SameSite defaults to Lax but can be configured for the deployment.
Signing out revokes the session and clears its cookie. Blocking this cookie prevents authenticated onboarding from working. The cookie is set by the API host, which may differ from the website host.
2. Temporary application status
The browser’s sessionStorage entry axiom-application-id holds the submitted application identifier so the success page can check its save status. It is not a password or authentication token. Session storage normally clears when the browser tab’s session ends; the application also removes this entry on a new login or logout.
3. Google sign-in
When configured, original login and signup pages load Google Identity Services from accounts.google.com. Google may use cookies, browser-mediated identity features and connection information according to its own policies. Email login remains available. Simple authentication pages do not load the Google sign-in component.
4. Analytics and advertising
The current application does not install advertising cookies, an analytics SDK or a marketing cookie manager. That statement does not describe any extra tracking configured separately by a hosting operator. Additional non-essential tracking requires a policy update and consent controls where applicable.
5. Browser controls
You can inspect, clear or block cookies and site storage through your browser settings. Clearing authentication cookies signs you out. Clearing the temporary application identifier can stop the success page from automatically restoring its polling state; it does not delete an application already saved on the server.