Cookie & Tracking Technologies Policy

This Cookie & Tracking Technologies Policy (“Policy”) explains how Polinate PTY LTD (“Polinate”, “we”, “us”) uses cookies, SDKs, localStorage, and similar technologies (collectively, “cookies”) on our web and mobile interfaces, APIs, and admin dashboards (the “Services”). It applies to all users who access the Services via a browser or in-app webviews. This Policy should be read with our Privacy Policy. If you have an enterprise agreement that specifies stricter cookie or telemetry requirements, those terms prevail for your tenancy.

Cookies are small text files placed on your device by a website. Related technologies include: - LocalStorage/SessionStorage: browser key–value stores for persistent or session-scoped data. - SDKs and Pixels: small code snippets used for authentication, analytics, security, and diagnostics. - Device Identifiers: mobile or browser-generated IDs used to maintain sessions and prevent fraud. Some are “first-party” (set by Polinate), others are “third-party” (set by our service providers).

We use cookies to: - Keep you securely signed in and route your requests to the correct tenant/region. - Prevent fraud and abuse (e.g., CSRF tokens, bot detection). - Remember preferences (e.g., UI state, language, table filters). - Measure performance and reliability (page loads, API latency, error rates). - Diagnose issues and improve features (anonymous or aggregated telemetry). - Support optional integrations you enable (e.g., email, ERP, auth).

We classify cookies by purpose. Unless otherwise stated, cookies in categories (1)–(3) are considered essential/strictly necessary for the Services to function properly. 1) Strictly Necessary (Essential) - Session authentication tokens, tenant routing, load balancer stickiness. - CSRF tokens, rate-limit tokens, bot/abuse prevention. - Consent storage cookie (to remember your choices). 2) Security and Compliance - Sign-in state, MFA flows, device/session integrity checks. - Audit flags to correlate suspicious activity and mitigate incidents. 3) Functional (Preferences) - UI layout, recently used filters, language, theme, dismissals of non-essential banners. 4) Performance and Analytics - Page timing, route transitions, API error rates, anonymised usage patterns. - Used to prioritise reliability work; does not track across unrelated sites. 5) Integration/Service Cookies - Authentication and session persistence for identity providers. - OAuth state and anti-forgery parameters during external sign-ins. 6) (Optional) Marketing/Attribution - Disabled by default. If enabled for specific campaigns, we will present additional consent where required and provide opt-out controls.

Depending on your configuration and region, the Services may use: - Identity & Session: Clerk (session tokens, PKCE/OAuth state), first-party auth cookies. - Hosting/Web: Vercel (edge routing, performance telemetry), Cloudflare (DDoS protection, caching), which may set security/performance cookies. - Data & App: Supabase/Neon DB (primarily server-side; no retail tracking cookies exposed to your end users), application-specific first-party cookies/localStorage. - Analytics (performance-only): Vercel Web Analytics or equivalent lightweight analytics to measure page load, errors, and core web vitals without cross-site profiles. - Email/OAuth: Google/Microsoft OAuth flows (temporary state cookies during sign-in), only when you initiate a connection. Note: We do not deploy advertising networks or social media trackers by default. If a customer explicitly enables marketing integrations, those will be disclosed and gated by consent.

Cookie duration varies by purpose: - Session cookies: expire when you sign out or close the browser session. - Short-lived security cookies (CSRF, OAuth state): minutes to hours. - Preference cookies: typically 6–12 months or until cleared. - Analytics cookies (performance-only): 1–13 months depending on the tool and regional settings. We minimise duration and scope consistent with security and usability.

Your choices depend on your jurisdiction: - Australia and similar regimes: we present a clear notice and options. Non-essential cookies are opt-in where required by customer policy. - EU/UK: we obtain prior consent for non-essential cookies (e.g., analytics/marketing). We block those until you opt in and honour granular category choices. - California/US state laws: we provide transparency and opt-out controls for any sharing/tracking classified as “sale” or “sharing” (not used by default). Signals we honour: - Consent Banner: your selections are stored in a consent cookie and applied on subsequent visits. - Global Privacy Control (GPC) / Do Not Track (DNT): where feasible, we treat these signals as opt-out for non-essential tracking. You can also control cookies via your browser: block, delete, or restrict cookies and storage. Note that blocking essential cookies will impair core functionality (e.g., login).

You can: - Use the in-product “Cookie Preferences” to change your selections at any time. - Reopen the consent banner via the footer link (“Cookie Settings”). - For mobile in-app webviews, use the provided settings page or device/browser controls. Enterprise administrators can request tenant-level defaults (e.g., disable analytics for all users by default) by contacting support.

First-party cookies are set by Polinate domains and are primarily used for authentication, security, preferences, and consent. Third-party cookies (where present) are set by integrated providers (e.g., identity, OAuth flows, performance analytics) solely to operate requested functionality. We contractually require providers to use data only for providing their services to us and to protect it appropriately.

By default, no. We do not deploy cross-site behavioural advertising, retargeting, or social media tracking pixels in the production application. If a specific campaign requires marketing/attribution cookies, we will: - List the provider and cookie names in the consent interface, - Obtain opt-in where required (e.g., EU/UK), - Provide an easy opt-out at any time.

The exact names vary by environment and build, but representative entries include: - “__host-session” (Strictly Necessary): signed session token (HTTPOnly, Secure, SameSite=Lax/Strict). - “__cf_bm”, “cf_clearance” (Security): Cloudflare bot management/DDoS allowances. - “csrf_token” (Security): CSRF protection for form posts and API calls. - “consent_prefs” (Strictly Necessary): your consent selections and timestamps. - “ui_prefs” (Functional): table column visibility, theme, language. - “oauth_state” (Security): anti-forgery state parameter during OAuth. - localStorage “feature_flags” (Functional): enables/disables certain UI features client-side. We rotate names/keys periodically for security and may change implementation without notice to improve safety and performance.

Our analytics approach focuses on reliability and usability, not advertising. We collect aggregate metrics such as page load time, error rates, and route performance. We do not use analytics that build cross-site advertising profiles in the application. Where regional law treats analytics as non-essential, we obtain consent before enabling them.

When you use integrations (e.g., Google/Microsoft OAuth, Clerk auth), their services may set their own cookies as part of the login or token refresh process. Those providers’ cookies and processing are governed by their own policies. If you follow a link to a third-party site or portal from within our application, their cookie practices apply there.

We may update this Policy to reflect changes in technology, providers, or legal requirements. We will post the updated version with an effective date and, for material changes, provide prominent notice in the application. Where required, we will re-collect consent.

For cookie questions, enterprise tenant defaults, or to request our current list of material third-party providers, contact: privacy@polinate.app (example) or use the in-product support channel.