Available lang sa Ingles ang dokumentong ito, at ang bersyong Ingles ang opisyal na teksto.
Cookie Policy
Effective date: July 27, 2026
Last updated: September 10, 2026
This Cookie Policy explains how Esqase, Inc. ("Esqase", "we", "us") uses cookies and similar browser technologies across our websites and applications: the marketing and documentation site at esqase.com, the firm application at app.esqase.com, the public eSignature signing app at docs.esqase.com, and the public booking, intake form, and payment pages we host for law firms. It describes what we set, why, for how long, and how you can control it. This policy supplements our Privacy Policy and forms part of the terms that govern your use of the service under our Terms of Service.
1. What This Policy Covers
This policy applies to the Esqase websites and web applications listed above, including public pages that a law firm shares with its clients (booking links, intake forms, eSignature signing links, shared document links, and payment links) and intake forms a firm embeds on its own website. It does not cover the internal console Esqase staff use to administer the service, which is not available to customers or the public. It covers cookies as well as similar technologies such as browser local storage and IndexedDB, which we describe below.
It does not cover websites operated by our customers or by third parties. When a law firm embeds an Esqase intake form on its own site, this policy covers the Esqase form itself; the surrounding website is governed by that firm's own policies.
2. Cookies and Similar Technologies
Cookies are small text files a website asks your browser to store. On your next visit, the browser sends them back, which lets the site recognize your session, keep you signed in, or remember something you did (like unlocking a protected link).
A few related terms used in this policy:
- First-party cookies are set by the site you are visiting (for example, an app.esqase.com cookie set while you use the Esqase dashboard). Third-party cookies are set by a different domain, typically because the page loads a component from another provider.
- Session cookies last only as long as your browser session. Persistent cookies have a fixed lifetime and survive closing the browser.
- Local storage, session storage, and IndexedDB are browser storage areas that hold data on your device without sending it with every request. Some of the software libraries we use (for example, the Firebase web libraries) store configuration and security tokens in IndexedDB.
3. How Esqase Uses These Technologies
We use three categories:
- Strictly necessary cookies make the service work: signing in, staying signed in, timing out idle sessions, protecting against abuse, and remembering that you unlocked a protected link. These cannot be switched off without breaking the feature they support, and they do not require consent.
- Functional storage is device storage (not cookies) that our software libraries need to operate, such as sign-in state during email link verification and security tokens.
- Analytics cookies help us understand how our marketing site and product applications are used so we can improve them.
Important: We do not use advertising or targeting cookies on any Esqase site or application. We do not track you across other companies' websites, and we do not sell personal information. Our product analytics measure how firm staff use the application itself; analytics is never tied to client matters, documents, or the contents of your work in Esqase, and the public pages your firm shares with its clients stay anonymous.
Our production cookies are built conservatively: every authentication, visitor, unlock, and confirmation cookie carries the browser-enforced __Host- prefix in its name (which requires a secure connection, locks the cookie to a single Esqase domain, and prevents broader scoping) and is marked HttpOnly, meaning JavaScript running in the page cannot read it. The one exception is the sidebar preference in Section 4.1, which carries no personal data and is written by the page itself.
4. Strictly Necessary Cookies
These first-party cookies are required for sign-in, security, and the public client-facing pages to function. Lifetimes below are the maximums set in our systems; cookies may be cleared earlier (for example, when you sign out).
Some cookie names below end in a fingerprint, shown as <fingerprint>. This is a random-looking code derived from the specific link you unlocked. It lets us remember the unlock without ever placing a document, client, or request identifier in a cookie name, and unlocking one link never unlocks another.
4.1 Firm Dashboard (app.esqase.com)
| Cookie | Purpose | Duration |
|---|---|---|
__Host-session | Keeps you signed in to your firm account; verified on our servers on every request | 12 hours |
__Host-activity | Idle timeout: a signed timestamp, refreshed while you are active, that signs you out after 1 hour of inactivity. It carries no personal data | 61 minutes (a sliding 1 hour idle window, plus one minute of grace for a request already in flight) |
__Host-2fa | If your account uses two-factor authentication, carries the pending sign-in between password entry and code verification. It holds your account identifier and a single-use value that is checked against our servers, never your password and never your verification code | 10 minutes |
sidebar_state | Remembers whether you left the dashboard sidebar expanded or collapsed. Its value is the word true or false and nothing else | 7 days |
4.2 Booking Pages (book.esqase.com)
| Cookie | Purpose | Duration |
|---|---|---|
__Host-booking-actor | Recognizes your browser across visits so repeat bookings are attributed to the same anonymous visitor | 30 days |
__Host-book-session | Keeps you signed in to an event page after you verify your email through a sign-in link | 13 days |
__Host-booking-schedule-unlock-<fingerprint> | Remembers that you unlocked a password-protected scheduling link for the current sitting | 4 hours |
__Host-booking-confirmation | Carries your just-completed booking across the redirect to the confirmation page, so booking details never appear in the page address | 5 minutes |
__Host-booking-schedule-confirmation | Carries a just-approved reschedule across the redirect to the confirmation page | 5 minutes |
4.3 eSignature Signing and Shared Documents (docs.esqase.com)
| Cookie | Purpose | Duration |
|---|---|---|
__Host-docs-actor | Recognizes your browser across visits as the same anonymous visitor | 30 days |
__Host-docs-unlock-<fingerprint> | Remembers that you unlocked a signing link (by password or verified email) for the current sitting | 4 hours |
__Host-docs-share-unlock-<fingerprint> | Remembers that you unlocked a shared document link for the current sitting | 4 hours |
4.4 Intake Forms (form.esqase.com)
| Cookie | Purpose | Duration |
|---|---|---|
__Host-form-actor | Recognizes your browser across visits as the same anonymous visitor | 30 days |
__Host-form-unlock-<fingerprint> | Remembers that you unlocked a password-protected form link for the current sitting | 4 hours |
4.5 Payment Pages (pay.esqase.com)
| Cookie | Purpose | Duration |
|---|---|---|
__Host-payment-actor | Recognizes your browser across visits as the same anonymous visitor | 30 days |
__Host-payment-unlock-<fingerprint> | Remembers that you unlocked a protected payment link (by password or verified email) for the current sitting | 4 hours |
__Host-payment-confirmation | Carries your just-recorded payment across the redirect to the confirmation page | 5 minutes |
Two further Esqase surfaces are worth naming. Our public API at api.esqase.com is authenticated with API keys rather than cookies and sets none. Our internal administration console at admin.esqase.com is used only by Esqase staff and is not open to customers or the public; it sets the same kind of strictly necessary cookies as the firm dashboard, __Host-admin-session (12 hours) and __Host-admin-activity (30 minutes, sliding).
The tables in this section were last verified against our systems on September 10, 2026.
5. Functional Storage
Some of what we keep on your device is not a cookie. It sits in your browser's local storage, session storage, or IndexedDB, is readable only by the Esqase site that wrote it, and is not sent to another website.
Firebase libraries. Our applications use the Firebase web libraries for sign-in, for the real-time signals that tell an open page that something it is showing has changed, for push notifications, and for the abuse protection described in Section 7.2. Those libraries use IndexedDB to hold application configuration, an installation identifier for your browser, the push notification registration described below, and the short-lived security tokens described in Section 7.2. Keeping you signed in is done by the cookies in Section 4, not by browser storage.
Firm dashboard (app.esqase.com).
| Name | Where | Purpose |
|---|---|---|
esqase:idle:last-activity-at, esqase:idle:last-ping-at, esqase:idle:signal | Local storage | Lets your open Esqase tabs agree on a single idle-timeout countdown, so a warning or a sign-out in one tab reaches the others |
esqase-firm-setup | Local storage | Holds your progress through firm setup, including details you have entered but not yet saved, so a refresh does not lose them |
esqase-setup-guide | Local storage | Remembers whether you opened, minimized, or dismissed the Setup Guide panel |
Push notifications. If you allow browser notifications, the dashboard registers a service worker and a push registration token so we can deliver the notifications you have turned on. Withdrawing the browser's notification permission, or turning notifications off in your Esqase settings, ends this.
Shared document pages (docs.esqase.com). A docshare-viewed-... entry in session storage records that a publicly shared document has already been counted as viewed in this browser session, so refreshing the page does not inflate the view count reported to the firm. It is discarded when you close the tab.
Analytics. PostHog keeps part of its state in local storage alongside its cookie, as described in Section 6.1.
This is functional device storage: it is not used for advertising or for tracking across sites, and it persists until you or your browser clears site data.
6. Analytics
We use one analytics tool, PostHog, on our marketing site at esqase.com and on our product applications. It is configured so that automatic page tracking is off and each page navigation is counted exactly once, we record only a curated set of product events rather than capturing every click automatically, page addresses and titles are sanitized so they carry no record identifiers or content, and it is not used for advertising.
6.1 PostHog
PostHog helps us understand which pages people read and how they move through the marketing site and the application. It stores a random identifier and session state under a name that begins with ph_ and ends in _posthog, split across a cookie and a matching local-storage entry. Unlike our own cookies, which are locked to the single sub-domain you are on, the PostHog cookie is scoped to esqase.com and its sub-domains, so one identifier is shared across the Esqase pages you visit. PostHog also keeps two short-lived window markers in session storage, which are discarded when you close the tab.
| Name | Purpose | Duration |
|---|---|---|
ph_<project key>_posthog (a cookie plus a matching local-storage entry) | Random identifier and session state for site and product analytics | Set by PostHog; 365 days by default |
PostHog session replay is off by default and operates only in environments where we have expressly enabled it; where it is enabled, all text and form inputs are fully masked so the recording never captures client matters, documents, or the contents of your work. Learn more in PostHog's privacy policy.
6.2 Product Applications
Our firm dashboard and the public product pages run privacy-hardened product analytics through PostHog, and set the ph_* cookie and browser storage entries described in Section 6.1 on their domains alongside the strictly necessary cookies listed in Section 4. This analytics is deliberately conservative: we record only a curated set of events (not automatic click capture), and page addresses and titles are sanitized so they never carry record identifiers or the contents of your work. When a member of a law firm's staff is signed in to the dashboard, we identify their analytics session with their name, business email address, firm name, and firm location, and with internal identifiers and role flags that tell us which firm and which member an action belongs to, so we can understand how firms adopt Esqase. We also record non-identifying attributes of the firm itself, such as its country, time zone, billing currency, and size. The public pages a firm shares with its clients (booking, signing, document sharing, intake, and payment) stay anonymous: we do not identify the client, and we do not collect their name, email, or phone number for analytics. In every case, product analytics measures use of the application itself and is never connected to client matters, documents, or their contents.
How long we keep this. The lifetimes above are how long an identifier stays in your browser. How long we keep the analytics records themselves is set out in Section 8 of our Privacy Policy: we keep product usage analytics only for as long as we need it to understand and improve the Service, and we delete the analytics associated with a firm user on a verified account-deletion request.
7. Third-Party Services
A small number of third-party providers can set their own cookies in connection with our service. We do not control these cookies; the linked policies do.
7.1 Stripe
Your firm's Esqase subscription is billed through Stripe on Stripe-hosted pages. We do not embed Stripe's scripts on Esqase pages: when you start a checkout or update a payment method, your browser is sent to a page served by Stripe, and the cookies set there belong to Stripe, sit on Stripe's domain, and are governed by Stripe's privacy policy. Stripe is not used on the payment pages a firm shares with its clients: those pages record a payment a client has already sent through their own bank or payment app, and no payment provider's software runs on them.
7.2 Google reCAPTCHA Enterprise
Our applications use Google reCAPTCHA Enterprise, through Firebase App Check, as invisible protection against bots and abuse. Where this protection is active, Google may set its own cookies, and the related security tokens are stored in your browser's IndexedDB. This use is governed by Google's Privacy Policy and Terms of Service.
7.3 Cloudflare
Cloudflare provides name resolution for our domains, and delivers and protects our marketing website at esqase.com. It is not in the path of our product applications: a request to the firm dashboard, or to a booking, signing, shared document, form, or payment page, goes straight to Google Cloud's load balancer, so no Cloudflare cookie is set there. Where Cloudflare's protections are active on the marketing site, it sets its own strictly necessary cookies on that domain. The main one is __cf_bm, which supports bot detection and expires after 30 minutes of inactivity. Cloudflare may also set cf_clearance if you complete a security challenge, and short-lived rate-limiting cookies such as _cfuvid and __cfruid. These carry no advertising identifier and are not used to profile you. See Cloudflare's list of cookies and its privacy policy.
8. Forms Embedded on Law Firm Websites
Law firms can embed Esqase intake forms directly in their own websites. In that setting, the Esqase cookies described in Section 4.4 appear in a third-party context on the firm's site, but they remain scoped to Esqase's own domain, are strictly necessary for the form to work, and are never used for tracking across sites. Some browsers block cookies inside an embedded frame by default. Where the browser supports it, the embedded form asks for permission to use its own cookies in that frame, which may show you a short browser prompt; you can decline. Whether you decline or your browser does not support it, the form still works: you can complete and submit it, though a password-protected form may ask for the password again and the form may not recognize your browser between separate visits. Opening the form's own link in an ordinary browser tab avoids the embedded context entirely.
9. How to Control Cookies
Esqase is offered to law firms in the United States and in the other countries where we make the Service available. We set the strictly necessary cookies in Section 4 because the features you asked for cannot work without them. We set the analytics entries in Section 6 on the basis of our legitimate interest in understanding and improving the Service, described in Section 4.2 of our Privacy Policy. We do not currently display a cookie banner, because we set no advertising or cross-site tracking cookies and we do not sell or share personal information. If we begin to offer the Service where the law requires your consent before an analytics cookie is set, we will ask for that consent first. The controls below are how you manage cookies on our sites today.
- Browser settings. Every modern browser lets you view, block, and delete cookies, typically under Privacy and Security in the browser's settings. You can block cookies for all sites, for specific sites, or clear them at any time. You can also clear site data (including local storage and IndexedDB) for any Esqase domain. Instructions for the common browsers: Chrome, Safari, Firefox, Edge.
- Do Not Track and opt-out signals. Our sites use no advertising or cross-site tracking cookies, and we do not sell or share personal information, so there is no sale or sharing to opt out of. PostHog is configured to respect Do Not Track: if your browser sends that signal, PostHog treats you as opted out, records no events, and sets no
ph_*cookie. The Do Not Track signal is deprecated and is no longer sent by every browser, so treat this as a best-effort measure rather than a guarantee. Blocking or clearing cookies for the Esqase domain you are visiting, as described above, is the reliable way to stop it. Where applicable law treats an opt-out preference signal such as Global Privacy Control as a valid request to opt out of the sale or sharing of personal information, we honor it accordingly. See our Privacy Policy for how we handle these signals. - Third-party cookies. Blocking third-party cookies in your browser limits what providers like Google can set in embedded contexts. Esqase's own cookies are set on the Esqase domain you are visiting, the Cloudflare cookies described in Section 7.3 are set on our marketing site, and the PostHog cookie described in Section 6.1 is set across esqase.com and its sub-domains. None of them is affected by that setting, except for embedded intake forms as described in Section 8.
Strictly necessary cookies do not require consent and cannot be disabled through any Esqase setting, because the features they support cannot work without them.
10. What Happens If You Disable Cookies
You can browse esqase.com with all cookies blocked. The product surfaces are different:
- Blocking cookies on app.esqase.com prevents sign-in entirely, because the session cookie is how we know who you are.
- Blocking cookies on booking, signing, form, or payment pages breaks link unlocks, email link sign-in, and confirmation pages. Protected links will ask for the password again on every request, and some flows will not complete.
- Clearing site data removes the functional storage described in Section 5, which may sign you out or interrupt an in-progress email verification.
Blocking analytics cookies has no effect on any feature.
11. Changes to This Policy
We may update this Cookie Policy from time to time, for example when we add a feature that sets a new cookie or retire one that does. We will post the updated policy at this address and revise the "Last updated" date above. Material changes will be communicated in accordance with our Terms of Service.
12. Contact
Questions about this Cookie Policy or our use of cookies? Contact us at:
Esqase, Inc.
2810 N Church St STE 89268
Wilmington, DE 19802, United States
legal@esqase.com