Cookie Policy

Cookies we use

better-auth.session_token. Set when you sign in. It carries the identifier for your login session and is what keeps you signed in from one page to the next. It lasts 24 hours in production (seven days in local development) and is extended after six hours of activity. Our authentication library sets it; our own code never touches it directly.

selected_business_id. Remembers which business you are currently working in, for accounts that have more than one. It lasts 30 days. The app writes it in your browser and reads it on the server, so both sides agree on which business you are looking at.

google_auth_success. A 60-second signal set immediately after you connect a Google account. It holds the connected email address and a short message as JSON, and is deliberately readable by page scripts so the interface can show you a confirmation. It expires a minute later.

OAuth state cookies. Each connection to an outside account sets a short-lived, HTTP-only cookie holding a random value that we compare when the provider sends you back to us. That comparison is how we detect a forged callback. They are google_oauth_state (signing in with Google), google_business_oauth_state (connecting Google Business Profile), meta_oauth_state (Facebook and Instagram), linkedin_oauth_state, pinterest_oauth_state, and twitter_oauth_state (X). Each lasts 10 minutes.

twitter_code_verifier. Set alongside twitter_oauth_state for the PKCE step of the X sign-in flow. HTTP-only, 10 minutes, and deleted as soon as the callback completes.

selected_organization_id. The organization-level counterpart of selected_business_id, for accounts that belong to more than one organization. It remembers which one you are working in. HTTP-only, 30 days.

beta_verified. Set when you enter the correct passphrase on the closed-beta gate at /register/verify. It records only that the passphrase was accepted, and the moment that record expires. HTTP-only, one hour.

beta_attempts. Set alongside it on the same page: a counter of how many passphrase attempts have been made, so we can limit guessing to five per hour. It holds a count and a reset time and nothing about you. HTTP-only, one hour.

impersonated_user_id. Set only when one of our superadmins impersonates an account to investigate a support problem. It holds the identifier of the account being viewed. HTTP-only, eight hours — deliberately shorter than the others.

We set no advertising cookies and no third-party tracking cookies, and this application sets no analytics cookie in your browser.

Why we use them

Two reasons, and neither is marketing. The first is keeping you signed in. Without a session cookie the server has no way to connect one request to the next, so every page load would look like a stranger arriving.

The second is remembering context and protecting the flows that leave our site. selected_business_id and selected_organization_id keep you in the business and organization you picked instead of dropping you back to a default. The OAuth state cookies exist purely as a security control: they let us confirm that a callback arriving from Google, Meta, LinkedIn, Pinterest, or X belongs to a request you actually started.

The third is guarding the closed beta. beta_verified remembers that you got the passphrase right so you are not asked again on every page, and beta_attempts counts wrong guesses so we can rate-limit them.

None of these build a profile of you or feed an advertising audience. There is nothing here to opt out of for marketing purposes, which is why this site does not show you a cookie consent banner.

Most of these are set only once you act on the site — signing in, choosing a business, connecting an outside account, or a superadmin opening a support session. Two are the exception, and we would rather say so than imply otherwise: beta_verified and beta_attempts are set on the public closed-beta gate at /register/verify, before you have an account and without you signing in. Our public marketing and legal pages — this policy, the Privacy Policy, Terms, Security, pricing, and the home page — set no cookie when you read them.

Controlling cookies

Every browser lets you block or delete cookies, and you are welcome to. Here is exactly what stops working if you do.

Block the session cookie and you cannot sign in. The login form will appear to succeed and then return you to the login page, because nothing is carrying your session between requests.

Block selected_business_id and an account with more than one business will not remember which one you selected. The product falls back to a default business on every page load.

Block the OAuth state cookies and connecting a Google, Meta, LinkedIn, Pinterest, or X account will fail. That check is a security control and it fails closed on purpose — we would rather refuse a connection than accept a callback we cannot verify.

Block beta_verified and the closed-beta gate will not let you through to the registration form: it has no way to remember that your passphrase was accepted, so it asks again every time.

Clearing cookies after you are signed in ends your session; sign in again and a new one is issued. If something behaves strangely after you change these settings, write to erikbigelow@gmail.com.