Reditus Privacy Notice

Version 2.1. Effective 5 August 2026. This version corrects version 2.0 of 4 August 2026, which replaced the notice dated 16 April 2025.

Reditus B.V.

Kapelweg 12, 3951 AC Maarn, Netherlands

KvK 77814487

VAT NL861156420B01

Privacy contact: privacy@getreditus.live

General contact: info@getreditus.live

This notice explains what Reditus does with personal data, why, for how long, and who else sees it. It is written to be read, not to be survived. If something here is unclear, or if you think something is wrong, write to privacy@getreditus.live and we will answer.

Section 15 lists what changed in this version and why, including the things we corrected about ourselves. Section 15.1 lists what version 2.1 corrects, after our own engineering team audited version 2.0 against the code and found statements in it that the code does not support. Some of those corrections are in our favour and some are not; both kinds are in there.

1. Which role we play, and who you should contact

Data protection law splits responsibility between a controller, who decides why and how personal data is used, and a processor, who only acts on someone else's documented instructions. Reditus is both, depending on whose data it is. Getting this right decides who you talk to when you want your data.

| If you are | Reditus is | Who decides what happens to your data | |---|---|---| | A visitor to getreditus.live, docs.getreditus.live or our status page | Controller | Reditus | | A prospect: you booked a demo, downloaded something, or we contacted you | Controller | Reditus | | A Reditus account holder or a team member on a customer's account | Controller for the account relationship: signup, billing, support, security, and product analytics and error diagnostics concerning your own use of the product, as clause 2.2 of the DPA sets out. For telemetry, error events and session replay that capture what is displayed inside a customer's account, Reditus acts as processor under clause 2.2 of the DPA | Reditus for the account relationship. For the in-app telemetry just described, the customer whose account it is | | An affiliate or a referred lead inside a customer's affiliate programme | Processor | The merchant running that programme. Reditus only acts on their instructions | | An affiliate in the Reditus marketplace whom Reditus recruited, or a person in our affiliate recruitment database | Controller | Reditus. See section 6 |

If you are an affiliate or a referred lead of a company that uses Reditus, we are not the right first stop. The merchant whose programme you joined, or whose link you clicked, decides what happens to that data. Contact them. If you cannot work out who they are, or they do not respond, email privacy@getreditus.live and we will identify them and pass the request on. We will help the merchant answer, and we do not charge them for that help.

The written terms that govern our work as a processor are in our Data Processing Agreement at https://www.getreditus.live/dpa. It applies automatically to every customer: it is incorporated into our Terms of Service, and a pre-signed PDF is available on the same page. You do not need to ask for it or sign anything.

(Role confirmed 4 August 2026: Reditus is the independent controller for network and marketplace affiliate profiles, and for its recruitment database. The vetted affiliate database contains registered affiliates who created a Reditus account and accepted our affiliate terms. The AI affiliate database additionally contains potential affiliates found from publicly available sources who have not registered with Reditus; section 6 is written for them. Once an affiliate joins a specific merchant's programme, the data inside that programme is processed on that merchant's instructions.)

2. What we do not do

It is easier to trust a list of purposes if you also know where the boundaries are. As of 4 August 2026:

The production database holding customer data is in the European Union, in Frankfurt, and the application runs in Nuremberg. Version 2.0 of this notice put that more broadly, as "all production customer data". We have narrowed it to what we have verified: details, and the four things that qualify the statement, are in section 9.
Our tracking script does not fingerprint devices. It reads no user agent, screen size, canvas, WebGL, audio, language, timezone, hardware or storage signals. This has been verified line by line across both files we serve, and re-verified in the code audit of 4 August 2026. Two caveats we owe you, because "no fingerprinting" is easy to overstate: the tracking pixel is an image request, so the browser sends its own user agent string and the connection's IP address in the request headers, as it does to any server it contacts; and we do use IP address ranges to correlate suspected self-referral fraud. Separately, the analytics and error monitoring tools we run inside our own logged-in application do collect standard device and browser characteristics. Those are listed in section 5.1.
We do not store the full IP address of a tracked visitor. Client IP addresses are truncated at the point of collection, before the event is written to our database: to /24 for IPv4 and to /40 for IPv6. This happens in the code that writes the event, not in a later clean-up job, so there is no window in which the full address sits in our database.
We set no cookie on an ordinary visit. Our tracking script writes its attribution cookie only when a visitor arrives carrying an attribution parameter, which in practice means arriving through an affiliate link. Someone who reaches a site from search, from a direct link or from anywhere else that carries no referral parameter gets no cookie from us at all.
We use no localStorage and no sessionStorage. Our tracking script reads and writes neither, anywhere. Everything it stores, it stores in the cookies described in section 5.4.
We do not ask for or want special category data: health, biometrics, political opinions, religion, trade union membership, sexual orientation, or criminal records. Do not send it to us.
We do not knowingly process the data of anyone under 18. Reditus is a business tool.
We do not sell personal data for money to third parties for their own marketing. See the caveat in section 6 about the marketplace, which we would rather flag than gloss over.
We hold no security certification of our own. No SOC 2, no ISO 27001, no penetration test we can point you to today. Section 10 says exactly what we do have. An earlier "Privacy Verified" claim on our help centre has expired and has been withdrawn.
There is no cookie consent banner on our sites today. We are not going to pretend otherwise. Section 5 explains what runs, on which site, and what we are doing about it.

3. What we use personal data for, and on what legal basis

This table covers processing where Reditus is the controller. Where we act as a processor for a merchant, the merchant sets the purpose and the legal basis, and section 4 describes what we handle in that role.

Where we rely on legitimate interests, we name the interest and summarise the balance. You can ask for the full written assessment at privacy@getreditus.live.

| Purpose | Data we use | Legal basis | Where the basis is legitimate interests: the interest, and the balance | |---|---|---|---| | Creating and running your Reditus account | Name, work email, password (stored hashed), company name, domain, role, account settings | Contract, Art. 6(1)(b) | Not applicable | | Billing, invoicing, dunning and tax records | Company details, billing address, VAT number, plan, invoices, payment and refund events from Stripe | Contract, Art. 6(1)(b), and legal obligation, Art. 6(1)(c), for the accounting records | Not applicable | | Paying affiliates we recruited into the Reditus marketplace | Name, payout email, payout amounts, and, where the affiliate is paid by bank transfer or through Wise, the IBAN, which is stored in the affiliate record and deleted with it. Payouts run on three rails: PayPal, direct IBAN bank transfer, and Wise | Contract, Art. 6(1)(b) | Not applicable | | Answering support requests and product feedback | Name, email, account identifiers, the content of your message, and the page you were on | Contract, Art. 6(1)(b), for customers. Legitimate interests, Art. 6(1)(f), for everyone else | Interest: answering people who contact us. Balance: you started the conversation, we use only what you sent, and we keep it no longer than the resolution plus a short reference period | | Booking and running demo and migration calls | Name, work email, company, chosen time, and anything you type into the booking form | Steps at your request before entering a contract, Art. 6(1)(b) | Not applicable | | Keeping the platform secure and preventing fraud and abuse | IP address, device and browser type, login and account activity logs, referral and conversion patterns | Legitimate interests, Art. 6(1)(f), and legal obligation, Art. 6(1)(c), where fraud must be reported | Interest: preventing referral fraud, account takeover and abuse of a system that moves commission money. Balance: security logging is expected of any platform handling payouts, the data is technical rather than intimate, it is not used to profile you commercially, and it is retained on a short cycle | | Understanding how the product and the website are used. Where telemetry captures personal data rendered inside a customer's account, that content is processed as processor data under the DPA, not under this row | Pseudonymous identifiers, page views, feature events, referrer, approximate location from IP, and for logged-in users the account identifier, email address, full name, role, plan and the account's monthly recurring revenue. Some product analytics events are sent to Google from our own servers rather than from your browser, as section 5.1 describes | Legitimate interests, Art. 6(1)(f), today. Consent once the consent gate in section 5 ships | Interest: knowing which parts of the product work so we can fix the parts that do not. Balance: the analysis is aggregate and it is not used to make decisions about individuals. PostHog storage is in the EU; Google Analytics data is collected in the EU and then forwarded to Google servers in the US, as section 5.1 states. We accept that a consent step is required for these technologies under Dutch and EU e-privacy rules and we are building one | | Diagnosing errors, including masked session replay, in the product app. Where an error event captures personal data displayed inside a customer's account, for example affiliate names or payout details in a merchant dashboard, that content is processed as processor data under clause 2.2 of the DPA, on the customer's instructions, and not under this row | Everything above plus recorded page interactions and navigation with the on-screen text and media masked, console output, and the account identifier, email address and name attached to the event | Legitimate interests, Art. 6(1)(f), today. Consent once the consent gate ships | Interest: reproducing and fixing faults that customers cannot describe over email. Balance: replay is limited to page structure and interaction because text and media are masked at capture, the sampling rates and exactly what is and is not masked are in section 5.2, and it is still first in line to move behind consent | | Identifying the company behind a website visit | IP address, and the organisation, domain and industry looked up from it, plus the pages visited | Legitimate interests, Art. 6(1)(f) | Interest: knowing which companies are evaluating Reditus so sales effort goes where there is genuine interest. Balance: the output is company level rather than personal, we do not attempt to name the individual visitor, and you can object at any time | | Sending marketing to people who asked to hear from us | Name, work email, company, and engagement with previous emails | Consent, Art. 6(1)(a), or the soft opt-in for existing customers under Dutch telecommunications law | Not applicable | | Cold outreach to business prospects who did not ask | Work email, name, job title, company, company website, publicly stated technology and market signals | Legitimate interests, Art. 6(1)(f). Not consent. See section 3.1 | Interest: reaching the specific people at B2B SaaS companies who run or would run an affiliate programme. Balance: business contact data used in a professional context, targeted rather than bulk, one click removes you permanently, and we never use it for anything except a first contact about Reditus | | Building and maintaining our affiliate recruitment database | Name, work email, company, website, public profile links, audience and topic signals, public traffic and domain metrics, contact history | Legitimate interests, Art. 6(1)(f). See section 6 in full | Interest: operating a two sided marketplace, which requires knowing who works as a B2B SaaS affiliate. Balance: professional data about a professional activity, much of it published by the person to advertise exactly this work, no special categories, no sensitive inferences, and an unconditional one click exit | | Advertising and campaign measurement | Advertising identifiers, click identifiers, page URLs, and conversion events | Consent, Art. 6(1)(a), which we do not currently collect. See section 5 | Not applicable. We do not claim legitimate interests for advertising tags | | Publishing content, author profiles and customer case studies | Name, job title, company, photo, biography, public profile links, and quotes given for publication | Consent, Art. 6(1)(a), from the person featured | Not applicable. Published content is public by design and is indexed by search engines | | Meeting legal obligations and defending legal claims | Whatever is relevant to the obligation or the claim | Legal obligation, Art. 6(1)(c), and legitimate interests, Art. 6(1)(f), for defending claims | Interest: establishing, exercising or defending legal claims. Balance: use is limited to the specific dispute and the data is not repurposed | | Running the company: accounting, banking, insurance and corporate records | Contact and transaction data of customers, suppliers and contacts | Legal obligation, Art. 6(1)(c), and legitimate interests, Art. 6(1)(f) | Interest: administering a company properly. Balance: routine, expected, and limited to what the records require |

Whether you have to give us data. The account, billing and payout fields marked "Contract" above are required: without them we cannot open an account, invoice you or pay you. Everything else on this list is optional, and declining it costs you nothing except the feature it powers.

3.1 Two kinds of outbound email, and why we split them

The previous version of this notice declared all marketing under "Consent". For cold outreach that was not true, and stating it did nobody any favours.

If you gave us your address, by signing up, downloading something, or asking to be kept informed, we email you on the basis of your consent, or on the soft opt-in that applies to existing customers being told about similar products. Every message carries an unsubscribe link, and withdrawing is instant and free.

If we contacted you cold, at a business address we found or inferred, the basis is legitimate interests, not consent. You never agreed to anything and we are not going to claim you did. Under Art. 21(2) you have an absolute right to object to direct marketing: no reason required, no balancing exercise on our side, and we must stop. Use the unsubscribe link, or write one line to privacy@getreditus.live. We remove your record and we will not contact you again.

One honest caveat about what "we will not contact you again" rests on. The suppression list that would guarantee a later data import cannot re-create your record is engineering work in progress, checked at ingest rather than at send time, and until it ships we do not claim that protection as a built mechanism. What we commit to is the outcome: if a record about you ever reappears, one more email removes it again, without conditions.

4. What we handle as a processor for our customers

When a company uses Reditus to run an affiliate or referral programme, that company is the controller and we act on its instructions. In that role we typically handle:

The merchant's affiliates and advocates: name, email, payout details, programme terms, commissions earned, links and assets, performance data, and any public profile data the affiliate adds.
Leads and customers referred through a tracked link: a randomly generated visitor identifier, IP address, referring URL, the page URL, timestamps, and optionally an email address, a customer identifier and other fields the merchant chooses to send.
The merchant's own transaction data, where the merchant connects Stripe so that commissions can be attributed to sales.

Six things about this are worth stating plainly, because most notices in this category do not.

The merchant decides how much personal data reaches us. At the click stage our script sets a cookie holding a randomly generated identifier and the attribution data, and it does not add a name or an email address of its own. Whether an email address ever reaches us depends on what the merchant sends at signup or sale, and on which of the integrations below the merchant has connected.

Our script transmits what the merchant gives it, but our server keeps only a fixed list of fields. Version 2.0 of this notice said there was no allowlist. That was wrong, and wrong in a direction that made us look worse than we are, so here is the accurate position. The script sends what the merchant passes to it, including any field with an m_ prefix. Our tracking endpoint then reads exactly eighteen named parameters and discards everything else it receives: evt, ref, url, ip, grid, m_email, m_uid, m_source, m_cal_event, m_cal_user, m_hub_utk, customer_id, affiliate_slug, cslug, ctype, pk, rl and sid. A field a merchant invents that is not on that list is not stored. That is a real limit, not a policy statement, but it is not a reason to send us more than you need: merchants should still keep special category data, government identifiers and free-text notes out of those fields, because m_email, m_uid and the free-form sid value will be stored exactly as sent.

We parse stored page URLs for Google advertising parameters. Where the page URL we receive contains gclid, gad_source or gad_campaignid, we read those values out of it. We use them for one purpose, detecting affiliates who are bidding on paid search ads in breach of a merchant's programme terms, and the result is a flag for a human at the merchant to look at, not an automatic rejection. This was not disclosed before.

We also read referral parameters set by other affiliate networks. Where a visitor arrives with a referral parameter belonging to another network in the URL (via, wpcr, fpr, fp_ref, ps_partner_key or awinmid), our script records that value and the network it came from, stores it in our own attribution cookie for the life of that cookie, and sends it to our tracking endpoint. We read it from the URL only. We do not read any other network's cookies or storage. Note that for one of the six the value is the merchant's identifier rather than the affiliate's.

Two exceptions are on us, not on the merchant. Where a merchant runs both our script and a HubSpot form or meeting widget, our own integration code reads the end user's email address from that submission and sends it to us by default, in the query string of the tracking request. Calendly behaves the same way: where a merchant connects Calendly, our own server code resolves the invitee's name and email address from the booking and stores them. Version 2.0 disclosed the HubSpot case and missed the Calendly one. We are disclosing both rather than leaving them for a customer to discover, and the defaults are being changed. A customer that does not want this today can disable the HubSpot or Calendly integration for its account. Any customer who wants help should email privacy@getreditus.live.

About sending an internal identifier instead of an email address. Version 2.0 of this notice, and earlier drafts of our DPA, described a "UID mode" in which no directly identifying data about referred persons reaches us at all. There is no such mode, and the claim was too strong. What is true: the merchant may send an internal identifier instead of an email address; where the merchant does so and does not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address. Three things qualify that even then. Our own installation documentation asks merchants to send both an identifier and an email address, and the in-product snippet offers the email field, so most installations send an email address whether or not an identifier is also sent. Each of the Stripe, HubSpot and Calendly integrations independently brings the email address to us, so the identifier alone only helps if none of them is connected. And the identifier itself is free text that we do not validate: if a merchant puts an email address or a name in that field, that is what we store. An internal identifier makes the data pseudonymous, which is a real reduction in risk; it does not make it anonymous, and it remains personal data.

Our cookies and what the tracking script transmits are described in the cookie policy at https://www.getreditus.live/cookie-policy, and the contractual detail is in the DPA.

5. Analytics, advertising, cookies and session replay, honestly

The notice before version 2.0 described our website and our product app as if they carried the same tools. They do not, and it had them the wrong way round. Version 2.0 fixed that but got several of the tools themselves wrong, in both directions. Here is the picture as our own code audit of 4 August 2026 found it.

5.1 What runs where

On the marketing site, getreditus.live:

| Tool | What it does | Notes | |---|---|---| | PostHog | Product and website analytics | Session replay is not enabled, here or anywhere else. Events are sent to an EU endpoint and stored in Frankfurt | | Leadfeeder (Dealfront) | Looks up which company an IP address belongs to | Sets the _lfa cookie for 24 months | | Featurebase | Chat and product feedback widget on this site. Visitors here chat anonymously: the marketing site has no sign-in, so nobody is identified to Featurebase and the conversation is attributed by whatever email address you leave. Version 2.0 of this notice described Featurebase as the chat inside the product; that was wrong, the in-product chat is HubSpot Conversations | Loads about 5 seconds after the page | | Guideflow | Interactive product demo embeds | Sets a third party cookie with two identifiers, roughly 2 years, on load | | Our own tracking script | Attribution for our own affiliate programme | First party, and it sets no cookie at all unless you arrive with an attribution parameter. See section 5.4 and the cookie policy | | Calendly | Booking widget embedded on our demo and migration booking pages | Sets Calendly's own cookies on load. Our embed currently passes hide_gdpr_banner=1, which suppresses Calendly's own consent notice. We are removing that parameter, and the Calendly cookies are listed in our cookie policy in the meantime |

Google Analytics and Google Tag Manager do not run on the marketing site. They run in the product app, which is the opposite of what the previous notice said.

In the product app, app.getreditus.live:

| Tool | What it does | Notes | |---|---|---| | Google Tag Manager | Loads the tags below. Container GTM-PSMWBCS, loaded in production only | Runs app wide, including on /login, /signup and the public /marketplace page. A tag manager can load further tags without any change to our application, which is exactly why it is named here rather than folded into the row below | | Google Analytics 4, in your browser | Product usage analytics | Collected in the EU, then forwarded to Google servers in the US | | Google Analytics 4, from our servers | A second, server-side stream. Our backend sends Google its own events about product milestones, for example when a customer finishes installing the tracking script | Distinct from the browser tag above, and distinct again from any Google Analytics property an affiliate connects to their own account under 8.4. It was not disclosed before | | Google Ads and DoubleClick | Advertising conversion measurement | Google is an independent controller here, not our processor | | LinkedIn Insight Tag | Advertising audience and conversion measurement | Fires on every page load, including pages used by affiliates. LinkedIn is an independent or joint controller | | Leadfeeder | Company lookup from IP | Same tracker as the marketing site | | HubSpot Conversations | The support chat inside the product | It is mounted on every page for every logged-in user and receives that user's email address together with a signed identification token, whether or not anyone opens the chat. Version 2.0 of this notice named Featurebase here. That was wrong: Featurebase runs on the marketing site, HubSpot runs in the product | | Paragon | Embedded integration platform. It brokers the third-party connections a customer switches on | Loaded in the product front end. Version 2.0 listed Paragon as no longer in use. That was wrong | | PostHog | Product analytics. No session replay | For logged-in users PostHog receives the account identifier, email address, full name, plan and monthly recurring revenue. Events go to an EU endpoint and are stored in Frankfurt; the PostHog interface our own team logs into is hosted in the United States. See 5.2 | | Sentry | Front-end error tracking and masked session replay | Browser only: there is no Sentry agent in our backend. See 5.2. Sent to Sentry's US region |

On docs.getreditus.live: the documentation is hosted by Mintlify and loads our own PostHog project.

On status.getreditus.live: the status page is provided by Better Stack. It loads Better Stack's own Google Analytics and Google Ads tags, which we did not add and are asking them about.

5.2 Session replay, corrected

This section is a correction, and it corrects in your favour. Version 2.0 of this notice, published on 4 August 2026, said that PostHog recorded 100% of sessions inside the product with no pages excluded and with names, email addresses and bank details left unmasked. Our own engineering team audited that statement against the code the same day, and it is not what the application configures. We are not going to leave an alarming description up simply because it is the cautious one. Here is what the code actually does.

PostHog session replay is not enabled in our code. There is no session recording configured for PostHog anywhere in our application or on our marketing site, so nothing in what we ship tells PostHog to record your screen. One limit on that sentence, which we would rather state than have you find: PostHog allows recording to be switched on at the project level, in its own dashboard, without any change to our code. We are describing what our code does, because that is what the audit read. What PostHog does receive, for logged-in users, is ordinary analytics events with the account identifier, email address, full name, plan and the account's monthly recurring revenue attached. That is real personal data going to an analytics provider and we are not minimising it, but it is event data, not a recording of your screen. Events are sent to PostHog's EU endpoint and stored in Frankfurt, Germany. The PostHog interface our own team logs into is hosted in the United States, which is why PostHog is listed in section 8.1(a) with Standard Contractual Clauses rather than as an EU-only recipient.

Sentry session replay is enabled, and it is masked. Sentry replays 10% of sessions in the product app plus 100% of sessions in which an error occurs. The recorder is configured to mask all text and to block all media, so a replay shows page structure, layout, navigation and the sequence of clicks, and not the words on the page, the values in the fields or the images and documents displayed. Console output is captured. Sentry runs in the browser only: there is no Sentry agent in our backend, so backend requests and database contents are not sent to Sentry. Error events carry the user identifier, email address and name by design. Sentry data goes to Sentry's United States region; the transfer safeguard for that leg is the Standard Contractual Clauses, as the Sentry row in section 8.1(a) states.

We replay sessions for one purpose only: error monitoring and bug diagnosis, so that faults customers cannot describe over email can be reproduced and fixed. We do not use replays for marketing, profiling or anything else.

What this means for the risk version 2.0 described. That version warned that bank details or affiliate names displayed on screen could end up sitting in a recording. On the facts, they do not: PostHog is not configured to record, and Sentry masks all text and media at the point of capture. The masking is set explicitly in our own client configuration. It is not a library default we happen not to have changed, and the audit read the two settings that do it. What remains is smaller than that: documenting the masking rules screen by screen, so that a new screen cannot quietly fall outside them, and deciding whether console capture should stay on. That work is on our engineering list. It is a hardening task, not an open exposure, and we are describing it as the former.

Retention of replays and error events is set by our error tracking provider's plan; see section 12.

If you would rather not be replayed at all, email privacy@getreditus.live. There is no self-serve opt-out today, so we will handle it manually for your account.

5.3 Consent

There is no cookie consent banner on our sites today. Analytics and advertising tags load before anyone has been asked. We are not claiming an exemption we have not thought through, and we are not going to describe a preferences manager that does not exist.

One qualification we owe you, because absence of a banner is a gap but switching off someone else's banner is an act. Our demo and migration booking pages embed Calendly, and that embed is currently configured to suppress Calendly's own consent notice. We are removing that setting, and this paragraph will be rewritten in the past tense when it ships.

What we are doing: building a consent gate that blocks analytics and advertising tags until you opt in, keeping only our own attribution cookie outside the gate, and documenting the reasoning for each vendor rather than applying one blanket claim. We are not publishing a ship date, because the previous version of this notice promised things with no dates attached and we would rather describe the gap accurately than decorate it: until the gate ships, the tags load without consent, and that is the state you should assume.

Until then, you can control cookies through your browser settings, and you can object to the analytics and company lookup processing by emailing privacy@getreditus.live.

A full per cookie list, with name, provider, purpose and duration, is in the cookie policy at https://www.getreditus.live/cookie-policy.

Three tools we used in the past, Hotjar, Segment and Crisp, do not load on any public page we have tested, and we have tested every public page we could crawl. Two limits on that, both of which we would rather state than round off. We have not yet run the same test inside the logged-in application, which is the surface where such a tag would most plausibly still be live. And a Hotjar site remains provisioned on our account, configured for full session recording with keystroke capture, even though nothing we have tested loads it. Section 8.6 states where that stands.

5.4 Our own cookies, in detail

The full per-cookie table, including third party cookies, is in the cookie policy. Seven facts about our own three cookies belong here, because version 2.0 of this notice got several of them wrong and because two of them are better than that version implied.

No cookie is set on an ordinary visit. Our tracking script writes its attribution cookie, _gr_id, only when the visitor arrives carrying an attribution parameter, in practice an affiliate link. A visitor arriving from search, from a direct link or from anywhere else without such a parameter is not given a cookie by us at all.
We use no localStorage and no sessionStorage. The tracking script reads and writes neither, on any site. Everything it keeps is in the cookies described here.
_gr_id lasts longer than its stated period on an active visitor. The default life is 60 days, and a merchant can configure any value from 1 to 119 days. Version 2.0 said "1 and 120". More importantly, the expiry is a sliding window: each qualifying visit rewrites the cookie with a fresh expiry, so someone who keeps clicking a merchant's links keeps the cookie beyond the configured number of days, potentially indefinitely while they stay active. Version 2.0 presented the configured number as the real retention period. It is the period since the last qualifying visit, not the period since the first.
_gr_id holds eleven fields, not one identifier. Alongside our own randomly generated visitor identifier and the attribution data, it can carry the merchant's own internal user identifier and a free-form session value the merchant sets. Whether either of those identifies a person is the merchant's choice and not ours, which is why section 4 asks merchants to be careful about what they put in them.
_gr_referral_widget holds personal data in cleartext. Where a merchant enables the in-product referral widget, this cookie is set on the merchant's own domain and holds the advocate's email address, first name, last name, company name, a company identifier, a product identifier and a widget authentication token, unencrypted, for 30 days.
_gr_cookietest is set by the referral widget, not by the tracking script. It is a one-off check of whether cookies work at all in that browser. Version 2.0 attributed it to the wrong script.
None of our three cookies currently sets the Secure, HttpOnly or SameSite attributes. We would rather state that than wait until it is fixed. It matters most for _gr_referral_widget, because that is the one carrying a name, an email address and an authentication token in plain text. Adding those attributes is on the engineering list.

6. If you never signed up: our affiliate recruitment database

This section is about people we hold data on who never created a Reditus account and never gave us their details. Art. 14 of the GDPR says we have to tell you, so here it is in full.

Reditus is the controller for this data.

6.1 What we hold and where it comes from

We maintain a database of people who work, or publicly present themselves as working, as affiliates, partners, creators, newsletter operators, review site owners or content marketers in the B2B SaaS space. We use it to introduce them to affiliate programmes, including programmes run by our customers and our own marketplace.

The categories of source are:

Public professional profiles and directories where a person advertises affiliate, partner or content marketing services.
Public company and creator websites, including their contact and about pages.
Public search engine results and publicly available domain and traffic metrics about the sites a person runs.
Public social and video platform profiles, where the person has published their contact details or channel data.
Affiliate and creator marketplaces and networks where profiles are published.
Referrals, where a merchant or an existing affiliate suggests someone.
Third party data enrichment and crawling services, which add or verify company and contact fields.

The data held per person is typically: name, work email address, job title, LinkedIn handle, company or site name, website, public profile links, the topics and audience they cover, public traffic or domain metrics for their site, a machine-generated fit score and written fit assessment for particular programmes, and a record of whether we have contacted them.

If you ask us about your own record under Art. 15, we will tell you which of these sources it came from, so far as we hold source information for it, and we will say so plainly if we do not.

Where this data sits, and which providers touch it. Version 2.0 of this notice said the pipeline behind this database was an internal research exercise that did not run in production, and left the providers unnamed. Our code audit of 4 August 2026 established that it does run in production, so here it is, named.

The pipeline runs on n8n, a hosted workflow automation service. It receives the search criteria a merchant enters, which are business criteria rather than personal data, and it processes candidate records containing name, email address, job title and LinkedIn handle.
Hunter performs the enrichment step. It is the only step in the pipeline that processes personal data as its purpose: it takes a candidate's name, email address and LinkedIn profile, and the enriched result is written back into our own database. The call is made from inside n8n rather than from our application, which does not change the fact that the enriched personal data ends up with us.
DataForSEO supplies site, company and search data. It returns no personal data in this pipeline.
A Google large language model produces the fit score and the written reason for it. Under Google's EEA terms, prompts and outputs are not used to train Google's models.
The scraped candidate records live in a second, separate database project with Supabase, distinct from the database that runs the product. We are naming it because a reader is entitled to know that this data sits in its own store rather than being mixed into customer data, and because a database of people who never signed up should be findable when someone asks us to delete their record.

All five are named in section 8 with their transfer mechanisms.

6.2 Why we think this is lawful, and where the balance sits

Our legal basis is legitimate interests, Art. 6(1)(f).

The interest, named: operating a two sided affiliate marketplace, which is only possible if we know who the affiliates are, and introducing those people to paid partnership opportunities in the field they already work in.

What merchants pay us for, stated exactly. Merchants pay for the Reditus platform in plan tiers, and the higher tiers include access to two databases, which are different and we describe them separately. The vetted affiliate database contains registered affiliates: people who created a Reditus account and accepted our affiliate terms so that merchants can find them. That is the point of joining the network, and it is stated in the affiliate terms at signup. The AI affiliate database is a recruitment database of potential affiliates compiled from publicly available sources. The people in it have not registered with Reditus, and merchants on qualifying plans can search it to find affiliates to invite to their programmes. What the code confirms today is that a merchant on a qualifying plan is shown the machine-generated match score for a candidate and the written reason behind it, alongside that candidate's profile. If you are in that database, this section is your notice: it explains what we hold, why, and how to be removed permanently with one email, without conditions. We do not sell lists of personal data.

The balance, summarised: the data is business contact data about a professional activity, not private life. A large share of it is published by the person precisely so that companies like ours will contact them about partnerships. We collect no special category data, we make no sensitive inferences, and we do not build profiles about anyone's private circumstances. Against that, we recognise two things that weigh the other way: the person did not choose to be in our database, and a database that is searchable by individual person is more intrusive than one that is not. Our answer to that is transparency and an exit that costs nothing: this section, a link to it in the first email we send, and an opt-out that we honour permanently and without conditions.

We are documenting a written legitimate interests assessment per source category, and a data protection impact assessment. Neither is finished today, which is why this sentence is in the present tense; both will be available in summary on request once they are, and this paragraph will change to the past tense then and not before.

6.3 How long we keep it

Once the suppression list described at section 3.1 is in production, records for people who have opted out will be reduced to the minimum needed to keep the opt-out working, which is the email address and the date, and will be kept indefinitely for that purpose only. That describes the practice we are building, not one that exists today; section 3.1 states where the suppression list stands.

6.4 Getting out, unconditionally

One click in any email we send you removes you. That is the whole process.

We do not ask you why.
We do not ask you to create an account, log in, or confirm through a second step.
We do not offer to "reduce the frequency" instead.
We do not make it conditional on anything.

You can also write one line to privacy@getreditus.live. We will remove your record. As section 3.1 explains, the suppression list that would stop a later import bringing you back is still being built; until it ships we do not claim that protection, and if a record about you reappears, telling us once more removes it again.

You have the same rights here as anyone else, set out in section 13. Two are worth calling out for this group: under Art. 21(2) your objection to direct marketing is absolute and we must stop, and under Art. 15 you can ask us for a copy of everything we hold about you and where it came from, so far as we hold source information for your record.

7. Automated decision-making and profiling

We profile, and we should say so. Two features do it.

Affiliate matching and scoring. We rank and score affiliates against a merchant's product, industry and customer profile so that merchants can see who is likely to be a good fit. Inputs are the fields in section 6.1: topics covered, audience, public site metrics, category and past programme performance where we have it. The score and the written reason for it are produced by a large language model, through the pipeline named in section 6.1, and both are shown to merchants on qualifying plans.

Prospect scoring on our own sales side. When someone uses a tool on our website or asks for a demo, we score the company against our customer profile to decide how our own sales team responds. Inputs are company level, such as revenue band, customer count, category and the affiliate tooling in use.

Neither produces a decision with legal or similarly significant effects made solely by automated means. A score is a ranking and a suggestion. A human at the merchant decides who to approach, who to accept into a programme and on what terms, and a human at Reditus decides how to respond to a prospect. No score by itself opens or closes an account, sets a commission rate, blocks a payout or terminates a relationship.

Your rights here. Because this profiling relies on legitimate interests, you have the right under Art. 21(1) to object to it on grounds relating to your particular situation, and under Art. 21(2) an absolute right to object where it is used for direct marketing. Write to privacy@getreditus.live. You can also ask what a score is based on, ask us to correct an input that is wrong, and ask for it to be reviewed by a person.

Artificial intelligence. One feature on our website, the AI Citation Finder, sends the text you type into it to a third party search data provider, which runs it against large language model services on its own accounts. Your email address, brand and product URL are not sent to that provider. Reditus does not use anything you type into that tool to train any model. The free-text category you enter is used to produce your result and for nothing else; we are verifying that no copy of it persists in our logs once the result is produced, and until that check is done we will not claim here that none does. Your email address is treated differently: it is held for up to 24 hours in the edge store described in section 9 for rate limiting, and it is used as a sales lead, as described under prospect scoring earlier in this section and in the section 3 purpose table. What we cannot promise on our own behalf is the upstream position: the provider runs your text against third party large language model services on its own accounts, under its terms rather than ours. If you would rather that did not happen, do not put anything confidential into the tool.

This is not presented as a closed list, because we are still completing our own inventory of AI use, and we would rather say that than fake completeness. Two statements in version 2.0 have to be withdrawn, because our code audit of 4 August 2026 established that they were wrong.

Version 2.0 said that no feature in the product app had been established as sending personal data to a large language model at query time, and that the pipeline classifying recruitment-database records was a pilot that did not run in production. Both were wrong. The affiliate matching and scoring feature runs in production. It works by sending the merchant's search criteria to a hosted workflow automation service, n8n, which enriches and scores candidate records and returns a match score and a written reason that are then shown to the merchant. The candidate records in that flow contain names, email addresses, job titles and LinkedIn handles. The language model is a Google model, called from inside n8n; Hunter performs the enrichment step; DataForSEO supplies site and company data and no personal data. All four are named in section 8 and described in section 6.1, and the processing they perform sits under the recruitment-database row of the section 3 purpose table.

Two limits on that, both of which the audit supports. The search criteria a merchant types are business criteria for finding potential affiliates, not personal data about the merchant's own users. And under Google's EEA terms, prompts and outputs sent to that model are not used to train Google's models.

Our Data Processing Agreement commits us to naming any AI service provider that processes customer personal data as a sub-processor before it begins or continues doing so. We are also confirming how AI-produced output in our tools must be labelled under Art. 50 of the AI Act, whose transparency duties have applied since 2 August 2026, and we will update this section when that inventory closes.

8. Who receives personal data

One table, one row per recipient, with the transfer mechanism stated per recipient rather than as a general reassurance at the end.

Two notes on how to read it. First, we describe the contracting entity and its country, which is what decides the transfer question, not the country where a server happens to sit; where those differ we say so. Second, we do not publish claims about the internal security controls of companies we cannot inspect. Every recipient below is under a written contract containing security and confidentiality commitments, and that is the accurate way to put it.

You can request a copy of the Standard Contractual Clauses for any recipient below, with commercial terms removed, at privacy@getreditus.live.

8.1 Providers that process personal data on our instructions

These are the same two lists we publish at getreditus.live/sub-processors. If they ever differ, the sub-processor page is the canonical one. Only the companies in 8.1(a) are sub-processors of our customers' data, and only changes to that list trigger the notice and objection rights in section 9 of the DPA.

8.1(a) Sub-processors: providers that may process your affiliate, referred-lead and account data

| Recipient (legal entity) | Country | What they do for us | Transfer mechanism | |---|---|---|---| | Hetzner Online GmbH | Germany (Nuremberg) | Hosting for the Reditus application | No restricted transfer. Data stays in the EEA | | Supabase Pte. Ltd | Singapore is the contracting entity; data is stored in Frankfurt, Germany | The application database, and only the database. Version 2.0 of this notice also credited Supabase with our authentication and our file storage. Neither is true: account authentication runs inside our own application with password hashes held in our own database, and uploaded files are stored in Cloudflare R2, in the row below. A second, separate Supabase project holds the affiliate recruitment data described in section 6; that project is listed in 8.1(b), because that data is ours as controller rather than a customer's | Standard Contractual Clauses, Modules Two and Three, plus UK and Swiss addenda, under Supabase's DPA v1 of 1 August 2026. Singapore has no EU adequacy decision, so the clauses are required even though the data sits in the EU | | Amazon Web Services, as a sub-sub-processor beneath Supabase | Being verified | Not a company we contract with directly. It is the cloud our database provider's EU project runs on, so it sits underneath the row above rather than beside it. We name it because a reader doing supply-chain diligence is entitled to know where the chain ends, and because our own code contains S3-protocol libraries that make it look as though we use AWS directly. We do not: those libraries talk to Cloudflare R2. | Inherited through our Supabase contract and the clauses named in the row above | | Cloudflare, Inc. | USA | DNS, content delivery, TLS termination on all our domains, and edge compute for the marketing site. Cloudflare does more for us than version 2.0 said: all files uploaded into the product are stored in Cloudflare R2, which is our file storage, and Cloudflare also hosts the tracking script itself. Cloudflare's key-value store additionally holds, for up to 24 hours, the email address and IP address of visitors who use the tools on our website, for rate limiting and lead routing. That store is not pinned to a jurisdiction, so those values may be replicated outside the EU | Standard Contractual Clauses, Module Three; the controller-side leg for our own processing is papered separately, as with every dual-role provider in this table. Cloudflare also holds an EU-US Data Privacy Framework certification, which we treat as supporting evidence and not as our primary mechanism | | n8n (contracting entity being verified) | Being verified | Hosted workflow automation. It runs the affiliate discovery, enrichment and matching pipeline described in sections 6.1 and 7: it receives the merchant's search criteria, processes candidate records containing name, email address, job title and LinkedIn handle, calls Hunter and a Google language model, and returns match scores and written reasons. Our application stores the full body of what n8n sends back, as received | Stated once the contracting entity is verified; until then we do not claim one here | | HubSpot (contracting entity being verified against HubSpot's jurisdiction-specific terms) | Being verified; onward access reaches HubSpot, Inc. in the USA | Two roles in addition to the customer-facing integration in 8.3, and neither was disclosed before. One, the support chat inside the product: it is mounted on every page of the application for every logged-in user and receives that user's email address with a signed identification token, whether or not the chat is opened. Two, our own CRM synchronisation, which sends affiliate and customer contact records out of our database into our HubSpot account | Standard Contractual Clauses, Module Three, where data reaches HubSpot, Inc. in the United States. Confirmed once the contracting entity is verified | | User.com sp. z o.o. (being verified) | Poland | Our own messaging and notification account receives referral, lead and affiliate notifications containing names, email addresses and countries. This is separate from the User.com integration a customer can switch on for its own account, which is in 8.3, and it was not disclosed before | No restricted transfer at this level | | Slack Technologies Limited (Ireland) and Slack Technologies, Inc. (USA), under the Salesforce Data Processing Addendum | Ireland and USA | Internal messaging, and roughly thirty kinds of automated system notification posted into our own workspace, including affiliate-created and commission-paid events, which carry names and email addresses. The vendor is listed once, here, because the sub-processor relationship is the stricter one | Standard Contractual Clauses, Modules Two and Three. Slack's default data residency is the United States | | Paragon (Useparagon, Inc., contracting entity being verified) | USA, being verified | Embedded integration platform loaded in the product front end. It brokers the third-party connections a customer switches on, so it handles those connection credentials and the records that pass through them. Version 2.0 of this notice listed Paragon under "providers we no longer use". That was wrong: it is live in the product | Standard Contractual Clauses, Module Three, to be confirmed with the entity. We do not claim an executed mechanism here today | | Calendly LLC | USA | Two roles. Our own demo and migration bookings, where we are the controller, and a product-side role that was not disclosed before: where a merchant connects Calendly, our server resolves the invitee's name and email address from the booking so that the meeting can be attributed to an affiliate. The vendor is listed once, here, because the second relationship is the stricter one | Standard Contractual Clauses, Modules Two and Three. Calendly also holds a Data Privacy Framework certification, which we treat as supporting evidence only | | Stripe Payments Europe, Limited | Ireland | Our own subscription billing, and reading a merchant's Stripe transactions to attribute commissions where the merchant connects it | No restricted transfer at this level. Stripe's onward transfers are covered by its own agreement. See 8.2 for the part where Stripe acts on its own account | | PayPal (Europe) S.à r.l. et Cie, S.C.A. | Luxembourg | Default affiliate payout rail, and one of three. The other two are a direct IBAN bank transfer from our own bank, which is not a disclosure at this level because no third party processor is involved, and Wise in the row below | No restricted transfer at this level | | Wise Europe SA | Belgium | Affiliate payouts, one of the three rails described in the row above. The IBAN an affiliate gives us is stored in their affiliate record and encrypted at the application level. Payouts through Wise are initiated by us operationally rather than by an API call from our application | No restricted transfer at this level | | Twilio Inc., trading as Twilio SendGrid | USA | Transactional email: account, notification and payout emails. SendGrid also sends our own templated marketing email, where we are the controller (see section 3); the vendor is listed once, here, because the sub-processor relationship is the stricter one | Standard Contractual Clauses, Module Three | | Functional Software, Inc., trading as Sentry | USA, US region ingest | Front-end error tracking and masked session replay in the product app. Browser only: there is no Sentry agent in our backend | Standard Contractual Clauses, Module Three. Functional Software also holds a Data Privacy Framework certification, which we treat as supporting evidence only | | PostHog, Inc. | USA is the contracting entity; event data is stored in Frankfurt, Germany | Product and website analytics. No session recording is configured in our code, contrary to what version 2.0 of this notice said; see the project-level qualification and marker at section 5.2. For logged-in users PostHog receives the account identifier, email address, full name, plan and monthly recurring revenue | Standard Contractual Clauses, Module Three. There is no EU contracting entity, and the interface our team uses is hosted in the United States, so the clauses are required even though event storage is in the EU | | Honeybadger Industries LLC | USA | Backend error tracking only. Its log-ingestion product is disabled, application logs are written to standard output rather than shipped to Honeybadger, and error reports carry no user-context tagging. Version 2.0 of this notice credited it with performance monitoring and application logging as well; it does neither for us, which means less of your data leaves the EU than that version implied. Replaced AppSignal | Standard Contractual Clauses, Module Three | | Plane Software, Inc. | USA (Delaware). The hosted cloud service, running on Amazon Web Services in the United States | Issue tracking: the tool in which we raise and work our own tickets. A ticket can contain the identity and contact details of the person who raised it, and whatever they included in their report | Standard Contractual Clauses, Module Three | | LinkedIn Ireland Unlimited Company | Ireland | The connection an affiliate authorises to their own LinkedIn account, from which we read and store that affiliate's profile data against their affiliate record. The direction of travel here is unusual and section 8.4 explains it: the affiliate grants us read access, so LinkedIn is the source rather than a recipient of onward data. We list it here anyway, because the connection is built into the product and the profile data it returns is retained by us. This is a different relationship from the LinkedIn advertising tag in 8.2 | Standard Contractual Clauses, Module Three, where data reaches LinkedIn Corporation in the USA | | Google Tag Manager, operated by Google | Ireland (Google Ireland Limited), with onward access by Google LLC in the USA | The tag container GTM-PSMWBCS, loaded in the product app in production only, including on pages your affiliates use. Version 2.0 treated the tag manager as one of our own corporate tools. We have moved it here instead, because a container can load further tags without any change to our application, and putting it in this table is what gives you notice of, and the right to object to, what it introduces | Standard Contractual Clauses, Module Three. Confirmed once the contracting entity for the container is verified |

8.1(b) Providers that process data for our own business, where we are the controller

These companies are not sub-processors of our customers' data. They process data about our own prospects, customers, staff and website visitors.

| Recipient (legal entity) | Country | What they do for us | Transfer mechanism | |---|---|---|---| | Dealfront Finland Oy, trading as Leadfeeder Finland, part of Dealfront Group GmbH (Germany) | Finland | Identifying the company behind a visit to our own web properties from its IP address | No restricted transfer at this level. Dealfront's onward chain reaches US providers under Standard Contractual Clauses | | Google Ireland Limited | Ireland | The browser Google Analytics 4 tag on the Reditus application interface (app.getreditus.live). It does not run on the marketing site, as section 5.1 states. Google Tag Manager was in this row in the first draft of version 2.1 and has been moved to 8.1(a) instead, because the container loads on pages your affiliates use and can introduce further tags without a change to our application, which is a thing you should have an objection right over rather than a thing we classify as our own housekeeping | Standard Contractual Clauses, Module Two, for onward access by Google LLC in the US. Collection happens in the EU and is then forwarded to Google servers in the US, which is not the same as EU residency | | Google Analytics 4, server-side stream, operated by Google | Ireland (Google Ireland Limited), with onward access by Google LLC in the USA | A second, server-side Google Analytics stream sent from our own backend rather than from a browser, reporting product milestones such as a customer completing the tracking script installation. It is distinct from the browser tag above and distinct again from any Google Analytics property an affiliate connects to their own account under 8.4. It was not disclosed before. | Standard Contractual Clauses, Module Two, for onward access by Google LLC in the US | | Google Cloud EMEA Limited | Ireland | Google Workspace: staff email, documents, spreadsheets, calendar | Standard Contractual Clauses, Module Two. Google LLC in the US is a listed sub-processor for data centre operations | | Google, for the Gemini language model API (contracting entity being verified: Google Ireland Limited or Google Cloud EMEA Limited, depending on which terms cover the developer API) | Ireland | The large language model that scores and explains affiliate matches, called from inside the n8n pipeline described in sections 6.1 and 7. It sees candidate profile data. Under Google's EEA terms, prompts and outputs are not used to train Google's models | Standard Contractual Clauses, Module Two, for onward access by Google LLC in the US. Confirmed once the contracting entity is verified | | Hunter Web Services, Inc., trading as Hunter | USA | Contact enrichment for the affiliate recruitment database in section 6. It processes a candidate's name, email address and LinkedIn profile, and it is the only step in that pipeline whose purpose is processing personal data. Two things worth being precise about: the call is made from inside the n8n pipeline rather than from our application, and the enriched personal data Hunter returns is written back into our own database | Standard Contractual Clauses, Module Two | | Supabase Pte. Ltd, second project | Singapore is the contracting entity; hosting region being verified, see section 9 | A second, separate database project holding the affiliate recruitment records described in section 6: publicly sourced candidate profiles, including people who never registered with Reditus. It is separate from the product database in 8.1(a) | Standard Contractual Clauses, Modules Two and Three, plus UK and Swiss addenda, under Supabase's DPA v1 of 1 August 2026 | | CORDNET OU (registry code 14748498), trading as Featurebase | Estonia is the entity of establishment; processing takes place in the Netherlands, Germany and Ireland | The chat and product feedback widget on the marketing site getreditus.live, where nobody is signed in and conversations are anonymous until you leave an email address. Version 2.0 listed Featurebase as our in-product support chat and therefore as a sub-processor of your data. That was wrong on the first point: the chat inside the product is HubSpot Conversations, in 8.1(a), which is why this entry has moved into the controller table | No restricted transfer at this level. Featurebase's own onward transfers to US providers are covered by its DPA under Standard Contractual Clauses | | POSITIVE GROUP SALES SOLUTIONS SAS, trading as NoCRM.io | France (Hem) | Our sales CRM: prospect and customer contact records and pipeline notes. Customer records are synchronised into it automatically from our application, which version 2.0 did not say | No restricted transfer at this level | | Sanity (contracting entity being verified: Sanity's own documents name both Sanity US Inc. in the USA and Sanity AS in Norway) | USA or Norway; content is stored on Google Cloud in Belgium | Content management for the marketing site, including author profiles and case study contacts | Standard Contractual Clauses, Module Two, if the verified entity is the US one; none needed if it is the Norwegian one, Norway being in the EEA | | Mintlify, Inc. | USA | Hosting for docs.getreditus.live | Standard Contractual Clauses, Module Two | | SaaSflow OU, trading as Guideflow | Estonia | Interactive product demo embeds on our marketing pages | No restricted transfer at this level | | DataForSEO OU | Estonia is the registered entity, with operations in Kharkiv, Ukraine | Two uses. Search and AI answer data behind the AI Citation Finder tool on our website, and site, company and search data inside the affiliate recruitment pipeline in section 6.1. In the recruitment pipeline it returns site and company data only, and no personal data | Standard Contractual Clauses. Ukraine has no EU adequacy decision, so the clauses are required rather than an assumption based on the Estonian registration | | Deluxe Custom Apps LLC, trading as GlockApps | USA | Receives email authentication (DMARC) reports for our domain | |

| Better Stack, Inc. | USA | Public status page at status.getreditus.live | Standard Contractual Clauses, Module Two. Better Stack's own DPA relies on the EU-US Data Privacy Framework with the Standard Contractual Clauses in its Schedule D as fallback; consistent with section 9 we treat the clauses as our primary mechanism and the Framework certification as a supporting fact only | | Sprinto (contracting entity being verified: Sprinto Inc. in the USA or Sprinto Technology Private Limited in India) | USA or India | Compliance automation and our trust centre, including the email address of anyone who requests a document there | Standard Contractual Clauses are required whichever entity it is, since neither the USA nor India has an EU adequacy decision; we are verifying the executed clauses along with the entity | | GitLab (contracting entity being verified) | Being verified | Source control and continuous integration. It holds no production personal data; the pipeline holds deployment secrets. It is named here rather than left inside the general sentence below because our DPA's own vendor annex says this notice is where it gets disclosed | Stated once the entity, plan and hosting region are verified. No production personal data is transferred to it | | Open Exchange Rates | Being verified | Currency conversion rates used to convert commission and payout amounts. No personal data is sent to it. Named here for the same reason as the row above | None required: no personal data is transferred |

Where a row above says a contracting entity is being verified, the name and country given are our best current understanding from the vendor's own published terms, not yet checked against an order form or invoice, and we say so rather than assert it.

We also use internal tools that can incidentally hold personal data, such as a password manager and a design tool. Our code repository and continuous integration provider is named in the table above rather than left in this sentence. Everyone who may access personal data on our behalf signs a non-disclosure agreement before access is granted. Our external bookkeeper receives payment and invoicing records only, not customer or affiliate personal data. We do not currently work with any marketing or other external agency; if we engage one, it will be required to sign a non-disclosure agreement before any access is granted.

8.2 Companies that act on their own account, not ours

These are not our processors. They decide their own purposes, so they answer for their own processing and you can exercise your rights directly with them as well as with us.

| Recipient (legal entity) | Country | What they do | Transfer mechanism | |---|---|---|---| | Google Ireland Limited, for Google Ads and DoubleClick | Ireland | Advertising conversion measurement in the product app | Independent controller. Controller to controller Standard Contractual Clauses where data reaches Google LLC in the US | | LinkedIn Ireland Unlimited Company | Ireland | The LinkedIn Insight Tag: advertising audiences and conversion measurement in the product app | Independent or joint controller. Controller to controller Standard Contractual Clauses where data reaches LinkedIn Corporation in the US | | Stripe Payments Europe, Limited | Ireland | Fraud detection, financial loss prevention and its own regulatory compliance | Stripe determines these purposes itself and has sole authority over them under its agreement |

We are reviewing whether advertising tags belong on pages used by affiliates at all, and they are part of what the consent gate in section 5.3 will block.

8.3 Integrations you switch on yourself

If you connect one of these, you are instructing us to send data to a service you have chosen. In that relationship the destination is your provider, not our sub-processor, and your agreement with them governs what they do with it.

| Integration | Entity | What is sent | |---|---|---| | HubSpot | HubSpot Netherlands B.V. (being verified against HubSpot's jurisdiction specific terms) | Contact and company records you choose to sync, in both directions. This is one of three HubSpot relationships; the other two, the in-product chat and our own CRM synchronisation, are ours rather than yours and are in 8.1(a) | | Slack | Slack Technologies Limited or Slack Technologies, Inc. | Programme notifications to a channel you nominate. We also run our own Slack workspace, which is in 8.1(a) | | Calendly | Calendly LLC (USA) | Meeting bookings connected to your account. Note the direction of travel as well: when you connect Calendly, our server reads the invitee's name and email address back out of the booking, as section 4 explains | | User.com | User.com sp. z o.o. (Poland, being verified) | Contact records, using an API key you paste in. We store that key, encrypted. We also run our own User.com account, which is in 8.1(a) | | Stripe | Stripe Payments Europe, Limited (Ireland) | Read access to your transaction data for commission attribution | | The Reditus API and webhooks | Wherever you point them | Whatever you request |

Entities marked "being verified" in this table are our best current understanding from the vendor's own published terms; we have not yet verified them against an order form or invoice. The same caveat applies to Google Ireland Limited and LinkedIn Ireland Unlimited Company in the tables above and below.

8.4 Connections an affiliate makes to their own accounts

This is the opposite direction from 8.3, and the difference matters. Where an affiliate authorises Reditus to read their own YouTube channel, Google Analytics property or LinkedIn profile, Reditus is the recipient of that data, not the sender. The platform acts as the affiliate's own service rather than as a destination we send data to, and the data Reditus receives is then held under the DPA as affiliate data. The affiliate can revoke the grant at any time.

One of the three is also listed as a sub-processor, and we would rather explain that than let the two tables look inconsistent. LinkedIn has a row in 8.1(a) as well as an entry here. On the reasoning in the paragraph above it arguably does not need one: the affiliate grants the read, and we are the recipient. We list it anyway, because the connection is implemented in our product, because the profile data it returns is stored against the affiliate's record in our database, and because a listing that is arguably too generous costs a merchant nothing whereas an omission costs them a gap in their own Article 28 diligence. YouTube and Google Analytics stay out of 8.1(a) because Google Ireland Limited is already named in this notice for those relationships and neither returns a stored profile of the same kind. If you would rather we applied the stricter reading to all three, say so at privacy@getreditus.live and we will.

| Connection | Entity | What Reditus receives | |---|---|---| | YouTube, connected by an affiliate | Google Ireland Limited | Read-only access to the affiliate's own channel and channel analytics | | Google Analytics 4, connected by an affiliate | Google Ireland Limited | Read-only access to the affiliate's own property | | LinkedIn, connected by an affiliate | LinkedIn Ireland Unlimited Company | Version 2.0 described this connection as in development and not live. Our code audit found the authorisation flow implemented in the product and a dedicated table in our database holding the LinkedIn profile data it returns, so we are correcting the entry rather than leaving a "not live" claim standing. What we receive is the affiliate's own LinkedIn profile data, held against their affiliate record. This is separate from the LinkedIn Insight advertising tag in 8.2, which is not a connection anyone makes and does nothing for affiliates |

Only the affiliate-side read grant is established for Google Analytics, which is why it is listed here and not among the integrations in 8.3; if a merchant-side connection ever ships, 8.3 gains a row in the same revision.

8.5 Others

We also disclose personal data where the law requires it, to our professional advisers under confidentiality, and to a buyer or successor in the event of a merger, acquisition or sale of the business. If that happens, this notice continues to apply until you are told otherwise.

8.6 Providers we no longer use

Named here because the previous version of this notice listed them and someone comparing the two deserves an explanation.

Heroku, and AWS through Heroku: replaced by Hetzner Online GmbH. Removed.
HubSpot as our only internal CRM: NoCRM is now our sales CRM. That is as far as the claim goes, and version 2.0 took it further than it should have by saying HubSpot appeared only as a customer integration. It does not. HubSpot still runs the support chat inside the product and still receives an automated synchronisation of affiliate and customer contact records from our database. Both are listed in 8.1(a). Only the sales-pipeline role moved to NoCRM.
Mandrill: not in use, despite an old email authentication record that still refers to it. That record is being removed.
Paragon: listed here in error in version 2.0. Paragon is live in the product front end, and it has been moved into 8.1(a).
AppSignal: replaced by Honeybadger for backend error tracking. Removed.
Linear: replaced by Plane for issue tracking. Removed.
Hotjar, Segment and Crisp: their tags no longer load on any page we serve, verified against every page we could crawl. A Hotjar site remains provisioned but does not load; we are confirming that all three accounts are closed and any residual data deleted, and until that is confirmed we list them here rather than claim it.

9. Where your data is

The production database holding customer data is in the European Union. The application runs on Hetzner Online GmbH in Nuremberg, Germany, and the database sits in Supabase's Frankfurt region, on PostgreSQL 17. Two corrections to what version 2.0 said in this same paragraph: authentication is not in Supabase, it runs inside our own application with password hashes stored in our own database; and file storage is not in Supabase either, uploaded files are held in Cloudflare R2.

Four honest qualifications:

1. Supabase's contracting entity is in Singapore, which has no EU adequacy decision. The data rests in the EU, but the contract is with a Singapore company, so Standard Contractual Clauses apply to that leg. We would rather explain that than let a procurement team discover it.

2. Some supporting services process data outside the EEA, specifically error tracking and session replay (Functional Software, Inc., United States region), transactional email (Twilio Inc., trading as Twilio SendGrid, United States), backend error tracking (Honeybadger Industries LLC, United States, which receives error reports only: its log-ingestion product is disabled and our application logs are not shipped to it), documentation hosting and our status page, and possibly our trust centre, whose provider's contracting entity and hosting region are still being confirmed (section 8.1(b)). Cloudflare terminates TLS at the point of presence nearest the visitor, which is not necessarily in the EU. Section 8 names each one and the mechanism that covers it.

3. Our marketing website's edge rate-limiting and lead store holds visitor email addresses and IP addresses for up to 24 hours in Cloudflare's key-value store. That store is not pinned to a jurisdiction, so those values may be replicated outside the EU. We are examining whether the namespace can be restricted to the EU, or the raw values replaced with hashes; until one of those ships, the sentence before this one is the accurate description.

4. Two stores whose region we have not yet verified, and will not assert. Version 2.0 opened this section with a flat claim that all production customer data rests in the EU. Two things sit outside what we have actually checked. Files uploaded into the product are stored in Cloudflare R2, and the second Supabase project holding the affiliate recruitment records in section 6 is a separate project from the product database. We are not going to state a region for either until we have confirmed it.

Hetzner holds an ISO/IEC 27001:2022 certificate issued by SOCOTEC Certification Deutschland GmbH, covering its hosting services and data centres in Nuremberg, Falkenstein and Helsinki. That is Hetzner's certificate for Hetzner's facilities. It is not a certificate held by Reditus, and we do not present it as one.

On international transfers generally. Where a transfer outside the EEA is needed, our primary mechanism is the Standard Contractual Clauses adopted by the European Commission on 4 June 2021, with the UK Addendum and a Swiss addendum where relevant. Where a recipient also holds a Data Privacy Framework certification we note it as supporting evidence, but we do not rely on it as our only mechanism, because that framework is under legal challenge. If it were suspended or invalidated, the clauses already in place would continue to apply.

10. Security, stated without decoration

What is true today:

Traffic to our websites and application is encrypted in transit with TLS.
Data stored in our database (Supabase, Frankfurt) and in our file storage (Cloudflare R2) is encrypted at rest by those providers.
Some fields are additionally encrypted by the application itself, on top of that platform-level encryption, so they are not readable in a database dump or by anyone with database access alone. Those fields are: affiliate IBANs, our customers' payment, product and webhook secrets, Slack access tokens, and API key tokens. We would rather name the exceptions than let the sentence imply more than it should: this is field-level encryption on those fields, not on everything, and payout email addresses and tax identifiers are stored in plain text.
Passwords are stored only as bcrypt hashes, at cost factor 11, in our own database. Authentication runs inside our own application rather than in an outsourced authentication service. Login session tokens are stored as SHA-256 hashes and are valid for two weeks.
Rate limiting is enabled in production on our API and authentication endpoints.
We use a managed hosting and database platform rather than running our own hardware, so physical security is handled by providers with certified data centres.
Everyone who may access personal data on our behalf, employee or contractor, signs a non-disclosure agreement before access is granted. Our external bookkeeper does not access customer or affiliate personal data at all: they receive payment and invoicing records only. We do not currently work with any marketing or other external agency, and a future one will be required to sign a non-disclosure agreement before any access.

You will notice this list says nothing about access reviews, multi-factor authentication or audit logging. Those controls are the subject of open questions on our own security page, and we will add them here as stated mechanisms when they are answered, not before.

What we are not going to claim:

We hold no security certification. No SOC 2 report, no ISO 27001 certificate, no published penetration test.
Encryption at rest does not mean a hosting provider or an attacker who compromises the application cannot read data. An earlier statement of ours on our help centre said otherwise. It was wrong and it has been corrected.
A previously advertised "Privacy Verified" certification has expired and was not renewed. Every claim to it is being removed from our website and help centre.

Breach notification. If a personal data breach happens and it is likely to result in a risk to people's rights, we report it to the Autoriteit Persoonsgegevens within 72 hours of becoming aware of it, as Art. 33 requires. Where the risk to you is high, we tell you directly without undue delay, as Art. 34 requires. Where the breach affects data we hold as a processor for a customer, we notify that customer without undue delay and in any event within 48 hours of becoming aware, and we follow up with a written root cause analysis within 30 days of containment. We chose 48 rather than 72 deliberately: a customer with a 72 hour duty to its own supervisory authority cannot meet it if its processor takes the full 72. Becoming aware means the point at which any member of our team has a reasonable degree of certainty that an incident has occurred, not the point at which we finish investigating it. The timings that bind us contractually are in section 6 of the DPA, and 48 hours is the figure that appears there, here and on our security page.

11. Sub-processors and how you hear about changes

Our current list of sub-processors is published at https://www.getreditus.live/sub-processors.

Before a new sub-processor starts processing customer data, we publish the change with an effective date and email the privacy or administrative contact on the customer's account, giving at least 30 days' notice. Customers can object within the window stated in the DPA, and the remedy if we cannot resolve the objection is termination of the affected service without penalty. The full mechanism, including the carve-out for urgent security changes, is in the DPA.

12. How long we keep things

For personal data we hold as a processor for a customer, the binding schedule is the retention schedule in Annex A1 of our Data Processing Agreement. Where this table and that schedule differ, the DPA schedule governs, and we will correct this table. Where the DPA schedule states no period for a category, its longstop criterion applies: no longer than is necessary, and in any event deletion or irreversible anonymisation no later than 12 months after the end of the agreement, with backups deleted no later than 12 months from the date the backup was taken.

We do not use the phrase "as long as necessary" as a retention period, because it is not one. Where we have a firm number, it is here. Where we do not, this draft says so instead of inventing one.

| Category | Period | DPA Annex A1 row | |---|---|---| | Account data after a customer stops using Reditus | Kept for the life of the account because it powers dashboards and reporting; on termination, a 60 day export window, then deletion within a 120 day longstop; earlier deletion on request. Deletion is carried out by us when you ask for it: there is no "delete my account" button in the product, for customers or for affiliates | Row 1 | | Affiliate and enrolment records | Version 2.0 said these are deleted with the programme they belong to. They are not, and we are correcting it rather than leaving a deletion promise in place that the software does not keep. There is no facility to delete an individual programme, and affiliates belong to the account rather than to a programme, so deleting one would not cascade to them in any case. What does cascade is deletion of the account, which removes the account's affiliates, enrolments and the records hanging off them, with two carve-outs we are naming rather than burying: generated reports are retained, and payout records are kept with the link to the person severed rather than deleted, because they form part of our financial records. An earlier draft of this row said "aggregated reports", which would have told you the surviving reports contain no personal data. We have not established that, so we are not saying it. If you want the affiliate data inside a specific programme removed while the account stays open, that is a request to us, and section 13 explains how to make it | Row 2 | | Click, visit and referral records | Client IP addresses are truncated at the point of collection, to /24 for IPv4 and /40 for IPv6, before the record is written. Event records are then kept for the life of the account, because they underlie referral and commission reporting, and are deleted with it | Row 3 | | Raw Stripe webhook event payloads | Deleted by a scheduled job once older than 2 days. Version 2.0 said one month, which was the intention rather than the code | Row 4 | | Other raw webhook payloads: our payment-processor webhooks and our own inbound webhook events | No automated clean-up runs for these today. They are retained until deleted with the account or by hand. We are stating the gap rather than describing the Stripe job as though it covered everything; building the equivalent clean-up is on the engineering list. This includes the legacy Paddle webhook table in the row below | Row 4 | | Legacy Paddle records, from before we migrated to Stripe | Paddle was our payment processor before Stripe. The connection is switched off, no customer uses it, and Stripe Payments Europe, Limited is our only payment processor today, so Paddle is not a sub-processor and does not appear in section 8. What does still exist is the data that era left behind: a Paddle customer table holding payer email addresses and names, and a table of Paddle webhook payloads. Neither has a clean-up job, so nothing deletes them on a schedule today. They are scheduled for deletion, and we would rather name the leftover data than let the switched-off vendor stand in for it. | Row 4 | | Conversion, subscription and commission records derived from those events | Kept for the life of the programme and account, because commissions and dashboards are calculated from them; deleted with the account. Where a commission links to a payment receipt, we store only a link into the customer's own Stripe account, shown to that customer alone; the receipt itself is never stored by Reditus | Row 4 | | Payout identifiers | Payouts run on three rails: PayPal, direct IBAN bank transfer, and Wise. The PayPal email address used for payouts and, where the affiliate is paid by bank transfer or through Wise, the IBAN are stored in the affiliate record and deleted when that record is deleted. The IBAN is encrypted at the application level; the payout email address is not. Version 2.0 also said affiliates can remove their own payout details at any time in their account. They cannot. There is no self-service deletion anywhere in the product today, for payout details, for an affiliate record or for an account, for affiliates or for customers. Deletion happens when you ask us for it and an administrator carries it out. We would rather say that plainly than leave a self-service claim standing that would send someone looking for a button that does not exist | Row 5 | | Payout transaction records | Kept until the account is deleted, which is a request to us rather than something the account holder can do from inside the product. Even then the payout record itself survives, with the link to the person removed rather than the record destroyed, because it forms part of our financial records. Records that form part of our statutory accounting are kept 7 years under Dutch law | Row 6 | | Support conversations | Two tools, not one, and version 2.0 named only the wrong one. Chat inside the product runs on HubSpot; the chat and feedback widget on our marketing site runs on Featurebase (CORDNET OU, Estonia). Conversations in both are kept for the duration of the relationship and deleted with the account or on request | Row 7 | | Session replay and error events | Replays are recorded by our error tracking provider only, with all text and media masked, and are kept for the window that provider's plan applies. Analytics and error events in our own account are kept while the account is active and deleted with it | Row 8 | | Login session records | Each holds the IP address and browser user agent for that session and is valid for two weeks. Expired records stop working at that point but are not purged by any job today: they remain in the database until the account is deleted. Purging them is on the engineering list | Follows the account data row, Row 1 | | Backups | 7 days. The database is snapshotted daily and can be rolled back to any day in the preceding 7 days, so no snapshot older than that is kept. No longer-term or off-platform archive exists | Row 9 | | Our own attribution cookie, _gr_id | 60 days by default, and configurable by the merchant between 1 and 119 days, not 1 and 120 as version 2.0 said. The expiry is a sliding window: each qualifying visit rewrites the cookie with a fresh expiry, so on a visitor who keeps clicking a merchant's links the cookie lives longer than the configured number of days. It is set only when a visitor arrives with an attribution parameter, so an ordinary visit sets nothing. See section 5.4 | Row 10 | | Our referral widget cookie, _gr_referral_widget, set only where a merchant enables the in-product referral widget. It holds the advocate's email address, first name, last name, company name, a company identifier, a product identifier and a widget authentication token, all in cleartext | 30 days | Row 10 | | Our cookie-support test cookie, _gr_cookietest, set by the referral widget rather than by the tracking script | A one-off check that cookies work in that browser. Version 2.0 attributed it to the tracking script | Row 10 | | Accounting and invoicing records | 7 years from the end of the financial year to which they relate, as Dutch tax law requires | Not in the DPA schedule: Reditus is controller | | Leadfeeder cookie, _lfa | 24 months. The previous version of this notice said "up to 14 months" for cookies generally, which understated this one by ten months | Not in the DPA schedule: Reditus is controller | | Guideflow demo cookie | Approximately 2 years | Not in the DPA schedule: Reditus is controller | | Email authentication reports held by our reporting provider | 90 days for aggregate reports, 30 days for provider XML, per that provider's own policy | Not in the DPA schedule: Reditus is controller | | Opt-out and suppression records | Kept indefinitely, because deleting them would undo the opt-out. Reduction to the email address and the date alone is tied to the suppression-list work at section 3.1, as section 6.3 states | Not in the DPA schedule: Reditus is controller | | Prospect and CRM records where no relationship starts | | Not in the DPA schedule: Reditus is controller | | Affiliate recruitment database records | | Not in the DPA schedule: Reditus is controller |

When a period ends we delete the data or irreversibly anonymise it so that it can no longer be connected to you. Backups are overwritten on their own cycle, which means deleted data can persist in a backup for a short period after it is removed from the live systems.

13. Your rights

Under the GDPR you can ask us to:

Give you a copy of the personal data we hold about you, and tell you where it came from (Art. 15).
Correct anything that is wrong or incomplete (Art. 16).
Delete it, where one of the grounds in Art. 17 applies.
Restrict what we do with it while a dispute about accuracy or legitimacy is resolved (Art. 18).
Send it elsewhere, in a structured, commonly used, machine readable format, where we hold it on the basis of your consent or a contract (Art. 20).
Object to processing based on legitimate interests, on grounds relating to your situation (Art. 21(1)). For direct marketing the objection is absolute: we must stop, with no balancing on our side (Art. 21(2)).
Withdraw consent at any time, where consent is the basis. Withdrawing does not affect anything we did before you withdrew.
Complain to a supervisory authority.

How to use them. Email privacy@getreditus.live. If you are an affiliate or a referred lead inside a merchant's programme, see section 1: the merchant is the controller, and we will route your request to them and help them answer it.

One thing to set expectations on. There is no self-service deletion in our product today. No account, affiliate record or set of payout details can be deleted by the person it belongs to from inside the application. Every deletion is performed by an administrator at Reditus after a request, which is why the route for all of them is the mailbox above, and why the response times below are the commitment that matters rather than a button in a settings page. Building the self-service route is engineering work we have not done, and we would rather say so than describe a feature you would go looking for and not find.

What happens next. We acknowledge requests within 5 working days and respond in full within one month. If a request is complex or you have sent several, we can extend by up to two further months, and we will tell you within the first month if that happens and why. We may ask you to confirm your identity first, which is a protection for you rather than an obstacle.

Complaining. In the Netherlands the supervisory authority is the Autoriteit Persoonsgegevens, Hoge Nieuwstraat 8, 2514 EL Den Haag, https://www.autoriteitpersoonsgegevens.nl. If you live or work in another EEA country, you can complain to your own national authority instead. If you are in the UK you can complain to the Information Commissioner's Office, and in Switzerland to the Federal Data Protection and Information Commissioner. You do not have to raise it with us first, although we would like the chance to fix it.

14. Contacting us about privacy, and our data protection officer

Privacy contact: privacy@getreditus.live

Response commitment: acknowledgement within 5 working days, full response within one month.

The mailbox is live and monitored. We have deliberately not printed a person's name here, because a role outlasts an individual; the commitment that binds us is the response time above.

On a data protection officer. We have not appointed one today. Whether Art. 37(1)(b) requires us to turns on whether our core activities involve regular and systematic monitoring of people on a large scale, and for a company whose core product is cross site referral tracking with a persistent identifier, that is a serious question rather than a formality. We are completing the written Art. 37 assessment now. If it concludes that an appointment is required, we will appoint, publish the name and contact details here, and notify the Autoriteit Persoonsgegevens; if it concludes otherwise, we will record the reasoning as Art. 5(2) requires and state that conclusion and its date here. Either way, this paragraph will be replaced by the outcome, and in the meantime every data protection matter goes to the privacy contact above.

Representatives. Reditus is established in the Netherlands, so no EU representative under Art. 27 is required, and we do not have one. We are assessing whether the UK GDPR requires a UK representative, which depends on the extent to which we actively target UK customers; if it does, we will appoint one and name them here.

15. What changed in this version, and why

Version 2.0 is a rewrite, not an edit. The main changes:

1. We corrected our registered address. The previous notice gave "Europalaan 100, Utrecht". Our registered address is Kapelweg 12, 3951 AC Maarn. We have added the VAT number.

2. We added a controller and processor role map (section 1). The previous notice never used either word, which left it reading as though Reditus decided everything, including what happens to our customers' affiliates. It does not.

3. We named the legitimate interest every time we rely on it, with a one line balance (section 3). Previously the term appeared several times with no interest named.

4. We split marketing into two rows. Cold outbound was previously declared under "Consent". It is not consent, and it now sits under legitimate interests with an unconditional opt-out (section 3.1).

5. We added a section for people who never signed up (section 6), covering the affiliate recruitment database, its sources, the balance, retention and a one click exit. There was no such section before.

6. We fixed the analytics picture, which was backwards. Google Analytics and Google Tag Manager run in the product app, not on the marketing website (section 5.1).

7. We disclosed session replay by Sentry in the product app, including the sampling rates and what is and is not masked (section 5.2). This was happening and was not disclosed. Version 2.0 also attributed full-session, unmasked recording to PostHog; version 2.1 corrects that, see 15.1.

8. We stopped promising a cookie preference manager that does not exist and said plainly that there is no consent banner yet (section 5.3).

9. We replaced six provider tables with one recipient table and gave a transfer mechanism for each recipient (section 8). Every recipient that was in use and named nowhere has been added, and providers we no longer use have been removed and listed as removed.

10. We removed the phrase "Encryption in transit, at rest" from 25 cells describing companies we cannot inspect, and replaced it with what is actually true: written contracts containing security commitments.

11. We withdrew the "Privacy Verified" claim, which has expired, and we now state that Reditus holds no security certification of its own (section 10).

12. We added automated decision-making and profiling (section 7), which was absent.

13. We added a privacy contact, a response commitment and our reasoning on a data protection officer (section 14).

14. We replaced "as long as necessary" with real periods where we have them, and marked the gaps where we do not (section 12).

15. We stated the breach notification figures (section 10): 72 hours to the supervisory authority, which is what Art. 33 requires of us as controller, and 48 hours to a customer where we are their processor, which is the figure that binds us under section 6 of the DPA. We added a real link to a separate cookie policy, which previously linked back to this page.

16. We disclosed the Calendly embed and the hide_gdpr_banner=1 parameter (sections 5.1 and 5.3), which suppressed a third party's consent banner on our booking pages, and we are removing it.

17. We disclosed that our script reads six other affiliate networks' referral parameters from the URL and stores the captured value in our own cookie (section 4). It was not mentioned before.

18. We split the recipient table into sub-processors and our own corporate vendors (sections 8.1(a) and 8.1(b)), so that a merchant can tell which companies its Art. 28 diligence and its objection right actually cover.

19. We corrected the direction of the affiliate OAuth connections (new section 8.4). Where an affiliate connects their own YouTube or Google Analytics account, we are the recipient of that data, not the sender. The previous draft had that backwards, and it also listed a LinkedIn connection that is still in development and not live.

20. We disclosed the contents of the referral widget cookie (section 12), which holds the advocate's name, email address and company in cleartext on the merchant's own domain for 30 days.

15.1 What version 2.1 corrects, and why there was anything to correct

Version 2.0 was published on 4 August 2026. That same day our own engineering team audited it line by line against the source code of the application, the front end and the tracking script, and this version publishes the result the following morning. The audit found roughly thirty statements the code does not support. Some of them made us look worse than we are and some made us look better; we are correcting both directions in the same revision, and we are leaving the wrong sentences visible in the text as corrections rather than quietly deleting them, because a reader comparing the two versions deserves to see which way each error ran.

Corrections in your favour, where version 2.0 described us as worse than we are:

1. PostHog is not recording your screen (section 5.2). Version 2.0 said it recorded 100% of sessions with no pages excluded and with names, email addresses and bank details unmasked. No session replay is configured for PostHog anywhere in our code. We have qualified this to the code position and left a marker on it, because PostHog can be switched to recording at the project level without our code changing, and nobody has yet read those project settings. PostHog does receive your email address, full name, plan and the account's monthly recurring revenue as analytics event data, and that is stated in the same section.

2. Sentry's replay masks all text and blocks all media (section 5.2), and it runs in the browser only, with no agent in our backend. Version 2.0 described the masking as a default left in place. It is not: it is set explicitly in our own client configuration, and it is what stops the risk that version 2.0 warned about. Section 5.2 now says so rather than leaving you to wonder whether it was an accident of the software.

3. Our tracking endpoint does have an allowlist (section 4). Version 2.0 said any field a merchant invents is passed through and stored. Our server reads eighteen named fields and discards the rest.

4. No cookie is set on an ordinary visit, and we use no localStorage or sessionStorage (sections 2 and 5.4).

5. IP addresses are truncated at the point of collection (section 2), in the code that writes the event, not by a later job.

6. Some fields are encrypted by the application itself on top of platform encryption, including affiliate IBANs and API keys (section 10). We had not mentioned it.

Corrections against us, where version 2.0 claimed more than the code delivers:

7. There is no "UID mode" in which no identifying data reaches us (section 4). What exists is the ability to send an internal identifier instead of an email address, which helps only if the Stripe, HubSpot and Calendly integrations are all disconnected, and which produces pseudonymous rather than anonymous data.

8. Supabase provides our database and nothing else (sections 8.1(a) and 9). Authentication runs in our own application; file storage is Cloudflare R2. Version 2.0 credited Supabase with all three.

9. Programme deletion does not cascade (section 12). Account deletion does, with two carve-outs.

10. There is no self-service deletion anywhere in the product (sections 12 and 13), for anyone, including the payout details version 2.0 said affiliates could remove themselves.

11. Stripe webhook payloads are deleted after 2 days, not one month, and other raw webhook payloads have no clean-up job at all (section 12).

12. Cookie facts corrected (sections 5.4 and 12): the configurable range is 1 to 119 days not 1 to 120, _gr_id expiry is a sliding window so real retention exceeds the stated period, _gr_id carries eleven fields including the merchant's own internal identifier, _gr_cookietest is set by the referral widget rather than the tracking script, and none of our three cookies currently sets Secure, HttpOnly or SameSite.

13. The AI pipeline runs in production (sections 6.1 and 7). Version 2.0 called it a pilot and said no product feature sent personal data to a language model.

14. The in-product chat is HubSpot, not Featurebase (sections 5.1, 8.1(a) and 12), and it receives every logged-in user's email address on every page. Featurebase is real and runs the chat and feedback widget on our marketing site, where nobody is signed in; it has moved from the sub-processor table to the controller table for that reason.

15. Paragon is live, not retired (sections 5.1, 8.1(a) and 8.6), and the affiliate LinkedIn connection is implemented rather than in development (section 8.4).

16. We were parsing page URLs for Google advertising parameters and had not said so (section 4).

Recipients version 2.0 did not name at all, now added: n8n, HubSpot in its two Reditus-side roles, User.com in our own account, Paragon, Hunter, the Google Gemini API, the server-side Google Analytics stream, the Google Tag Manager container, the second Supabase project holding the affiliate recruitment records, and, in our own corporate vendor table, GitLab and Open Exchange Rates. Slack, Calendly, LinkedIn and Google Tag Manager moved from our corporate vendor list into the sub-processor list, because each of them receives, or can introduce something that receives, data we hold for customers. Wise stays named, and is one of the three rails we pay affiliates on, alongside PayPal and a direct IBAN bank transfer from our own bank. Plane stays named, confirmed as the hosted cloud service in which we raise our own tickets. Paddle is not named as a recipient at all: the connection is switched off, customers no longer use it, and Stripe Payments Europe, Limited is our only payment processor. The personal data that era left in our database is described in the retention table in section 12 instead, because that, and not the vendor, is what is still live.

17. Honeybadger does less than we said (sections 8.1(a) and 9). Version 2.0 credited it with performance monitoring and application logging as well as error tracking. Its log-ingestion product is switched off, our application logs are written to standard output rather than shipped to it, and our error reports carry no user-context tagging. Less personal data leaves the EU than that version described.

18. The two lists in section 8.1 now match our published sub-processor page row for row. Version 2.1's first draft named vendors in one document and not the other, which made the sentence at the top of section 8.1 untrue. Both lists, and the page at getreditus.live/sub-processors, are now maintained from one source.

We update this notice when our practices change. Material changes are announced by email where we have your address, and on the website. Every version carries a number and an effective date, and previous versions are available on request.

*This notice is published by Reditus B.V., Kapelweg 12, 3951 AC Maarn, Netherlands. KvK 77814487. VAT NL861156420B01.*