What we have verified about your privacy

Third-party data-flow audit · revised 5 September 2026

What the app talks to

We audited every outbound connection in the app, the backend and the infrastructure, and wrote down what leaves our systems, to whom, and carrying what. The verdict: there is no analytics SDK, no advertising pixel, no session-replay tool and no tag manager anywhere in the frontend, backend or infrastructure, fonts are self-hosted, and the one third-party script in the whole product is Paddle's checkout, loaded only on the checkout page.

The connections that do exist are all functional rather than commercial, and none of them hands an identified user's health record to a party that could monetise it. Some of the lines below run outward rather than inward — a share link you make yourself, the feedback report you choose to send us — and they are written down for the same reason as the rest: they are paths your data can take.

• Open Food Facts, for food search and barcode lookup. What it reads: the words you type into food search, and the barcode you scan. Both go out from our server rather than from your browser, so Open Food Facts sees our server’s address and never your IP address, your identity, or your account. What you searched for is the only thing it learns. How it is used: the product it sends back — a name and the numbers per serving — fills in the entry you are about to log, so you do not have to type them. The entry is yours: it sits in your own timeline next to what you log by hand, and it is not sold, not shared, and never used for advertising. Where it goes: to Open Food Facts (openfoodfacts.org), a non-profit open-data project, and no further. What leaves us is the search word or the barcode; nothing that identifies you goes with it, and nothing that comes back is passed on to anyone.
• Dexcom Clarity CSV upload, whenever you upload one. What it reads: only the file you upload. A Clarity CSV holds your glucose readings and the times they were taken; BeeGoodHealth reads those and nothing else, and never signs in to Dexcom on this path. How it is used: those readings show up in your own timeline and charts next to what you log by hand. They are not sold, not shared, and never used for advertising. Where it goes: into your own account, stored the same way as everything else you log. It is not passed on to anyone.
• Dexcom Clarity sync, on the accounts that connected it while it was offered. What it reads: the same Clarity CSV export you could download yourself, fetched on your behalf. This path is closed to new connections and cannot be added to your account. For the accounts that connected while it was offered, we still store the actual Dexcom Clarity website username and password, encrypted at rest, and a server-side automated browser still uses those credentials to log into clarity.dexcom.com on the account holder’s behalf, on the schedule they would otherwise follow manually. This is browser automation of a real login — not an official Dexcom integration or API — and Dexcom’s Terms of Use prohibit automated or bot access to their services; it runs only at the account holder’s direction, solely to fetch their own data, and Dexcom does not sanction it and could interrupt it at any time. How it is used: those readings show up in your own timeline and charts next to what you log by hand. They are not sold, not shared, and never used for advertising. Where it goes: into your own account, stored the same way as everything else you log. It is not passed on to anyone.
• Your sign-in provider, Google, Yahoo or Microsoft. It learns that you signed in to BeeGoodHealth, and when, and receives no health data from us.
• Google Health, only if you connect it. It is off until you turn it on. What it reads: your weight, exercise and hydration entries, and on Premium your blood glucose as well. Read-only — BeeGoodHealth never writes anything back to Google Health, and reads nothing else from your Google account. How it is used: those entries show up in your own timeline and charts next to what you log by hand. They are not sold, not shared, and never used for advertising. Where it goes: into your own account, stored the same way as everything else you log. It is not passed on to anyone. As with any connect-with-Google button, Google knows you linked the app.
• Your browser's push service, only if you turn on push reminders. The reminder text is encrypted so the service cannot read it, but it does see that a message was sent to your browser and when. Leave push off and reminders never involve anyone else.
• Paddle, for billing. What it reads: your email address, a pseudonymous identifier for your account, and the name of the plan you chose. No health data of any kind — no entries, readings, medications, routines, charts or reports ever reach Paddle. How it is used: Paddle is the merchant of record: they are the seller on your receipt, and they register and remit sales tax and VAT on the sale. Checkout happens in Paddle’s own secure checkout — opened from our checkout page, but served by Paddle — so your card number and billing address are entered into Paddle’s form and never touch our servers, our logs, or our database. We never see or store a card number. Where it goes: to Paddle (paddle.com), who keep their own customer, transaction and invoice records to meet their own tax and accounting obligations.
• Amazon Web Services, which hosts the app. AWS is our infrastructure provider, not a party we share data with, and data is encrypted at rest.
• A share link, only when you make one yourself. What it reads: the entries already in your account, and nothing beyond them. A link opens a read-only view of your timeline, narrowed to the date range you set when you made it, and it carries nothing that names you: no email address, no name, no account details, and no way to sign in. How it is used: it exists so you can show a doctor, dietitian or family member your own record without giving them an account or emailing a file. Nobody gets a link unless you make one and send it. Where it goes: wherever you send it, and nowhere else. We never publish a link, never index one, and never send one on your behalf. The token in the address is long enough to be unguessable — but a link is a link, and anyone you give it to can pass it on, which is the one thing this cannot prevent. Stopping: revoke it from the Share page and it stops working straight away; every link the app makes also carries an expiry, so one you forget about stops working on its own. Revoking a link does not touch your entries — they stay in your timeline until you delete them, and deleting your account revokes every link with it.
• Amazon SES and our own mailbox provider, when you send us a feedback report. What it reads: only what the Send feedback form on the Account page collects: the message you typed, the category you picked (if any), which plan your account is on, your account id, and four details about the app as you were using it — the page (route) you were on, your viewport size, and your theme and palette settings. Nothing else rides along: no health entries, no screenshots, and the form has no way to carry them. How it is used: the report is stored in our own database — that copy is the record — and each one is also emailed as plain text to us so it actually gets read rather than sitting in a table. The message box is free text, so if you choose to write about your health in a report, we keep what you wrote, on the same terms as everything else. Where it goes: the stored copy stays in our database with the rest of your account. The mail goes out through Amazon SES to our own admin address, and on to the provider that hosts that mailbox — that provider is the third party on this path, and it holds the message the way it holds any other mail sent to us. The mail carries the message, the category, the plan, the four app details, and the stored report’s own id — a timestamp and a random number our server made up to label the row, which is how we find the stored copy again. Not your account id.

The beta request form on our homepage stores what you type on our own systems and sends it to no one.

The audit was first published on 1 August 2026 and re-run in full against the current code on 5 September 2026. Everything on this page was reconciled with that revision, including Google Health and the checkout page's Paddle script.

Where a line above says What it reads, that sentence is the app’s own wording rather than a summary of it: the same words appear in the privacy policy and on the card where you connect the thing, and a test fails if any of the three drifts from the others. They were last reconciled on 7 September 2026.

The audit also flagged two gaps on our side, and both have since been closed: this site did not send the same security headers as the app, and beta requests had no expiry. It now does, and they now expire automatically.

Read the privacy policy