Legal

Privacy Policy

privacy-2026-09-06-v4 Last updated: 6 September 2026 Effective from: 1 September 2026

This policy explains what personal data Rekala processes, for what purpose, on what legal basis, who else is involved, and how to exercise your rights. It is written to describe what the software actually does, not what would be convenient to say.

How Rekala uses Google (Gmail) user data. A consolidated summary for anyone reviewing our Google integration; the detail lives in sections 4, 9, 11 and 16.

What we access. Only if you connect a Google mailbox: your Google account email address, to identify the connected mailbox, and an OAuth token that authorises sending. The only Gmail scope we request is gmail.send, alongside openid and email for identification.
What we cannot access. gmail.send does not permit reading, listing, searching or modifying any message. Rekala never reads your inbox, your contacts or any other Google data.
How we use it. Solely to deliver, from your own mailbox, an email you wrote and explicitly approved inside Rekala. Every send is triggered by a person; the app never sends on its own initiative.
How we store and protect it. Tokens are stored encrypted with AES-256-GCM and are never returned through our API. If the key is missing or the data has been tampered with, the mailbox is treated as unusable rather than proceeding unencrypted.
How we share it. We do not sell or share your Google data. Google itself is the provider that delivers the message; no other party receives it.
Retention and deletion. When you disconnect the mailbox, Rekala erases the stored tokens (access and refresh) and, for Google, additionally calls Google's token-revocation endpoint to invalidate the grant on Google's side. You may also revoke access at any time from your Google Account security settings.
Limited Use. Rekala's use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements.

Who the controller is, and how to reach us
Two distinct relationships: when we are a controller, when a processor
If you received an email sent with Rekala
Data we process as a controller
Data we process as a processor
Where prospect data comes from
Purposes and legal bases
Exactly what is sent to the AI model — and what is not
Sub-processors and international transfers
Retention, backups and deletion
Security
Your rights, and how to actually exercise them
Automated decision-making and profiling
No cookies: local storage in your browser
Third-party resources on this site: none
What we do not do
Changes to this policy

1. Who the controller is, and how to reach us

The Rekala service (the application at app.rekala.io and the website at rekala.io) is provided by Rekala Labs SpA, a sociedad por acciones incorporated under the laws of Chile, registered office at Moneda 812, office 601, Santiago, Región Metropolitana, Chile, Chilean tax ID (RUT) 78.500.869-3. Referred to below as "Rekala" or "we".

For any data-protection matter, including exercising your rights: privacy@rekala.io.

Data Protection Officer: not applicable. EU representative under Article 27 GDPR: not applicable.

You may lodge a complaint with the competent supervisory authority: the Chilean Data Protection Agency (Agencia de Protección de Datos Personales).

2. Two distinct relationships: when we are a controller, when a processor

This is the most important distinction in the document, and it decides who you should contact.

(a) Rekala as a controller

For our own users and visitors to rekala.io, we decide why and how the data is processed. That covers your account, your session, billing and web-server logs.

(b) Rekala as a processor

For the prospect data a customer uploads into their workspace, the controller is the customer, not Rekala. The customer decides who to contact, why, and on what legal basis; we store and process that data only on their documented instructions, never on our own initiative, and never share it between workspaces.

This allocation is not a statement of intent — it is wired into the product. Every customer accepts a versioned Data Processing Agreement (DPA), and every assertion they make — the legal basis for an import, launching a campaign, accepting the DPA — is recorded immutably together with the exact version of the text they accepted.

3. If you received an email sent with Rekala

If you are here because someone wrote to you using Rekala: the controller for that email is the company that wrote to you, not Rekala. They chose to contact you, they decided on what legal basis, and they hold your data in their workspace. We act on their instruction.

The fastest and most effective route is to reply to that email and ask them to stop writing or to delete your data. Once the company records your objection, your address is blocked immediately and permanently across their whole workspace: it cannot be enrolled in a campaign, no email can be generated for it, and nothing can be sent to it. That block never expires and survives even the deletion of your contact record — precisely so that nobody can re-contact you by mistake later on.

If you get no reply, or you don't know who wrote to you, contact us at privacy@rekala.io: we will identify the responsible customer and pass your request on. We cannot decide on their behalf about data they control, but we are obliged to assist them — and we do — so that they can answer you.

4. Data we process as a controller

About the people who use the application:

Account: email address, first and last name, role within the workspace, whether the account is active, and the sign-up date. The password itself is not stored: only a bcrypt hash, from which it cannot be recovered.
Session: a session identifier and its expiry. The identifier is not stored in the clear either — only its SHA-256 hash lives in the database.
Sender profile: the name, role, company, signature, tone and language you want the drafting to use.
Interface preferences (interface language, layout of some panels).
Connected mailbox (only if you connect one): the verified mailbox address and the tokens that authorise sending. Tokens are stored encrypted with AES-256-GCM.
Activity records: DPA acceptances, legal-basis assertions, material changes, and administrator impersonation of an account, recording who acted.
Feedback you submit through the in-app feedback form.

About visitors to rekala.io: The web server keeps no access logs; only operational errors go to the system journal, which rotates automatically. The site contains no JavaScript, no analytics and no cookies.

5. Data we process as a processor

This is the data a customer enters about the people and companies they want to reach. We list it precisely, because it is exactly what a controller needs in order to meet their own transparency obligation:

About the contact person

First and last name.
Email address (the only mandatory field).
Company and job title.
Phone number.
LinkedIn profile.
Country.
Notes and tags written by the customer, plus research notes attached to the contact.
The declared source of the contact and the legal basis the customer has asserted.

About the relationship with that person

The full text of the generated emails (subject and body of up to three emails per sequence), their edited versions, and when they were marked as sent.
The verbatim text of replies that the customer pastes into the application when a prospect writes back. This can contain anything that person wrote, and it is kept as-is.
The conversation between the customer and the assistant about those emails: instructions, corrections and rules.
Send events and status within the campaign.
Whether the address is on the suppression list, and why.

About the prospect's company

Name, industry, size, country, website and notes.
The information extracted automatically from that company's public website.

6. Where prospect data comes from

From two places, and only two:

The customer provides it: by importing a CSV file or adding the contact by hand. In doing so they must declare the legal basis on which they hold it, and that declaration is recorded.
Automated research of the company website. Our server makes a request to the prospect's company's public website and extracts information about the company. This research is strictly company-level: we never research individuals.

When that read finds email addresses published on the page, two filters apply by design and are not configurable:

Generic inboxes only. Addresses such as info@, contact@, kontakt@, sales@ and similar are accepted. An identifiable person's address — of the firstname.lastname@ shape — is always discarded. We never harvest an individual's address.
Same domain only. Only an address on the same domain as the page being read is accepted, never a third party's that happens to appear on it — an agency in the footer, a vendor, a partner.

Nor is an address "derived" that was not literally written on the page.

7. Purposes and legal bases

Processing	Purpose	Legal basis
Account and access	Create the account, authenticate, maintain the session, provide support	Performance of the service contract (Art. 6(1)(b) GDPR)
Billing	Charge for the service and meet accounting obligations	Performance of contract and legal obligation (Art. 6(1)(b) and (c))
Service security	Prevent unauthorised access, limit abuse, diagnose faults	Legitimate interest in securing the service (Art. 6(1)(f))
Prospect data	Store it, draft the emails, and — if the customer enables it — send them from their mailbox	Determined by the customer as controller; we process on their instruction (Art. 28 GDPR). The bases a customer can declare in the product are: existing relationship, consent, legitimate interest in B2B prospecting, or another documented basis.
Compliance records	Preserve the evidence of what the customer declared, and when	Legal obligation and legitimate interest in being able to demonstrate compliance (Art. 6(1)(c) and (f))

Rekala does not use a customer's prospect data for any purpose of its own, nor to improve the service for other customers. Product learning is isolated per workspace: nothing that happens in one customer's workspace influences another's.

8. Exactly what is sent to the AI model — and what is not

To draft an email, the contents of the prompt are sent to Anthropic PBC. We are specific about what that contains, because it is the question every systems administrator asks, and because it is checkable.

What is not sent

The contact block of the prompt contains only the prospect's name, company, job title and country. The recipient's email address is never sent to the model. Neither is their phone number or LinkedIn profile. The address is used solely to deliver the message, at the moment of sending, and that send does not go through the model.

This is not a statement of intent: the eight prompts the system assembles are frozen byte-for-byte in an automated test that runs against every change, and they contain no email address, no phone number and no reference to LinkedIn.

What is sent

The prospect's identity: name, company, job title and country.
Any research notes the user has written.
The intelligence extracted from the company's public website.
The text of replies the user has pasted, when drafting a follow-up that must respond to what the prospect said.
The seller's material: pitch, selling points, company knowledge and uploaded documents. When a PDF cannot be extracted locally, the file is sent base64-encoded so the model can read it.

There is an important practical consequence, and it deserves saying plainly: if a user types personal data into the notes, or uploads a document containing it, that data will reach the model. Control over that sits with whoever writes it.

Anthropic processes this data as a sub-processor, under contract, solely to return the response. Under Anthropic’s commercial terms, data sent through its API is not used to train its models.

9. Sub-processors and international transfers

The list is deliberately short, and it is closed. Each party is involved only in the part of the service that concerns it, under a written contract with data-protection obligations equivalent to our own.

List current as of 1 September 2026.
Sub-processor	Role	Location	Transfer mechanism
Hetzner Online GmbH	Hosting and infrastructure: runs the application and stores the database	Germany (EU/EEA)	None needed: the data stays in the EEA
Anthropic PBC	Large-language-model processing: drafts the email from the material described in section 8	United States	EU Standard Contractual Clauses, with a transfer impact assessment
Google	OAuth and the Gmail API: delivers the message from the user's own mailbox, only if they connect their account	Google LLC (United States)	Standard Contractual Clauses incorporated in the provider’s data-processing terms; the provider is additionally certified under the EU-U.S. Data Privacy Framework
Microsoft	Microsoft Graph: an alternative sending route from the user's own mailbox. Built, and involved only if the user connects a Microsoft account	Microsoft Corporation (United States)	Standard Contractual Clauses incorporated in the provider’s data-processing terms; the provider is additionally certified under the EU-U.S. Data Privacy Framework
Bright Data	Web-page rendering for company research. Currently inert: no key is configured, the function does not run, and it processes no data	—	Not applicable while it remains inactive. If it is ever activated, it will appear here with its location and mechanism before it begins processing

About your own email provider

When a user connects their Gmail or Microsoft mailbox, the message is delivered through that provider's API with the permission the user themselves granted, and it goes out from their account. That provider is already the customer's email provider independently of Rekala. The permission can be revoked at any time from the security settings of the Google or Microsoft account, or by disconnecting the mailbox inside Rekala.

Prospects' websites

During research, our server makes an HTTP request to the prospect company's public website. As with any visit, that site receives the IP address of our server — not that of any user or any prospect. It is not a sub-processor, but we declare it because it is a flow of data to a third party.

Changes to the list

Before adding or replacing a sub-processor that will process customer data, we announce it at least 30 days in advance, by updating this page and notifying inside the application. A customer with a reasonable, data-protection-grounded objection may raise it within that period.

10. Retention, backups and deletion

We would rather be exact, limitations included.

Prospect data: kept for as long as the customer keeps it in their workspace. Rekala does not delete data on a timer. The product flags for review contacts with no exchange in about 36 months, but it only surfaces them: the decision to keep or delete is always the customer's. There is no automatic deletion by elapsed time.
Suppression list: kept indefinitely, by design. A refusal to be contacted does not expire. When a contact is deleted at their request, the suppression entry is created first, and the cleartext address is then nulled, leaving only an irreversible hash that keeps blocking any re-contact.
Compliance records (DPA acceptances, legal-basis assertions): append-only, kept as evidence, without any email content.
User account: for as long as the account is active, and for 30 days afterwards.
Backups: a full copy of the database is taken once a day and the seven most recent are kept; older ones are deleted automatically. Data deleted from the live system may therefore still be present in a backup for up to roughly seven days, until that copy rotates out.
Known limitation: expired session rows are not purged automatically. An expired session cannot be used to log in — it is rejected — but its record remains in the database until the user logs out or an administrator revokes it.

11. Security

Passwords are stored with bcrypt; never in the clear and never recoverable.
Session identifiers are stored as SHA-256 hashes. Anyone obtaining a copy of the database would get hashes, not replayable credentials.
Mailbox OAuth tokens are encrypted with AES-256-GCM. The system fails closed: if the key is missing or the data has been tampered with, the mailbox is treated as unusable rather than proceeding unencrypted.
File preview and download links use single-use tokens, bound to the file and the workspace, valid for roughly two minutes, so the session credential never travels inside a URL.
Strict per-workspace isolation, including product learning: no data and no pattern crosses from one customer to another.
Three levels of access control: authenticated user, workspace administrator, and platform administrator. Destructive operations and sensitive configuration are administrator-only.
When a platform administrator acts by impersonating another account, who did so is recorded.
Every database query passes through a global guard that rejects non-scalar values, preventing a request value from being stored with an unexpected type.
HTTP security headers, an allowlist of permitted origins, request rate limits, and a guard against requests to internal networks in the functions that read external websites.

No measure removes risk entirely. If you find a security problem, write to security@rekala.io.

12. Your rights, and how to actually exercise them

If the GDPR or an equivalent law applies to you, you have the right to access your data, rectify it, erase it, restrict or object to its processing, and to data portability. You may also withdraw consent where processing rests on it, and lodge a complaint with a supervisory authority.

If you are a Rekala user

Write to privacy@rekala.io. We are the controller and we answer directly.

If you are a prospect

The controller is the Rekala customer who contacted you, and the decision is theirs. We explain this in section 3. Our obligation — which we meet — is to assist them so they can answer you, and for that the product has real tooling:

Access export: a workspace administrator can generate a bundle of everything the platform holds about a contact: identity, declared source and legal basis, notes, every campaign they appear in, the full text of the emails, send events, the assistant conversation about those emails, and their suppression status.
Erasure: an administrator can delete the contact. The operation first creates the permanent block entry, then cascades the deletion of the record, its campaign memberships, the emails, the edits and the associated conversation. The audit log records counts only, never content.

Limitations we would rather declare. Today neither function has a button in the interface: they are administrator operations, run by our team or by the customer's administrator through the API, by deliberate decision — erasure is irreversible and we did not want to expose it as a button. This does not reduce the right or the response deadline; it only describes how it is served. There is also no whole-workspace export or deletion in a single step yet.

We will handle or pass on every request within the applicable legal deadline, free of charge, unless it is manifestly unfounded or excessive.

13. Automated decision-making and profiling

Rekala does not take decisions based solely on automated processing that produce legal effects on a person or similarly significantly affect them. The system drafts text and classifies commercial material; the decision of who to write to, and of whether an email goes out, is always a person's, and the product requires that human approval.

14. No cookies: local storage in your browser

The application does not use cookies. Authentication uses a token sent in the header of each request, which the browser keeps in localStorage. Some interface preferences are kept in the same storage. This data stays on your device, is not sent automatically with every request the way a cookie would be, and you can clear it by clearing the site's data in your browser — which will log you out.

The rekala.io website has no JavaScript, no analytics and no cookies, which is why it shows no cookie banner: there is nothing to consent to.

15. Third-party resources on this site: none

When you open any page on rekala.io, your browser talks only to rekala.io. Nothing is loaded from a third-party server: no fonts, no images, no scripts, no icons. The typefaces are served from our own server along with the rest of the site.

We say so because until 25 August 2026 that was not the case: the typefaces were loaded from fonts.googleapis.com and fonts.gstatic.com, so Google received every visitor's IP address purely to deliver a font. That dependency has been removed.

16. What we do not do

Each of these statements was checked against the deployed code by looking for the feature and confirming it does not exist:

We do not sell or share personal data with anyone, and we do not trade it for advertising purposes.
We do not insert tracking pixels into emails.
We do not track opens.
We do not rewrite links in emails, and we do not track clicks.
We do not add blind copies (BCC) or copies (CC) to any send.
We do not read your Gmail inbox. The only permission the application requests from Google is gmail.send, plus the basic identification needed to know which address is sending. That scope makes reading mail technically impossible. An honest caveat: the alternative Microsoft route, which is built, does request Mail.ReadWrite, because threaded sending with Graph requires creating a draft before sending it. That permission is used for nothing else.
Our use of Google user data is limited. Rekala’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements.
We use no third-party analytics, neither in the application nor on the website.
The website loads no third-party resources at all. Your browser talks only to rekala.io.
We do not research individuals. Automated research is always company-level.
We do not harvest individuals' addresses from web pages: only generic inboxes on the same domain.
We do not mix data between customers. Neither the data nor the learning leaves the workspace in which it was created.
We never send anything on our own initiative. Automatic sending is built but inert: it ships disabled, it requires the owner to arm the transport, the customer to accept the DPA and pass a test send — and even then, every email is approved by a person.

17. Changes to this policy

If we change this policy, we will update the date and version identifier shown at the top. Material changes affecting customers will also be communicated inside the application. The version in force is always the one published at this address.

Document privacy-2026-09-06-v4 · 6 September 2026 · Terms of Service · Home