Last updated: August 2026
Cadivra Limited, registered in England and Wales (17130844). Contact: [email protected]. We are the data controller for the personal data described in this policy.
Data protection contact: [email protected]
This Privacy Policy explains how we collect, use, store, and share personal data when you visit our website, create an account, use our Platform, or contact us. This covers data we process about you (our customers and website visitors) as a data controller.
When you upload contact data to Cadivra for email campaigns, or when you connect a mailbox and we retrieve replies from it on your instruction, we process that data on your behalf as a data processor under our Data Processing Addendum (DPA). Your rights and our obligations in respect of that data are governed by the DPA rather than this Privacy Policy. Sections 7 and 9 below describe the security and retention measures we apply across the Platform, including to that data, so that you can rely on them in either role.
This policy is intended to comply with the UK GDPR and the Data Protection Act 2018. Where our services are used by customers in the European Economic Area (EEA), we also aim to comply with the EU General Data Protection Regulation (EU GDPR).
Where we rely on legitimate interest as a lawful basis, we have conducted a legitimate interest assessment and concluded that our interests do not override your rights and freedoms. You may object to processing based on legitimate interest at any time by contacting us.
For marketing emails about Cadivra's own products sent to existing business customers, we rely on the "soft opt-in" under Regulation 22 of PECR. You can opt out at any time via the unsubscribe link in each email.
We share personal data only with the following categories of recipients, and only to the extent necessary for the purposes described:
We do not sell your personal data to any third party.
If you choose to connect a Google (Gmail / Google Workspace) or Microsoft mailbox to Cadivra, we request the minimum permissions needed to provide the service:
We access only what is needed for these features, and section 7 explains the measures that protect this data. The access and refresh tokens for your mailbox are encrypted at rest. You can disconnect your mailbox at any time from Settings. Disconnecting deletes the credentials we hold for that mailbox and stops Cadivra reading it or sending from it. Because the permission itself is held by your Google Account, you can also remove Cadivra's access directly at myaccount.google.com/permissions, and we recommend you do so if you want the grant withdrawn at Google as well. Section 9 explains how to remove reply content we had already stored. We do not use data obtained from your connected mailbox for advertising, and we do not sell it. Cadivra personnel do not read the content of your messages. The only exceptions are those permitted by the Google API Services User Data Policy: with your explicit permission, where you have asked us to look at a particular message in order to support you; where it is necessary for security purposes, including investigating abuse of the service; or where we are required to do so by applicable law.
Where you use AI features, the content of replies to your outreach may be processed by Anthropic (as our sub-processor) to classify the reply and assist your follow-up. Anthropic does not use this data to train its models, and we do not use data obtained through Google Workspace APIs to develop, improve or train generalised artificial intelligence or machine learning models.
Cadivra's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
We take reasonable and appropriate steps to protect the data we hold against unauthorised or unlawful access, use, destruction, loss, alteration or disclosure. The most sensitive category of data we handle is Google user data: the content, headers and metadata of messages in a connected Gmail or Google Workspace mailbox, and the ability to send email from that mailbox. This section describes the measures that protect it. Section 6 sets out what we access, why, and the Limited Use commitments that govern how it may be used. We use Google user data only in the ways this policy describes.
Sections 7 and 9 describe our security and retention practices across the whole Platform. They do not change who is responsible for what. Where the data is about you, our customer, Cadivra is the controller and this policy governs it. Where the data is about your contacts, or is content we retrieve from your connected mailbox on your instruction, you are the controller and Cadivra is your processor, handling that data only on your instructions and under our Data Processing Addendum. We describe our measures here so that you can rely on them in both roles.
Traffic between your browser and the Platform is encrypted in transit using HTTPS, with TLS terminated at our content delivery provider's network edge.
Every call we make to a provider API is made over HTTPS. That includes the Gmail API and Google's token endpoints, the Microsoft Graph API, and the other providers listed in section 5. We do not integrate with provider APIs over unencrypted connections.
Two qualifications, which we would rather state than leave you to discover. Where you connect a mailbox using your own mail server details instead of Google or Microsoft, we default to an encrypted connection (implicit TLS, or STARTTLS where your server offers it) and fall back to an unencrypted one only if you configure your own mail server that way. And when we research a company for you, we fetch that company's public website: we try HTTPS first and use plain HTTP only where the site offers nothing else.
The credentials that give access to your connected accounts are the most dangerous data we hold, so they are encrypted at rest with authenticated symmetric encryption (AES-128 in CBC mode, with HMAC-SHA256 authentication) before being written to our database. This covers:
The Platform will not start in production if the encryption key is missing or invalid, and is designed so that it cannot fall back to storing these credentials unprotected.
Account passwords are never stored in a form we can read. They are hashed with bcrypt using a unique salt for each password. Password reset links and email verification links are stored only as a one-way hash, so that a copy of our database is not sufficient on its own to take over an account. Programmatic access keys are generated from a cryptographically secure random source, stored only as a one-way hash, and shown to you once.
Other data we hold, including your contact records, the outreach we generate for you and the reply content described in section 7.4, sits in our production database. Cadivra does not apply a further layer of encryption to it field by field. It is protected instead by the access controls in section 7.3, by the limits on human access in section 7.5, and by the bounds on what we store at all in section 7.4. We describe the position this way, rather than implying that we encrypt message content field by field, because we do not.
Every request that reaches your data must carry a credential: either a signed access token, which expires 60 minutes after it is issued, or a workspace access key, described below. A small number of endpoints are deliberately open because they have to be, such as the unsubscribe page a recipient clicks, our contact-import template and our service health check; none of them exposes your data. Changing your password invalidates every access token and refresh token issued before the change, across every device.
Each workspace is isolated. The workspace a request belongs to is determined on our servers from your confirmed membership records, never from anything the browser sends, and every query for contacts, outreach, replies and reporting is filtered by it. Where one record refers to another, the second record is checked against your workspace again rather than trusted. If your access to a workspace is paused or removed, requests are rejected at the point of authentication, before any handler runs, and a disabled account cannot authenticate at all.
Privileged actions within a workspace, including billing, access keys, outbound notifications, sending schedules, suppression imports and viewing the workspace audit record, require an owner or administrator role, resolved from your membership record at the time of the request.
Programmatic access keys are limited to a read, write or administrator scope; are tied to the single workspace they were issued for; are rejected once revoked, and once their owner's membership of that workspace is removed or paused; are rate limited; and cannot be used to create or manage other keys.
Two-factor authentication using a time-based one-time code is available on every account, and workspace owners on our higher plans can require it for everyone in the workspace. Authentication endpoints are rate limited by both source address and target account, so guessing attacks are slowed whether they come from one address or many. Sign-in responses are deliberately timed so as not to reveal whether an email address has an account.
Development, staging and production run as separate environments with separate databases, separate application secrets and separate Google and Microsoft application registrations. The keys that protect customer data, meaning the token-signing secret and the encryption key, are generated independently for each environment, so a problem in a test environment cannot reach production data. Production data is never copied into a test environment; the only tool that populates a non-production environment generates entirely fictional data, refuses to run against production, and cannot trigger real sending.
Responses from our application servers carry security headers, including X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy, and a Content Security Policy is applied to the pages we render.
We ask Google for two mailbox permissions and no others: permission to send email (gmail.send) and read-only access to email (gmail.readonly). We do not request permission to modify or delete your mail, and we do not request access to Drive, Calendar or Contacts.
Read-only access supports one feature, and it is not a mailbox-wide read. We use it to detect replies and delivery failures to the outreach you sent through Cadivra, so that we can show you the reply, stop the sequence when someone replies, keep your reporting accurate and, where you use AI features, classify what the reply means so we can suggest the right follow-up. Section 7.8 explains where that classification happens.
When Cadivra checks for replies and delivery failures, it searches only for messages from the specific people you have emailed through Cadivra, and for recent messages that look like an automated delivery notice: sent from an address such as postmaster or mailer-daemon, or carrying a subject line such as "Undeliverable" or "Delivery Status". Each search returns a small, capped number of the most recent matching messages. For a possible delivery notice we look only at the subject, the sender and the short preview Google returns, so that we can tell a genuine bounce from an ordinary email, and we discard anything that is not one.
We minimise how much of a message we look at. While deciding whether a message is a reply to your outreach, we request only a short list of headers (such as Subject, From, In-Reply-To and References) rather than the message itself. The body of a message is only ever retrieved once that message has already been matched to an email you sent through Cadivra. What we then store is bounded: a preview of no more than 500 characters and, where we store the text of the reply, no more than the first 20,000 characters.
We do not read, index, copy or store anything else in your mailbox. Our access to the Gmail API is confined to these two functions, sending the email you have approved and detecting replies and delivery failures, and we maintain it that way as the Platform changes.
Cadivra is a small, UK-based company. We do not operate an outsourced support or operations function, and no third-party administrator holds standing access to our production systems. Access to production infrastructure and to the production database is held by a named, minimal set of Cadivra's own technical personnel who need it in order to run the service, and each of them is bound by a signed confidentiality obligation.
The staff view of an account cannot show us your outreach. It shows account and billing information: name, email address, plan, credit balance, campaign names, statuses, counts and credit history. It does not expose the body of any email you have written or sent, your contact lists, or the content of any reply we have stored. Where you send us written feedback on a generated draft, we do read that feedback, and we review it across accounts, in order to improve the product.
Consistent with the Limited Use commitments in section 6, Cadivra personnel do not read the content of your Gmail messages. The only exceptions are those permitted by the Google API Services User Data Policy: with your explicit permission, where you have asked us to look at a particular message in order to support you; where it is necessary for security purposes, including investigating abuse of the service; or where we are required to do so by applicable law.
Our diagnostics are configured with the same aim. Error reports deliberately exclude request bodies, headers and query strings, precisely so that contact data and message content are not captured in them; we record only the path, the method and the account involved. When a mailbox connection fails, we record only the error code the provider returned and never the provider's raw response, so that an access token does not end up in a log.
Every change to the Platform is put through automated checks before release. Those checks include static analysis for bug classes in our application code, a guard that blocks unsafe or conflicting database migrations, secret scanning that fails the build if a credential is committed, and browser-level end-to-end tests run against a real database. Static code analysis runs across both the server and browser code. A failing check is fixed before the change is released. An extensive automated test suite of over 1,300 tests is maintained alongside the code.
No credential is stored in our source code. Every secret is supplied to the running service by our hosting platform as an environment variable, and only placeholder example files are kept in the repository.
Database schema changes are applied only by versioned, ordered migrations run as part of a deployment, never by ad-hoc changes to the production database. A release to production requires an explicit human approval step before it goes live.
The application runs as an unprivileged system user inside its container, and the application code is not writable by the process that runs it, which is intended to prevent a compromised process from modifying the code it runs. Where you supply a web address for us to send notifications to, we require HTTPS and we resolve and reject private, loopback, link-local and cloud-metadata addresses, so that the address you give us has to be a genuine external endpoint.
We keep two audit records. The first records every authenticated request made using a programmatic access key, including the workspace, the person the key belongs to, the method, the path, the response status, the duration, the source address and the client, with any key material removed from the recorded path. Workspace owners and administrators can read their own workspace's record. The second records every action Cadivra staff take on an account, such as changing a plan, adjusting credits, resetting two-factor authentication or deleting an account, and captures both the staff member and the account concerned.
We do not alter these records in the ordinary course, because their value is that they are a faithful account of what happened. We keep each for as long as it is needed for accountability, for investigating abuse of the service and for defending legal claims, relying on our legitimate interests in each of those purposes. Where you exercise a right that would otherwise require us to change one of these records, we will restrict its use rather than rewrite it, and we will tell you what we have done.
The background jobs that detect replies and delivery failures report their own health, including when they last ran and whether a run is overdue, and that status is visible to you inside the Platform as well as to us, so a silent failure does not go unnoticed.
We maintain a documented operational playbook covering our known failure scenarios, including abuse of the service and the handling of data protection requests, with named escalation contacts and an emergency procedure for rolling a release back. Where a security incident affects personal data, we will investigate it and contain it. Where the incident affects personal data for which Cadivra is the controller, and where the UK GDPR requires it, we will report it to the Information Commissioner's Office without undue delay and, where feasible, within 72 hours of becoming aware of it. Where the incident affects data we process on your behalf, the decision whether to notify the Information Commissioner's Office is yours: our obligation is to notify you promptly, without undue delay and in any event within 48 hours of becoming aware of it, with enough information for you to make that decision. Our full obligations to you as a processor are set out in our Data Processing Addendum.
The service providers we use are listed in section 5, and the sub-processors that handle customer data are listed on our Sub-Processors page. Each is engaged under a written contract imposing data protection obligations equivalent to those in our Data Processing Addendum, including confidentiality and appropriate security measures. As set out in that Addendum, we remain liable to you for each sub-processor's performance of those obligations, subject to the limits in our Terms of Service. We give at least 14 days' advance notice before a new sub-processor begins handling customer data, and you may object as described in the Addendum.
Content originating from your connected mailbox reaches a third party in only these ways:
The last two happen only because you switched them on, and they send the content to a destination you chose. You can disconnect either at any time. The content delivery and DNS provider named in section 5 sits in front of the Platform, so your data passes through its network in transit; it is not stored there for our purposes. No other provider receives the content of your messages, and none receives it for their own purposes.
We do not sell Google user data or any other personal data. We do not provide it to data brokers, information resellers or advertising platforms. We do not use it for credit assessment, lending or advertising of any kind. We do not use data obtained through Google Workspace APIs to develop, improve or train generalised artificial intelligence or machine learning models, as stated in section 6.
No system can be made perfectly secure, and we would rather tell you what we actually do than describe controls we do not have. We hold no ISO 27001 or SOC 2 certification and make no claim to one. What we commit to is maintaining measures appropriate to the sensitivity of the data we hold, reviewing them as the Platform changes, and telling you promptly if something goes wrong.
If you believe you have found a security vulnerability in Cadivra, please report it to [email protected] and we will respond.
Our Platform is hosted within the European Union. Some of our service providers process data in the United States (including Stripe, Anthropic, Resend, Cloudflare, Vercel and Google). Where personal data is transferred outside the UK or EEA to a country not covered by an adequacy decision, we ensure appropriate safeguards are in place, including:
as applicable. Where relevant, we also rely on the EU-US Data Privacy Framework for transfers to certified US organisations. Copies of the applicable transfer mechanisms are available upon request.
The periods below apply while your account is open. If you delete your account, section 9.3 applies instead and these periods stop, except where we are required by law to keep a record.
You are the controller of the data in this subsection and you decide how long it is kept. Our retention obligations to you as your processor are set out in our Data Processing Addendum.
We do not delete this data on a fixed timetable, and we do not want to imply otherwise. Your contact records, the outreach we generate for you, and the reply content we store in order to detect replies and keep your reporting accurate are kept for as long as you keep them in your account. You decide when they go, and you can remove them at any time:
You can export your data yourself at any time from Settings, under Privacy. The export is a structured, machine-readable file covering the personal records we hold across your account, your workspace, your outreach and your contact data. The audit records described in section 7.7 are not included: email [email protected] if you want a copy of the audit records that relate to you and we will provide them separately.
You can also delete your account yourself from Settings. Deleting an account requires your current password and a typed confirmation. It runs immediately and we cannot reinstate what it removes: there is no recovery period. It removes your records across the Platform, including your contacts, your outreach, your email activity, any stored reply content from your mailbox, your credit and billing history, and your suppression list, and it cancels any live subscription. If you need to keep a record of contacts who asked not to be emailed, export it before you delete the account, because the suppression list goes with it. One precondition applies: if you are the only owner of a workspace that still has other active members, you will need to transfer ownership or remove those members first, so that a shared workspace is not orphaned.
Deletion removes your data from our live systems at once. Any copy of that data in our hosting provider's routine database backups is not individually editable; it is overwritten on that provider's rotation cycle, and it is restored only to recover the service as a whole after a failure, never to reinstate an individual account.
If you would rather we did it, email [email protected] and we will action a deletion request within 30 days. Where deletion follows the end of your subscription, section 10 of our Data Processing Addendum sets out the export window that runs first.
Two things survive account deletion by design, and only these. Billing and tax records are retained for the period in section 9.1, because UK law requires it; they contain no message content and no contact data from your mailbox. And our internal audit record of actions Cadivra staff have taken on accounts retains the email address of the account that was acted on, so that we can always show what was done and by whom; it contains no contact data and no message content.
If you are not a Cadivra customer and you believe your details are held in a customer's account, write to [email protected]. We are the processor for that data rather than the controller, so we will pass your request to the customer responsible for it without undue delay and tell you that we have done so.
Under UK GDPR (and, where applicable, EU GDPR), you have the following rights:
To exercise any of these rights, email us at [email protected]. We will respond within one month.
If you are not satisfied with how we handle your data, you have the right to lodge a complaint with the Information Commissioner's Office (ICO) at ico.org.uk. If you are based in the EEA, you may also complain to your local supervisory authority.
We use cookies and similar technologies on our website. For full details, including the specific cookies we use and how to manage your preferences, see our Cookie Policy.
When you use the Platform to send outreach emails, the Platform may include tracking technologies (such as tracking pixels) in those emails to measure open and click rates. This tracking is performed on your behalf as part of the service. You are the data controller for this processing and are responsible for ensuring your use of tracking complies with applicable laws, including PECR and the EU ePrivacy Directive. We provide the tools; compliance with recipient-facing obligations is your responsibility.
The Platform is not directed at individuals under 18 years of age. We do not knowingly collect personal data from children.
We may update this Privacy Policy from time to time. We will notify you of material changes by email or via a prominent notice within the Platform. The date at the top of this policy indicates when it was last updated. If we materially change how we access or use Google user data, we will notify you before the change takes effect.
Cadivra Limited. Email: [email protected]