Cookies and tracking
Version 1.2 · Last updated 5 September 2026
Two different things get confused under this heading, so we describe them separately.
Part one is what our own website stores on your device when you visit capitis.app. That is the cookie question, and the answer is short.
Part two is what happens when a shopper clicks a Capitis tracking link on your site. That one involves no cookies at all, but it does involve personal data, and it is the part that determines what your privacy notice has to say.
Part one — cookies on capitis.app
We use strictly necessary cookies only. No analytics, no advertising, no session recording, no third-party pixels, no tracking of any kind across our marketing site, dashboard or documentation. There is nothing to consent to and no banner, because under the UK Privacy and Electronic Communications Regulations and the EU ePrivacy rules, strictly necessary cookies do not require consent.
| Cookie | What it is for | How long |
|---|---|---|
__Host-authjs.csrf-token | Stops a malicious site submitting a form to us as you (cross-site request forgery protection). Set on every visit, including before sign-in. | Session |
__Secure-authjs.callback-url | Remembers where to send you back to after sign-in | Session |
__Secure-authjs.session-token | Keeps you signed in. Set only after you sign in. | 30 days or until sign-out |
capitis_intro_dismissed | Remembers that you dismissed a first-visit explainer panel, so it does not reappear. Used only when you are not signed in; for signed-in users the same preference is stored in your account instead. | 1 year |
first_run_key | Carries your first API key from the moment your account is created to the screen that shows it to you once. Deleted as soon as it is displayed. | 5 minutes |
NEXT_LOCALE | Remembers which language you chose from the menu on the public site, so the choice survives to your next visit. Set only when you pick a language. | 1 year |
All of them are HttpOnly (unreadable by JavaScript), Secure (sent only over HTTPS) and
SameSite=Lax (not sent on cross-site requests). The __Host- and __Secure- prefixes stop
another site on a neighbouring subdomain from writing them.
To remove them, sign out, or clear cookies for capitis.app in your browser. Blocking them entirely will stop sign-in from working. Nothing else on the site depends on them.
We run no third-party scripts. Fonts, styles and images are served from our own domain.
Part two — what a tracking link records
When a shopper clicks a Capitis link on your site, they pass through capitis.app/c/… and are
sent onward to the affiliate network and then to the merchant. That hop takes a few
milliseconds. Here is exactly what happens in it.
We do not set a cookie on the shopper. Not a first-party cookie, not a third-party cookie. Nothing is written to their device by us, and nothing is read from it. There is no local storage, no device fingerprinting, and no script — the redirect is a plain HTTP response.
We do record the click, server-side, as a row in the click ledger:
| Recorded | Why it exists |
|---|---|
| Timestamp | Attribution windows; conversions arrive days or weeks later and must be matched to a click |
| IP address | Evidence of where a click came from, so a network's traffic-quality question or a complaint about a single click can be answered. Erased once the click is 90 days old |
| User agent (the browser and device string the browser sends) | Kept verbatim as part of the same evidence, and shown on the click in your reports. Erased once the click is 90 days old |
| The link, merchant and campaign | Reporting, and calculating what you are owed. Campaign is a single free-text field; there is no separate label |
| The click token | The reference that ties a later conversion back to this click — and the only thing attribution uses |
| The network the click was routed to, and the link the shopper was sent to | Reporting, and showing why a click did or did not earn a commission |
| The end-user reference the link was issued for, if any | Recognising a returning shopper across publishers. It is your own reference for that shopper; any email address, phone number or wallet address you gave us for them is stored only as a fingerprint — see below |
Four columns on that record are never filled in, and we would rather say so than let the table imply otherwise: the country of the click, the referring URL, a device classification and a fraud score. The country is only ever set from a header added by a content delivery network sitting in front of the redirect, and that header does not reach us. So we cannot tell you which of your pages produced a click, we do not sort clicks into mobile and desktop, and nothing anywhere in the platform scores a click for fraud.
IP address and user agent are personal data. We are not going to describe them as anything else. They are recorded because the affiliate networks require us to be able to evidence traffic quality, and because a question or complaint about a single click cannot be answered without them. Attribution does not depend on them — it runs on the click token alone, and no automated fraud or click-farm detection runs on them either. A job that runs every night erases both fields once a click is 90 days old; the rest of the click row stays, because it is the commission audit trail.
Identifiers reach us raw, and we hash them on arrival. If you tell us who a shopper is, you
send the plain email address, phone number or wallet address — there is no field for sending a
value you hashed yourself. The API turns it into an HMAC-SHA256 fingerprint in memory and stores
only that, so the address or number itself is not kept as the identifier. Email and phone
fingerprints are hashed a second time under a server-side secret before storage; wallet
fingerprints are not, because a wallet address is already public on the blockchain. Card tokens
are different again — they are opaque references issued by a card vault, kept as issued rather
than hashed, and we reject any value that looks like a real card number. The one thing we cannot
strip out for you is the free-text metadata you can attach to a shopper: whatever you put in
there is stored exactly as you sent it. Details on the Security page.
The click is passed on to the affiliate network. That is the entire point of an affiliate link: the network has to see the click to pay the commission. The network receives the click, the tracking reference, and whatever the shopper's browser sends it directly. The network processes that as an independent controller under its own privacy policy — not as our processor and not as yours. We cannot control or limit what it does with it.
What this means for your privacy notice
You are the controller for your shoppers' data. Your notice needs to cover, in words a normal person understands:
- That links on your site are affiliate links and may earn you a commission.
- That clicking one sends the visitor through a tracking redirect operated by Capitis, which records the click including their IP address and browser information.
- That the click is passed to an affiliate network and to the merchant, who process it for their own purposes.
- Where relevant, that you send us an identifier for them — an email address, phone number or wallet address — which we store only as a fingerprint, so a returning shopper can be recognised, and how they opt out or ask for it to be removed.
That is not our preference; it is a contractual requirement flowed down from the networks. Rakuten Advertising's publisher agreement, for example, requires a privacy notice reachable from your home page that discloses tracking devices, the data collection taking place, and the choices available to visitors. See Publisher Policy §4.
Consent
Because nothing is stored on or read from the shopper's device, the UK and EU cookie-consent rules — which govern storage and access on terminal equipment — are not what is engaged here. What is engaged is ordinary data protection law, and you need a lawful basis for the processing. Most publishers running a consent management platform will already be handling affiliate tracking inside it; keep doing that. If a network hands us a specific notice, consent or opt-out specification, we pass it to you and you must implement it.
Opting out
A shopper can ask you to remove any identifier you submitted; you can revoke it instantly from the dashboard or the API and it stops matching from that moment. They can also contact us at privacy@capitis.app, though in most cases we will need to route the request back to you. If the shopper gives us the address they used, we can fingerprint it and check it against what we hold — but the stored fingerprint cannot be turned back into an address by itself, so you are the one who can identify the shopper and revoke the identifier.
Questions: privacy@capitis.app
N888 LIMITED, 20 Wenlock Road, London, England, N1 7GU — Company Number 17434249