Last updated: 2026-08-18
1. What Are Cookies?
Cookies are small text files placed on your device when you visit a website or web application. They allow the service to remember information about your visit — for example, whether you are signed in — so you do not have to re-enter it on every page. Cookies may be "session" cookies, which are deleted when you close your browser, or "persistent" cookies, which remain on your device for a set period or until you delete them.
Similar technologies — such as local storage and session storage — may be used alongside or instead of cookies for analogous purposes. This policy covers all such technologies and refers to them collectively as "cookies", and Section 3 lists the local-storage items as well as the cookies.
2. Who Sets Cookies on Notavia?
Most of what this policy describes is set by Tessora LLC ("we", "us", or "our") as first-party cookies on the Notavia console and the documentation site. They are not the only thing your browser will carry, so Section 3 also lists the third-party scripts our pages load, because those scripts can set storage of their own that we neither control nor read.
We do not permit advertisers or social networks to set anything on any of our surfaces, and we do not use cookies to profile you or to follow you between sites.
PostHog runs as a third-party product-analytics service on this website from 18 August 2026, and it may set browser storage only if you accept analytics, and never before — a rejection or an absent choice keeps its client uninitialised. Section 4 describes both the website route and the separate server route, and says exactly where each of them stands. On the Notavia console and the documentation site no PostHog browser script runs.
3. What Your Browser Actually Carries
Authentication, security, consent-record, and requested interface-preference storage is essential to the requested function or records a choice you asked the service to remember. Theme and currency items only remember the interface selection you made; they are not analytics and do not select a country, data location, legal region, billing country, transaction currency, or governing law.
The optional category is website analytics, listed in Section 3c. It must remain off unless you affirmatively accept it. Section 3d separately lists browser requests to third-party scripts, including requests that are broader than the page function requires and therefore remain launch-remediation items rather than being relabelled essential.
3a. The Notavia console (dashboard and sign-in pages)
| Name | Type | Purpose | Duration |
|---|---|---|---|
notify_auth_* | Cookie | Authentication session — records that you are signed in. The name ends with the deployment it belongs to, so on the live console it reads notify_auth_production. HttpOnly, SameSite=Lax, with a 14-day sliding expiry, so it renews while you keep using the console. Invalidated on sign-out. | 14 days, sliding |
notify_antiforgery_* | Cookie | Anti-forgery token — protects every form submission from cross-site request forgery (CSRF). The name ends with the deployment it belongs to, so on the live console it reads notify_antiforgery_production. | Session |
.AspNetCore.Mvc.CookieTempDataProvider | Cookie | Carries a short message from one page to the next — a status line after you save something, and, immediately after signup, your first API key on its way to the confirmation screen. Its contents are encrypted with the application's data-protection key, so the value is not readable in your browser. Written only when there is something to carry, and deleted as soon as the next page reads it. | Session |
notify_dashboard_env | Cookie | Remembers whether you are working in the Test or Live environment. HttpOnly, marked essential. No personal data is encoded. | 12 months |
ns_consent | Cookie | Consent preference — your selected cookie categories (necessary, analytics, marketing), the time you set them, and a schema version for the record itself, so the notice does not reappear on every page load. That version is the format of the record, not the version of this policy: if you inspect the cookie you will see "v":1, which is what the consent script writes today and is unrelated to the version number at the top of this page. No personal data is encoded. | 12 months |
.AspNetCore.Identity.TwoFactorRememberMe | Cookie | Only if you tick "remember this machine" when entering a two-factor code. It lets this browser skip the second factor next time. You can clear it yourself with Forget this browser in your two-factor settings. | 14 days |
.AspNetCore.Correlation.<random> | Cookie | Set the moment you start an OAuth or OpenID Connect sign-in — today that is "Sign in with Google", and the same applies to an organisation OpenID Connect single sign-on — before you leave for the provider. A SAML organisation sign-in does not write this cookie at all; it writes the Saml2.* cookie listed below instead. It ties the reply that comes back to the request that started it, which is what stops someone else's sign-in reply being accepted in your browser. It carries no identity: the value is a fixed marker, and the identifying part is the random 43-character suffix in the name itself, which is why we cannot print the full name here. The name does not say which provider you chose, and we are careful about how far we take that: the prefix is the framework's own and carries no scheme name, so it is the same prefix for every OAuth and OpenID Connect provider, but the only sign-in we actually ran and observed was Google. We describe what we measured rather than a provider we did not test. HttpOnly, Secure, SameSite=None, and scoped to the single callback path for the provider you picked (/signin-google for Google) rather than to the whole site. Each sign-in attempt writes its own, so abandoning a few in a row can leave several until they expire. | 15 minutes, then it expires on its own; normally removed as soon as that sign-in exchange completes |
.AspNetCore.Identity.External | Cookie | Temporary external-login state used when you choose Google, Microsoft, or a Customer-configured external identity provider. Written on the way back from the provider, once it has told us who you are and before you are signed in. Sign in with Google is live on the console's sign-in page, so this and the correlation cookie above are the two things a Google sign-in actually puts in your browser on our side. Google sets its own cookies on Google's domain during that step; those are Google's, on Google's site, and we neither set nor read them. | Deleted when that sign-in exchange completes |
Saml2.* | Cookie | Only if your organisation signs in through SAML single sign-on. Holds the state of one sign-in exchange with your identity provider. | Deleted when that sign-in completes |
ns-theme | Local storage | Your light/dark appearance choice. | Until you clear it |
notifyservice:workflow-schema:* | Local storage | A cached copy of the workflow-editor schema, keyed by its content hash, so the editor does not re-download it. Written only if you open the workflow editor. No personal data. It has no expiry and we do not currently clear it. | Until you clear it |
The framework can also use .AspNetCore.Identity.TwoFactorUserId while a sign-in is waiting for a second factor. It is temporary and deleted when that sign-in exchange completes.
3b. Documentation site (docs.notavia.saas-infrastructure.com)
| Name | Type | Purpose | Duration |
|---|---|---|---|
ns_consent | Cookie | The same consent-preference record as above, scoped to the docs domain. | 12 months |
starlight-theme, starlight-synced-tabs__*, starlight-openapi-snippet-id | Local storage | Your appearance choice, and which tab or code-sample language you last picked, so the docs keep your selection as you move between pages. Set by the documentation framework. | Until you clear it |
sl-sidebar-state | Session storage | Whether the sidebar is open. | Until you close the tab |
3c. Our website (saas-infrastructure.com)
| Name | Type | Purpose | Duration |
|---|---|---|---|
si_consent | Cookie | Strictly necessary. Your cookie choice — which categories you accepted, when, and a schema version for the record itself, so the notice does not reappear on every page. That version is the format of the record, not the version of this policy. SameSite=Lax, Secure over HTTPS, readable by the page (it is not HttpOnly, because the script that shows the notice has to read it). No personal data is encoded, and it is not sent to us or stored against any account. | 6 months |
theme | Local storage | Your light/dark appearance choice. | Until you clear it |
ns-currency | Local storage | Whether you chose to see prices in USD or EUR on the pricing page. Written only when you use that toggle, and never before. No personal data, and it is not sent to us or stored against any account. | Until you clear it |
ph_<project-token>_posthog | Cookie and local storage | Only after analytics consent and only if PostHog is activated. PostHog's persistent browser identifier and related client state. The project-token portion varies with the configured project. | 365 days under the installed client default unless a verified project configuration shortens it |
__ph_opt_in_out_<project-token> | Local storage and, depending on the client path, cookie storage | Only after the PostHog client is initialized. Records the client's opt-in or opt-out state. The withdrawal routine targets both ph_ and __ph_ names. | Until replaced, cleared by the withdrawal routine, or cleared by you |
Nothing in either PostHog row may be set unless you have accepted analytics. Before you make a choice, and after a rejection, the application does not initialize PostHog. The consent test harness supplies a placeholder project key and checks both the no-request and after-Accept paths.
What has changed, stated precisely. The website release of 18 August 2026 carries the PostHog key, so the rows above are live behaviour rather than description — still only if you accept analytics. Earlier versions of this page recorded the interim states (no key, then a key held but never built into a release) as each was true.
No anti-bot challenge runs on this website. Neither form page requests a Cloudflare Turnstile script or any comparable third-party challenge, so opening either page contacts no challenge provider and sets no storage belonging to one. The hidden decoy field on both forms, and a per-IP-address submission limit on the waitlist form only, are what is actually in place.
An earlier release did load that script on both form pages, unconditionally and outside the cookie choice, while nothing ever checked the token it produced. It was removed rather than described, because a challenge that collects from every visitor and gates nothing is a disclosure without a protection. If a challenge returns, it will reject a missing or failed verification instead of passing it, check the expected hostname and the form the token was issued for, and the vendor's contract, transfer, retention, deletion and subprocessor position will be published here first. See our Subprocessor List.
3d. Third-party scripts our pages load
These are not cookies we set, but they are third parties your browser contacts, and each can set storage we do not control. Naming them is the point:
- Paddle (
cdn.paddle.com) — our payment provider's checkout library. It is requested only when you open a checkout, by the checkout code itself. It used to sit in the dashboard's root document and therefore load on every dashboard page, including for members who can never reach billing; that was narrowed on 15 August 2026. If you never open a checkout, your browser never contacts Paddle.
That is the whole list, and it used to be longer. Until 15 August 2026 two signed-in console pages also fetched Bootstrap and jQuery from jsDelivr and cdnjs, which handed your IP address and user agent to two networks we had no agreement with, for files we could serve ourselves. Those files come from our own servers now and neither network is contacted from anywhere in the product. No first-party source defines a storage name or duration for the one script that remains, and we have not observed or approved a production Paddle checkout from which a vendor-controlled storage ledger could be verified. We do not invent a cookie name or duration where the live vendor behavior has not been evidenced.
We set no advertising cookie and do not use these technologies for cross-site advertising. If PostHog is activated, its installed client defaults to a cross-subdomain first-party cookie for the configured site. That setting, the final cookie domain, and registrable-domain deletion must be verified before activation; it is not permission to track a visitor across unrelated websites.
3e. Recipient-facing pages
If you received a message sent through Notavia by one of our customers, the unsubscribe and preference page you land on sets an anti-forgery cookie — but it does so when the page is rendered, not when you submit it, because the page carries a form and the framework issues the token with the form. If you open an unsubscribe link and never submit anything, you already have the cookie.
We have to be exact about what that cookie does there, because it is not what it does elsewhere. These are the only two places in Notavia where cross-site-request-forgery validation is deliberately switched off: the preference page you reach from an unsubscribe link, and the one-click unsubscribe endpoint a mail provider calls on your behalf. A one-click unsubscribe is sent by your mail provider, not by your browser, and cannot carry a token, so requiring one would break the standard it implements. What authorises a change on either page is the signed token in the link the message carried — not a session and not that cookie. We would rather tell you the check is off here than let "the same protection as everywhere else" cover a page where it is not.
Nothing else is set on those pages, no analytics runs, and we do not use them to identify you.
4. Product Analytics
PostHog runs on two distinct analytics routes, both active from 18 August 2026 after the activation gates this section used to enumerate were closed. A data processing agreement with PostHog Inc. — incorporating the EU Standard Contractual Clauses, the UK Addendum, and Swiss FADP terms — was executed by both parties on 13 August 2026. The project's console settings were verified by the accountable owner on 18 August 2026: the project runs on EU Cloud, retention follows the plan-defined schedule with person deletion available in the console, support access was reviewed against the executed agreement, and the opt-out from PostHog's prospective product- and model-development use of Customer Content was exercised in service settings — under PostHog's current public terms that use is permitted unless the customer opts out, so the opt-out was treated as an activation gate rather than an assumed setting. The two routes are still not in the same position, and we describe them separately rather than under one word.
On our website, this route is optional worldwide and may initialize only after you accept analytics. That gate is in the code and does not depend on whether a key is present, so it governs the current release and the next one alike. The code enables page-view and page-leave capture and autocapture of ordinary interactions such as clicks, and defines waitlist_submitted with a source property and contact_submitted with a topic property. It uses persistent browser identifiers with person_profiles set to identified_only, disables session recording, and enables the client option that respects Do-Not-Track. The website does not call PostHog identify, but identified_only does not remove the persistent anonymous identifier or ordinary event properties. Text and element-attribute masking, exclusions, IP discard, surveys, feature flags, cross-domain behavior, project retention and deletion, and the data-use/model-training opt-out were verified as account settings by the accountable owner on 18 August 2026, with evidence filed in the internal evidence register, and the production domain is authorised in the project. Reject remains as easy as Accept. Withdrawal stops collection and removes both PostHog name patterns, including any registrable-domain cookie.
In the console, no PostHog browser script runs. The separate server route is active from 18 August 2026 with a production key configured. Its current five call sites are organization_registered (plan, region), first_notification_sent (channel), api_key_created (environment, scope), plan_changed (plan, previous_plan, status), and inbox_first_rendered (no custom property). The sender adds an organization UUID as distinct_id and $groups.organization. The current call sites contain no name, email address, message content, Recipient data, person identifier, or hidden payload field. A code-level allow-list enforces that list. The sending code refuses an event or a property that is not declared, refuses a value that is not a short plain token, and refuses outright rather than trimming silently, and regression tests cover both the list and every call site. This route is based on the legitimate interests described in the Privacy Notice, not website consent; a website rejection does not opt an organization out of it. An organization can object in the dashboard, under Settings → Privacy & Data, and the sending code checks that objection before every send and stops for that organization from the moment it is recorded; the objection carries its date and can be withdrawn. A user may also object through the worldwide privacy contact. Both controls are in the image production runs, and they are what governs this route now that it is active.
We do not set Google Analytics, Hotjar, Segment, Facebook Pixel, or any equivalent cookies. We do not share browsing data with advertising networks, and we do not engage in cross-site tracking.
If we activate PostHog or add another analytics or marketing technology, we will update this policy and the table in Section 3 and retain the worldwide explicit opt-in rule before setting optional browser storage or making optional analytics requests.
5. Our Cookie Consent Approach
The two kinds of surface carry two different interactions, because they set two different kinds of cookie. We describe both rather than implying one applies everywhere.
On our website (saas-infrastructure.com) — a gating opt-in banner. Accept and Reject sit side by side, at the same level, in the same size — rejecting takes exactly one click, the same as accepting, and there is no pre-ticked box. Preferences opens the same choice per category with analytics off by default. Until you accept analytics, PostHog is not initialized and no PostHog request may be made. Rejecting is recorded locally like any other choice, so the banner does not follow you after you say no. Accepting analytics is not consent to the separate server analytics route.
On the Notavia console and the documentation site — a non-blocking notice. The notice records preferences but does not gate authentication, security, or requested interface storage and does not gate the third-party script requests identified in Section 3d. You will see it on the sign-in pages, dashboard, in-product legal pages, recipient e-mail-confirmation page, and documentation site. You can dismiss it ("Got it") or open Cookie Preferences to review the category model. The one remaining third-party request, Paddle's checkout library, happens only when you open a checkout and is not treated as accepted through this notice either.
That notice does not appear everywhere. It is absent from the account-management pages, the unsubscribe and preference pages, and the two standalone pages named in Section 3d — the data-export download and organisation-onboarding pages. We would rather tell you where it is missing than describe a notice you cannot see.
Consent record. Your preference is saved in a first-party cookie on the device and browser you set it on — si_consent on the website, ns_consent on the console and documentation site. Neither is sent to us or stored against your account, so neither follows you to another device. Clearing your cookies clears the record, and you will be asked again. The two are separate records: a choice made on the website does not carry to the console, and the console's notice is not a consent gate in the first place.
Withdrawing consent. On the website, Cookie preferences in the footer reopens the choice at any time. Withdrawing analytics consent changes the client to memory-only persistence, opts it out, resets it, targets ph_ and __ph_ browser-storage names for deletion, and reloads. Production activation remains blocked until browser evidence proves that this also removes a cookie written at the registrable-domain scope. On the console and documentation site, the consent notice does not control authentication, security, or requested-preference storage and does not control the separate server analytics route.
6. How to Control Cookies
On our website, every page carries a Cookie preferences link in the footer, under Legal. It reopens the choice, shows what you picked last time, and lets you change or withdraw it.
On the Notavia console and documentation site, the sign-in pages, the recipient e-mail-confirmation page, the dashboard and the documentation site carry a Cookie Preferences link in the footer. It is not on every page. The account-management, unsubscribe and standalone pages listed in Section 5 have no footer of that kind, and neither do the in-product legal pages: their footer links to this policy rather than to the preferences dialog. The legal pages do carry the notice, and while the notice is on screen its Cookie preferences button opens the dialog — but once you have dismissed it there is no route back to the dialog from a legal page. If you cannot find it, open the dashboard or any sign-in page and it will be there.
You can also control cookies through your browser. Most browsers allow you to:
- View the cookies set on a site.
- Delete cookies individually or in bulk.
- Block all cookies, or block cookies from specific sites.
- Receive a notification when a new cookie is set.
Please consult your browser's help documentation for instructions. Common browsers:
- Chrome: Settings → Privacy and security → Cookies and other site data
- Firefox: Settings → Privacy & Security → Cookies and Site Data
- Safari: Settings → Privacy → Manage Website Data
- Edge: Settings → Cookies and site permissions → Cookies and site data
Blocking strictly necessary cookies will prevent Notavia from functioning correctly — you will not be able to sign in or submit forms.
7. Changes to This Policy
We review this Cookie Policy whenever we change the cookies we set. When we add or remove cookies, we will update the table in Section 3 and the lastUpdated date at the top of this document. Where a change involves setting non-essential cookies for the first time, we will seek your consent before doing so.
8. Contact
For questions about our use of cookies, please contact:
Tessora LLC Privacy and data protection: support@saas-infrastructure.com