The companies barua uses to run the service, each of which may touch personal data barua holds for you. It is a short list on purpose, and it is the whole list.
Status: draft 1.0, version , prepared 30 August 2026. Not in force. Last changed: .
| Company | What it does for barua | Where it processes | Where the data sits |
|---|---|---|---|
SupabaseSupabase, Inc. (US), hosting on AWS |
The database, the replay storage bucket, and account sign-in | United Kingdom, with support access from the United States | United Kingdom (London) |
NetlifyNetlify, Inc. (US) |
Serves the site and the operator app, and runs the pipeline that builds profiles and composes messages | United Kingdom for the pipeline and the app: every one of those functions is pinned to London. Two things run outside that pipeline, at whichever of our host's locations is nearest to whoever is asking, which may still be London. The pixel file is served from there, and who asks depends on the install. On a plain one the visitor's own browser asks, so the edge sees their connection: the address, the site it was for, and the time. On a site using the first-party proxy we hand out, the site's own server asks on a cache miss, so the edge sees that server rather than the person, unless the site's proxy forwards the visitor's address in a header, which is the site's configuration rather than ours. We ask for the file to be kept an hour, which is a request rather than a guarantee. The location lookup is called by the browser directly to us either way, including behind the proxy. It is skipped once an answer has been stored, so it is normally once a session and can repeat when a lookup fails or tabs open together. Neither writes an address into our database | Nothing is stored here. Compute only, plus logs |
AnthropicAnthropic, PBC (US) |
Decides whether a message is worth sending, and writes it | United States | Nothing is stored for barua. Contractually barred from training on what it is sent |
OpenAIOpenAI, L.L.C. (US), reached through Netlify's AI gateway |
Learns the shape of your site once a month: which pages mean what, and which messages
are worth trying. It is sent page paths and their counts, product names and prices, your
funnel milestones, the event names your site publishes, the name=value query
signatures seen on real addresses with the paths they appeared on, counts of people by funnel
position, the playbook you wrote, every message trigger that has ever reached someone here,
90-day totals per trigger of what was decided, sent, opened and clicked, and a sample
of up to 15 real titles of things individual people made. No contact details are sent as fields, and no
customer identifiers. Two of those inputs are free text a person wrote, the playbook and the
creation titles, so anything typed into them travels as typed. A title can be personal in
itself, which is why it is named here rather than folded into "page titles" |
United States | Nothing is stored for barua. Contractually barred from training on what it is sent |
MailgunSinch Email, formerly Mailgun Technologies, Inc. (US) |
Delivers the messages barua sends for you, and receives the template emails you forward | United States | United States. Delivery logs, and forwarded templates for about three days |
Domain registration and DNS sit with GoDaddy, and they are not on this list because they never hold personal data. Nor is anything on your own site: what your visitors see is served by you.
Data leaves Europe at these points, and the table above is the authoritative list rather than this paragraph. Deciding and writing a message passes the distilled profile to a model provider in the United States. Once a month the summary in that table goes to a second provider there. Sending a message hands the recipient's address and the message to the delivery provider. A support engineer at our database provider can reach stored data from the United States when they are fixing something. And the lookup that turns a visit into a city runs at whichever edge is nearest the visitor, which can be anywhere.
Those transfers are meant to run on the European Commission's standard contractual clauses, or on a provider's certification under an approved framework where it has one. Being straight about where that stands: we have read and confirmed the mechanism for the provider that decides and writes messages. The others we have not finished checking, and Annex 3 marks each one, so you can see which is which rather than taking a blanket sentence on trust. The paperwork is available on request.
The database and every piece of pipeline compute sit in London. That is outside the EU, and this page says so rather than saying "EU hosting", because the two are not the same thing and you should not have to find that out yourself. It is covered by the European Commission's adequacy decision for the United Kingdom, renewed in December 2025 and running to December 2031, which means data reaches it from the EEA on the same footing as an EU destination, with no standard contractual clauses and no transfer assessment to sign. If you need it inside the EU specifically, say so and we will talk about it.
We give you at least 15 days' notice before a new subprocessor starts handling your data, by email to the account address. If you object on reasonable data protection grounds, tell us within those 15 days and we will try to solve it. If we cannot, you may end the agreement for the affected part of the service without penalty and get back the unused part of what you paid.
Removals do not need notice. This page carries the date it last changed, at the top, and we keep the old versions.