Cookie Policy

What this policy covers

This Cookie Policy explains the cookies and similar technologies we use on ever.works and in Ever Works Cloud — the public website, the documentation, the signed-in application, and any desktop or mobile application we publish for it. The product-specific section below lists what is actually in use on each of those surfaces.

It sits alongside our Privacy Policy. The two documents answer different questions, and it is worth knowing which one you are reading:

• This policy is about your device. What we store on it, what we read back from it, why, and how you control that.
• The Privacy Policy is about the information itself. What we do with personal data once we hold it, the lawful basis for each purpose, who receives it, how long we keep it, and the rights you can exercise over it.

Where something described here involves personal data, the Privacy Policy governs that processing. Nothing in this policy narrows the rights that document gives you.

What this policy does not cover

Other people's sites and services. Our pages link to third-party sites, and our Service connects to third-party tools when you ask it to. Once you are on someone else's site, their cookie notice applies, not ours. We have no control over what they store on your device.

Your own workspace, your own site, your own people. Where you use the Service as a customer to run something of your own — a workspace for your organisation, or a site we provision for you — the pages you publish and the people you invite are yours. This policy is not your cookie notice to your own visitors or personnel, and our banner is not your consent mechanism. Providing those is your responsibility, on your own domain, under your own control.

A copy you run yourself. Where the software behind the Service is published as open source and you run your own deployment, this policy describes the service we operate — not yours. You choose what your deployment loads and what it stores on your users' devices, and only you can describe it to them.

Cookies and the other technologies that behave like them

A cookie is a small text file that a website asks your browser to keep and hands back to a server on later requests. It is the oldest way of doing this, and the best known — but it is only one of several, and the rules that matter here do not turn on which one is used.

The law we work to attaches to storing information on your device or reading information back from it, whatever the mechanism. So wherever this policy says "cookies", read it as covering all of the following.

The technologies

• Cookies — as above. Set by the site you are visiting, or by another provider whose code runs on the page.
• Local storage and session storage — key-value storage inside your browser. Larger than a cookie, not sent automatically with every request, and it can hold exactly the same kind of identifier.
• IndexedDB and the browser cache — structured storage and cached files. Ordinarily used to make pages load faster and to let parts of the Service work offline, but capable of holding an identifier too.
• Pixels, beacons and tags — a tiny image or a short script whose only job is to load. The act of loading it tells the provider that a page was opened, or an email read, along with your IP address and browser details. A pixel often stores nothing at all and still reports on you.
• Tracking parameters in links — identifiers added to a URL so that a click can be attributed to the campaign or message that produced it.
• SDK identifiers in desktop and mobile applications — an installed application has no cookie jar. It stores identifiers in its own application storage instead, and may use identifiers the operating system provides: an advertising identifier, an installation identifier, or a push notification token.
• Device and network characteristics — your IP address, screen size, language, time zone, fonts and browser version. Individually unremarkable; combined, they can form a fingerprint that recognises a device without storing anything on it.

First-party and third-party

First-party means we set it, on our own domain, and it goes to our servers.

Third-party means it belongs to another company whose code we have chosen to run on the page — an analytics provider, an embedded video player, a bot-protection service. Their technology reports to them, not to us, and they decide what it does. Note the awkward part plainly: a third-party resource embedded in our page discloses your IP address, your browser and the page you were on to that provider, even when it stores nothing on your device at all. Loading it is the disclosure.

Some third-party technologies are deliberately set up to look first-party — served from a subdomain of ours, or routed through our own servers. Where we do that, we say so in the table below rather than letting the appearance stand.

Session and persistent

Session items are discarded when you close the browser or the application. They are typically what keeps you signed in and moving through a single visit.

Persistent items survive until they expire or you delete them, which is what lets us recognise a returning visitor, remember your preferences, or remember that you refused something. Each entry in the table below states how long it lasts.

Why we use them

There are six reasons, and each one maps to one of the categories in the next section. We have written the category next to each so you can see immediately which ones you control.

• To sign you in and keep you signed in. Your session has to be attached to the right account, the right workspace and the right organisation as you move between pages, and it has to be protected against being replayed or forged by someone else. → strictly necessary
• To keep the Service secure. Telling a person apart from an abusive script, protecting forms against automated submission, enforcing rate limits, and detecting fraudulent sign-ups and payments. → strictly necessary
• To make the Service work at all. Routing your request to a healthy server, keeping you on the same one where a feature requires it, balancing load, and serving the right version of the application. → strictly necessary
• To remember what you decided about cookies. Your choice has to be stored somewhere, or we would have to ask you on every page. → strictly necessary
• To remember your preferences. Language, time zone, theme, layout, a panel you collapsed, a message you dismissed, and whether you want the support widget open. → functional
• To understand how the Service is used. Which pages and features people actually use, which paths fail, and where things are slow — so that we improve the right things rather than the ones we happen to notice. → analytics
• To measure our marketing. Whether a campaign reached anyone, which content leads to sign-ups, and which organisations show interest in the product. → marketing

Two things follow from that list, and we would rather state them than leave them implied.

Only the first four are needed for the Service to function. Everything in the last three groups is optional. If you refuse all of it, every feature you are entitled to still works, at the same price.

Where we can achieve a purpose without storing anything on your device, we do. That is the whole reason our own analytics is built the way it is — see the section on analytics without consent below.

The four categories we use

Every entry in the table below belongs to exactly one of these four categories. The banner and the preference centre use the same four names, so what you agree to and what this policy describes are the same thing.

1. Strictly necessary — no consent, because the Service cannot run without them

These are the ones we set because you asked for a service that cannot be delivered otherwise. They are not optional, they are not used for analytics or marketing, and there is no switch for them in the preference centre. If you block them at the browser level, parts of the Service will stop working.

• Session and authentication — signing you in, keeping you signed in, refreshing your session, and binding it to the correct account, workspace and organisation.
• Security — protection against cross-site request forgery, detection of abusive automated traffic, rate limiting, and fraud prevention on sign-up and payment.
• Load balancing and routing — sending your request to a healthy server and keeping you there where a feature needs it.
• Your consent choice — storing what you decided, so that we can honour it and stop asking.

Error and crash diagnostics are not in this category by default. Where we use a diagnostics tool that records more than a technical error — a reconstruction of what was on your screen, for example — it is listed under analytics and it waits for your consent.

reCAPTCHA is in this category, and here is our reasoning

We use Google reCAPTCHA — and on some surfaces an alternative provider, named in the table below — to stop automated abuse of forms such as sign-up, password reset and contact. We treat it as strictly necessary, which means it loads without asking you first.

The reason is that it protects the specific form you are trying to use. You cannot meaningfully ask for the form and refuse the protection on it: without it, those endpoints are abused within hours, which is a security failure that harms you as much as us.

What that means in practice, stated plainly:

• It collects device and behaviour signals from your browser — mouse and touch movement, timing, browser and device characteristics, and your IP address — and sends them to Google, which acts as its own controller for that data under its own privacy notice.
• We load it only on pages carrying a protected form. It is not present across the whole site.
• Where an equivalent provider is available on a surface, we prefer the one that collects less.

Not every data protection authority accepts that a bot-protection service belongs in the strictly necessary category. We think it does, for the reason above, and we would rather publish the reasoning and let you judge it than bury the tool in a list. If you would prefer not to submit a form protected this way, write to [email protected] and we will take it from you another way.

2. Functional and preferences — consent required

These remember choices you have made so that the Service behaves the way you left it: language, time zone, theme, layout, dismissed messages, and support or chat widgets where we offer them.

Refusing this category costs you convenience, not access. Everything still works; it simply forgets your preferences between visits and you set them again.

3. Analytics — consent required

These tell us how the Service is used: which pages and features are used, which paths people abandon, what is slow, and what fails. Depending on the surface this may include a provider's own persistent identifier and, where the table says so, a masked reconstruction of a session.

Third-party analytics tools are off until you turn them on, and nothing in this category loads before you choose.

There is one deliberate exception, and it is the subject of the next section: our own analytics, running on our own servers, is designed to operate without a consent requirement — cookieless, with no persistent identifier and aggregate reporting only. The next section sets out exactly what that involves and the conditions it depends on.

4. Marketing — consent required

These measure whether our marketing works and help us understand who is interested in the product: attribution of a sign-up to the campaign that produced it, and business-audience identification tools.

One of these deserves a plain sentence rather than a euphemism. Visitor identification tools resolve a visitor's IP address to the organisation it belongs to, so that we can see which companies have looked at the product. They do not tell us your name, but most people do not expect a website to work out their employer, so we would rather say it here than let you find it in a table. It is off unless you consent.

No cookie walls, ever

We do not use cookie walls, and we never make access conditional on consenting to non-essential cookies.

You can refuse everything except the strictly necessary category and the whole of the Service remains available to you — the same features, the same content, the same price. We do not offer a "consent or pay" alternative. We do not degrade the experience, hide content, or nag you on every page because you said no. Refusing is a decision we record and respect, not a negotiating position.

Our own analytics, and why it runs without asking you

We want to know whether the Service works — which pages load, which fail, whether a change made things better or worse. That is a legitimate thing for us to want, and it is also the reason most websites hand their visitors to a third-party analytics company. We built ours the other way round: we run our own analytics software, on our own servers, in our own infrastructure, and it is designed so that there is nothing about you worth asking permission for. No third-party analytics vendor receives this data. The table below names the software and where it runs.

What it does, and what it deliberately does not do

• It sets no cookies. Nothing is written to your device — no cookie, no local storage entry, nothing.
• It creates no persistent identifier. There is no visitor ID that follows you from one day to the next.
• It does not track you across sites or across devices. It measures our own site only. It has no presence anywhere else, so there is nothing to join up.
• It counts visits using a hash that is salted and rotated daily. A one-way value is derived from your IP address and browser details together with a secret salt, purely to tell one visit apart from another within a single day. We change the salt every day, which breaks the link between today's value and tomorrow's by design. The inputs are not stored.
• It reports only in aggregate — page counts, referrers, countries, browsers. No profile of you, no individual visitor record to open, nothing to hand to a marketing tool.
• It keeps data for a bounded period, stated in the table below, after which the underlying records go and only aggregate statistics remain.
• It is never used for advertising, and the data is not sold, shared for anyone else's purposes, or combined with data from another source.

Why this can run without consent, and the condition attached

Under the ePrivacy rules, storing information on your device or reading it back generally requires your prior consent, with a narrow exemption for what is strictly necessary. European regulators — the French CNIL most explicitly — have also published criteria under which a first-party audience-measurement tool can be treated as exempt: it must serve only the operator's own site, produce only aggregate statistics, avoid cross-site and cross-device tracking, avoid a persistent identifier, and keep data for a limited period.

Our configuration is built to meet those criteria. That is the whole basis on which it runs without asking you — and it is conditional on every one of the measures listed above.

We are not claiming a general permission. If we ever changed any of it — a persistent identifier, a fixed salt, measurement across more than one of our own sites, a third-party vendor, reporting at the level of an individual visitor — the exemption would no longer apply, and we would move this tool into the analytics category and ask for your consent before making the change. The category is a configuration setting in our consent system, not a paragraph in this document, precisely so that it can be changed the moment the facts change.

One further distinction worth being precise about. The exemption above is about storage on your device. Where the resulting data is still personal data, the separate question of a lawful basis under data protection law arises, and ours is our legitimate interest in understanding whether our own service works — assessed against the fact that the measurement is aggregate, short-lived and cannot be traced back to you. You can object to that processing, and the paragraph below is how.

You can switch it off anyway

You do not have to accept our reasoning to escape the measurement.

• Open Cookie preferences from the footer of any page. Our own analytics appears there with a switch, even though it runs without consent, and turning it off stops it.
• Blocking it at the browser or network level also works, and we do not try to detect or defeat that.
• Or write to [email protected] and ask us to exclude you.

We do not ask for a reason and we do not require an account.

Separately, and only with your consent, we also use third-party tools

Alongside our own analytics we use third-party analytics and marketing products. Those are a genuinely different proposition: another company receives the data, they typically use a persistent identifier of their own, and some are capable of following a visitor across other sites entirely.

Nothing in that group runs until you consent to it, and none of it is covered by the exemption described above. Each tool is named in the table below, with what it does, who operates it, and how long anything it stores lasts.

Ever Works: what is on each surface

Ever Works has four surfaces and they genuinely differ, so they are listed separately rather than merged into one table you would have to filter in your head.

Everything below in the functional, analytics or marketing categories waits for your consent. Only the strictly necessary rows load without it. If you ever see one of the others running before you have chosen, that is a defect rather than a policy — tell us at [email protected] and we will fix it.

1. The website at ever.works

Two things on this surface that are not cookies but are still disclosures. Subscribing to the newsletter sends your address to Mailchimp, which holds the list. Writing to us through the contact form sends your message through Postmark, which delivers it. Neither happens unless you use the form.

2. The application — app, api, admin and mcp at ever.works

One third-party fetch happens on the sign-in and registration pages before you have an account or a consent choice. The animation on those pages loads a WebAssembly file from a public content delivery network — jsDelivr, falling back to unpkg. Nothing is stored on your device by it, but the request itself discloses your IP address, your browser and the page you are on to that network. There is no way to fetch a file from somebody else's network and hide the request for it, so we name it here rather than let you find it. We would prefer to serve the file ourselves and intend to.

3. The documentation sites

The application and the sites we provision do not do this — they build the typeface into the page and serve it themselves, so no request reaches Google.

4. Sites we provision for customers

This policy does not govern a Work site. The operator of that site is responsible for its own cookie notice and its own consent mechanism, on its own domain. This section exists for two reasons: so that a visitor can see what the software is capable of, and so that a Work Owner can start from a real list instead of guessing.

Two things run on a provisioned site because we put them there:

Everything else is off until the Work Owner configures a key for it. Each of these is theirs to disclose and, where it is not strictly necessary, to gate behind consent on their own site:

• Analytics — PostHog, including session recording, which the template's configuration enables by default once a key is present; Google Analytics, which also reaches google-analytics.com and stats.g.doubleclick.net; Plausible; Segment; DataFast; Jitsu; and the hosting provider's own analytics and performance measurement where the site is deployed there.
• Error reporting — Sentry in the visitor's browser, including its own session replay.
• Maps — Google Maps or Mapbox, loaded when a listing shows a location.
• Bot protection — Google reCAPTCHA on forms.
• Payments — Stripe, Lemon Squeezy, Polar or SolidGate checkout scripts and frames, loaded on the pages where a visitor pays.
• Language — a cookie recording the locale a visitor was redirected to.

A Work Owner who switches any of these on has changed what their visitors must be told and, for the non-necessary ones, must be asked. Nothing in the product does that for them.

Third-party cookies and the providers behind them

Some of what runs on our pages belongs to other companies. We chose to include it, so we tell you it is there — but the provider decides what its own technology collects, and for that collection it is usually acting in its own right and under its own privacy notice rather than ours. Where that is the case, the table below links to their notice.

These are the kinds of provider involved, and what each kind does.

Analytics providers

Measure how the Service is used: page views, feature use, funnels, errors and performance. Most set a persistent identifier of their own so a returning visitor is recognised, and some can record a session replay — a reconstructed, masked playback of what happened on the screen. Where a tool on a surface can do that, the table says so explicitly.

Consent required. They do not load until you agree.

Tag management

A tag manager is a container we load once, through which other tags can then be delivered without shipping new code. That flexibility is exactly what makes it worth describing carefully: a container is a delivery mechanism, so what it delivers matters more than the container itself.

Every tag we deliver through a container is declared in the table below, in its own category. The container is consent-gated as a whole, and we do not use it to deliver anything from a category you have refused.

Consent required.

Marketing and visitor identification

Campaign measurement and attribution — which advertisement, email or article led to a visit or a sign-up — and business-audience identification, which resolves a visitor's IP address to the organisation that holds it so we can see which companies are interested in the product. It gives us a company, not your name. Most people still do not expect it, which is why it is named here as well as in the table.

Consent required.

Video, maps, fonts and other embedded content

Where a page embeds something served from another provider's network — a video player, a map, a code sandbox, a font, a script from a public content delivery network — your browser fetches it directly from that provider.

That fetch discloses your IP address, your browser and the page you were on to the provider, whether or not anything is stored on your device. There is no way to embed a resource and hide the request for it.

We handle this in two ways: where we can serve the asset ourselves, we do, which removes the third party entirely; and where an embed stores or reads anything on your device, we treat it as consent required and it does not load until you agree. Embeds that store nothing but are still fetched from a third party are listed in the table so you can see the disclosure even where no cookie is involved.

Security and delivery

The network in front of our sites — the proxy and content delivery layer that terminates the connection, absorbs attacks and filters hostile traffic — along with bot protection on forms and fraud checks on payment. These see connection metadata and may set their own security cookies.

Strictly necessary, and therefore not consent-gated. Our reasoning for putting bot protection in that category, including what it sends to its provider, is set out in the categories section above.

Where these providers are, and where to find the full list

Some of these providers are established outside the European Economic Area, and using them involves an international transfer of personal data. The transfers section of our Privacy Policy sets out the destinations and the safeguards we rely on for each, and you can ask us for a copy of those safeguards.

Two lists keep this current, and between them they are the authoritative answer:

• The table in the product-specific section below names every cookie and similar technology in use on this product's surfaces — the provider, whether it is first- or third-party, its category, its purpose, how long it lasts, and a link to the provider's own notice.
• Our Sub-processor List covers the wider set of providers that process personal data for us, including the many that never touch your device at all. You can obtain the current version at any time from [email protected], and it names the sub-processor, what it does, and where it processes.

We update both when a provider is added, removed or changed. If you find something on our pages that is not in either list, tell us at [email protected] — that is a defect and we will fix it.

Consent, and how to withdraw it

How the banner works

On your first visit we show a consent banner, and nothing in the functional, analytics or marketing categories is written to or read from your device until you have made a choice. The strictly necessary items load, because the page cannot be delivered otherwise. Everything else waits.

The first layer of the banner — the one you see without clicking anything further — carries both a Reject all and an Accept all control, presented with equal prominence. Refusing everything takes one click, exactly like accepting everything. Alongside them is a route into per-category choice, so you can accept analytics and refuse marketing, or any other combination.

Three things that some banners do and ours does not:

• No pre-ticked boxes. Every category except strictly necessary starts switched off.
• Closing the banner is not consent. Neither is dismissing it, scrolling past it, or carrying on browsing. If you do not make a choice, nothing optional is set — you simply have not decided yet.
• No dark patterns. We do not make the reject control smaller, greyer, slower or harder to find than the accept control, and we do not hide it a layer down.

Changing your mind

Withdrawing consent is as easy as giving it, and you can do it at any time.

There is a persistent Cookie preferences link in the footer of every page, and an equivalent entry inside the application's settings. It opens the same per-category controls you saw in the banner, showing what you currently allow. Change a switch and it takes effect immediately: we stop, and where we can, we remove what was stored.

Two honest limits on that:

• Withdrawal works forwards, not backwards. It does not make lawful past processing unlawful, and it does not reach into data a third-party provider already received. If you want that deleted too, ask us at [email protected] and we will tell you who holds it and how to ask them.
• Your choice is stored on the device and browser you made it on. A different browser, a different device or a private window will ask again, because there is nothing there to read. Clearing your browser storage deletes the record of your refusal as well, which is why the banner reappears afterwards.

The record we keep

When you make a choice we record what you chose, when you chose it, which categories it covered, and which version of this policy was in force at the time. That record exists for two reasons: so that we honour your choice, and so that we can show what you were asked and what you answered.

You can ask us for a copy of your own consent record at [email protected].

How long a choice lasts before we ask again

We store a consent choice for six months. After that the banner appears again so you can confirm or change it. We will also ask again sooner if we add a purpose or a category your earlier choice did not cover, or if this policy changes in a way that materially affects what you agreed to.

This is our own practice, not a legal requirement. There is no EU-wide statutory interval for asking again — six months follows regulator guidance we consider sensible and proportionate, and we have chosen to apply it. If you would rather not be asked at all, refusing everything is a decision we keep for the same six months, and blocking storage at the browser level stops the question permanently.

Controls in your browser and on your device

Our banner is not the only way to control this, and it is not the strongest one. Your browser and your operating system can enforce a choice on every site at once, including ours.

In a browser

Every major browser — Chrome, Firefox, Safari, Edge and the rest — offers the same set of controls, under privacy or site settings:

• Delete cookies and site data, for one site or all of them.
• Block cookies, either all of them or only those set by third parties.
• Clear storage on exit, so nothing survives the session.
• Private or incognito windows, which discard everything when the window closes.
• Per-site permissions, so you can allow storage on the sites you use and block it everywhere else.

Your browser's own help pages describe exactly where these live in your version — we deliberately do not reproduce click-by-click instructions here, because they go stale faster than this document does.

Content blockers and privacy extensions work on our sites too. Using one is a legitimate choice, and we build the Service so that it keeps working when the optional things are blocked.

In our desktop and mobile applications

An installed application has no browser settings to change, so the controls are at the operating-system level instead:

• Reset or limit the advertising identifier your device provides.
• Answer no to the app-tracking permission prompt on iOS, which stops access to that identifier entirely.
• Withdraw notification permission, which stops the push token being useful.
• Clear the application's stored data, or uninstall it, which removes everything it kept locally.

The Cookie preferences controls described above are also available inside the application, and they govern the same categories there as on the website.

What breaks if you block the strictly necessary ones

Blocking the optional categories breaks nothing. Blocking storage entirely does, and you should know what to expect:

• You will not be able to sign in, or stay signed in. Authentication needs somewhere to keep the session.
• Forms may fail their security check and refuse to submit.
• Some features will behave inconsistently, because requests can no longer be kept on the same server.
• We cannot remember that you refused. The record of your choice is itself stored on your device, so blocking storage means the banner returns on every visit — the one genuinely irritating consequence, and it comes from the mechanism rather than from us being difficult.

Do Not Track

Browsers once offered a Do Not Track header, and some still do. We do not treat it, on its own, as a refusal — and we would rather explain why than quietly ignore it.

No consistent standard was ever agreed for what a site should do on receiving it. It was never clear whether it expressed a considered decision or a default someone else had set, browsers behaved differently, and several have withdrawn it. A signal we cannot interpret is not a safe basis for deciding what you want.

Use the banner or the preference centre instead. A choice made there is unambiguous, and we record it.

Global Privacy Control

Global Privacy Control (GPC) is the later, better-specified signal, and unlike Do Not Track it is defined to express an actual opt-out rather than a preference.

Where we receive a GPC signal from your browser, we treat it as a refusal of the analytics and marketing categories on that browser, and we act on it without waiting for you to interact with a banner.

Two points of detail:

• It applies to the browser or device sending it. Another browser sends its own signal, or none.
• An explicit choice you make later in our preference centre takes precedence, in either direction. If you switch a category on there while GPC is enabled, we treat that as your decision, and we record it as such. If you would rather that never happened, leave the categories switched off.

Changes to this policy

We update this policy when what we do changes — a provider added or removed, a technology retired, a category reassigned. Every update gets its own version number and effective date, recorded at the end of this document.

Where a change materially affects what you agreed to — a new purpose, a new category, or a tool moving out of the strictly necessary or exempt group — we ask for your consent again rather than relying on the choice you made against the old text. Corrections, clarifications and provider renames are published with a new version and no fresh request.

Earlier versions stay available, with the dates each was in force, at https://ever.works/cookies. The effective date shown with this policy tells you which version applies today.

How to reach us

Questions about this policy, about anything in the table above, or about a choice you have made — write to [email protected]. That address is monitored and we answer it. Ask us for a copy of your own consent record, for the current sub-processor list, or to be excluded from our own analytics, and we will do it without asking why.

By post: Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria — registered in Bulgaria under company number 204599535. We correspond in English.

If you think we have handled your data badly, tell us first — we would rather fix it. You can also complain to a data protection supervisory authority at any time. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.0 of the Cookie Policy for ever.works, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://ever.works/cookies.