← Back to Held

Held legal

Cookie notice

How Held uses cookies and similar browser storage.

Last updated 26 August 2026

PrivacyCookiesTerms

Held uses cookies and similar browser storage for sign-in, security, private customer sessions, and optional booking convenience. Held does not set advertising or cross-site tracking cookies by default.

Cookies can behave differently on shared devices. Clear saved details before leaving a public, salon, school, or shared phone or computer.

Strictly necessary cookies

Owner and staff sign-in cookies keep dashboard sessions secure. Access cookies follow the authentication session expiry, refresh cookies last for up to 30 days, and the selected owner or staff workspace can be remembered for up to one year. They are HTTP-only where possible and are cleared on sign-out.

An invited-staff continuation cookie can hold the private invite token for up to 15 minutes while sign-in finishes. It is path-scoped and cleared when the user returns to the invite.

Current private booking links keep their bearer token in the link instead of saving it in a new booking-access cookie. Held clears the older ob-customer-portal-token cookie when a legacy private-link route is used; older releases allowed that cookie to last for up to 24 hours.

If optional customer accounts are enabled, Held uses short-lived HTTP-only cookies for the email-code linking intent, recent-authentication check, or supported social-provider PKCE verifier and safe return path. The linking-intent cookie can include the private booking token only long enough to return to that booking after sign-in. These cookies last for up to ten minutes. Separate customer-only access cookies follow the authentication session expiry, refresh cookies last for up to 30 days, and the selected business cookie lasts for up to 24 hours. These cookies do not sign the customer into an owner or staff dashboard.

Owner Google sign-in and supported Gmail, Microsoft, or Meta connection flows use path-scoped HTTP-only state, verifier, or temporary-grant cookies for up to ten minutes. Successful or cancelled flows clear them where the connection step handles that result; failed or abandoned values expire within that limit.

If an owner connects a supported Meta business channel, Held uses separate short-lived HTTP-only cookies to bind the permission response and asset-selection step to that owner and business. The temporary provider grant is encrypted, path-scoped, expires after about ten minutes, and is cleared when setup finishes or is cancelled; a failed or abandoned asset-selection step relies on that bounded expiry.

A newly generated dashboard API key is held in a short-lived HTTP-only cookie for up to three minutes so it can be shown on the matching result page, then it expires.

Owner onboarding can save an unfinished setup draft in this browser, including business contact details and staff names. It is removed after setup or when read more than seven days after it was saved.

Public booking submission identifiers and the choice to dismiss the app-install prompt use session storage and normally disappear when the browser tab or session closes. Non-essential booking-funnel analytics is disabled in Production: Held does not write its funnel identifier or send funnel events unless a future release adds and enables a reviewed consent flow. Dashboard display preferences and a last-online timestamp can remain in local storage until the user clears browser data.

Held's service worker keeps only the offline fallback page and static app icons in browser Cache Storage. It replaces older Held shell caches when updated and the browser can retain the current shell until the site data is cleared. Private dashboard, customer, booking, manage, client, checkout, and payment responses are excluded from this app-shell cache.

Server-side security and rate-limit data helps prevent abuse and protect public booking writes. It is covered by the platform retention schedule rather than browser cookie expiry.

Returning-client convenience cookie

The optional returning-client cookie is named ob_client. It can store the customer name, email address, and phone number entered on a booking form so a future booking page for the same business on the same device can pre-fill those fields.

The same opt-in also writes ob_client_scope for 30 days on that business path. It contains only a version marker used to recognise the correctly scoped cookie and does not contain the customer's contact details.

It is scoped to that business's exact /book address, uses SameSite=Lax, uses Secure on HTTPS, and lasts for 30 days unless cleared sooner. When a booking page next reads an older site-wide or shared /book version, Held moves the saved details to that business path and removes the broader cookie.

The booking page needs to read this cookie to pre-fill the form, so it is set by browser JavaScript and cannot be HTTP-only.

The booking form asks before saving these details. Use Clear saved details on the booking page or clear browser cookies to remove it, especially on shared devices.

Provider and embedded contexts

Stripe, Meta or Facebook, Google, Microsoft, Supabase, Resend, or SendGrid may set their own cookies or use similar storage when their hosted pages, dashboards, or OAuth flows are opened.

Embedded booking widgets should not add advertising cookies. Website owners embedding Held are responsible for their own site cookie banner and any analytics or marketing tags they add around the widget.