Sub-processors
The short version
- This is the complete list. If a company isn't here, it doesn't get your data.
- Most rows only apply if you opt into the thing they power — subscribe, use Google sign-in, ask for an email sign-in code, or turn managed AI on.
- We announce additions 30 days before they take effect, and you can object (DPA §5).
1. Current sub-processors
| Provider | What it does | Data it receives | Location | Transfer mechanism |
|---|---|---|---|---|
| Armitage Labs OÜ (trading as Creem) only if you subscribe |
Checkout, subscription billing, invoices, the billing portal. Acts as merchant of record where applicable. | Your name and email, billing country, payment details (given to them directly — never through us), subscription state | Estonia (EU) — registered at Rotermanni 14, Tallinn 10111, registry code 16977866. | None needed for the EEA leg — they are established in Estonia. Their published Data Processing Agreement and Standard Contractual Clauses cover anything they route onward. |
| Google only if you use "Sign in with Google" |
Verifies the sign-in and confirms you own the email address | The sign-in exchange: your Google account identifier and verified email | Ireland (EU) / United States | Google's EU controller entity + SCCs and EU–US Data Privacy Framework certification |
| OpenRouter, Inc. only if you turn managed AI on |
The AI gateway our relay calls. Routes each request to one of the model providers that serve the model we have selected. They state they do not use inputs or outputs for model training, and that they do not persist image, audio or video beyond the time needed to route the request. | The chat text (or one voice note) submitted for that request — max 40 messages / 24,000 characters. Never your contact list or other chats. | United States | Standard Contractual Clauses (Art. 46(2)(c)) — OpenRouter states it relies on the European Commission's SCCs for transfers out of the EEA. Onward routing is governed by their terms and by the per-provider row below. |
| Microsoft Azure — EU region only if you turn managed AI on |
Runs the model that produces the completion | The same single request, passed on by the gateway. Not retained by us; we instruct the gateway, on every request, that it may only use a provider which does not store it at all. | European Union. We pin every request to the gateway's EU endpoint for this model, and we switch off its fallback: if that endpoint is unavailable the request fails rather than moving to a provider outside the EU. The same model is also offered from the United States by OpenAI and Amazon Bedrock — we do not use those. | None needed for the inference itself — it stays in the EU. The routing leg through the gateway is covered by the row above. This row depends on the model we run: if we change the model, or lift the pin, this row changes with it. |
| Plus Five Five, Inc. (trading as Resend) only if you sign in with an email code |
Delivers the one message that carries your sign-in code. No marketing mail, no tracking pixel. | Your email address and the code itself, for that one message | Ireland (EU) — messages are processed in their eu-west-1 region and do not leave the EEA to be sent. The company itself is incorporated in the United States. |
Their Data Processing Agreement, incorporating the EU Standard Contractual Clauses and the UK Addendum — these cover any access from the United States, since sending itself stays in the EEA. They also state certification under the EU–US Data Privacy Framework. |
| Hetzner Online GmbH (Germany) | Runs the API and the managed database described in Privacy §3, and keeps its backups | Account, licence, linked-number and AI-counter records; server request logs | Nuremberg, Germany (EU) — the server, its database and its daily backups all sit in that one data centre. Hetzner Online GmbH is itself a German company, established in the EEA. | None needed for the hosting itself — the provider and the machine are both inside the EEA, so nothing has to cross a border to be hosted. |
On the AI row, plainly: the gateway and the model provider are two separate companies and both see the text of that one request. Which model we route to is an operational choice we may change — when the provider changes, this page changes first, 30 days ahead. If you'd rather no third party saw any of it, leave AI off; the local features don't involve this row at all.
2. Standby providers
Stripe is configured in the codebase as a fallback and is not currently in use — no payment of yours has ever gone through it. If we ever switch to it we'll treat that as adding a sub-processor: its entity and region will be named in the table above, with 30 days' notice, same as any other.
3. Who is not on this list
Because their absence is a feature:
- No analytics or advertising provider. The site runs none — see Cookies.
- No newsletter or marketing platform. The only email we ever send is the sign-in code you asked for — that is the whole reason the delivery provider above is on the list. There is no mailing list to be added to.
- No CRM, support desk or session-replay tool. Nothing watches you use the product.
- No cloud storage of your chats, contacts or media. There is no bucket, because there is nothing to put in it.
4. Getting notified
Changes are posted here with a date, announced in the product, and — if you ask at [email protected] — sent to you by email at least 30 days in advance. You may object on reasonable data-protection grounds; see DPA §5 for what happens then.
5. Change log
| Date | Change |
|---|---|
| 6 August 2026 | Named the payment provider (Armitage Labs OÜ, trading as Creem) and the hosting provider (Hetzner Online GmbH). Both were already in use and already on this list — this completes their entries rather than adding anyone new, so it is not a change that triggers the 30 days' notice in §4. Hosting also moved within the EEA, from Frankfurt to Nuremberg. |
| 27 July 2026 | Added the email delivery provider, for passwordless sign-in codes. |
| 23 July 2026 | First published. |