Privacy Policy

Biteline is operated by Cloudevia, registered at 145 rue des Meuniers, 92220 Bagneux, France under company number 952479681. We are the data controller for the personal data described in this policy.

For anything about your data — a question, a request, or a complaint — write to contact@getbiteline.com. A person reads that mailbox; you do not need to use a specific form of words.

Biteline turns a photo of a meal into an estimate of its calories, protein, carbs and fat, and tracks those numbers against a daily target calculated from your body and your goal. Three things follow from that, and they shape this whole policy:

• We need some data about your body — sex, date of birth, height and weight — because the calorie formula does not work without it.
• The photos you take are uploaded to our storage and analysed by an AI model. They are not analysed on your phone — but they do not leave the EU: the photos are stored in AWS in Paris (eu-west-3), and the analysis runs on Amazon Bedrock in the EU.
• What you eat, when you eat it and what you weigh is sensitive. We treat it that way: we do not sell it, we do not use it for advertising, and we do not share it with data brokers.

Account data

Your email address, your display name if you give us one, and a hashed password if you signed up with an email and password. If you sign in with Apple or Google we receive the identifier and email address that the provider returns to us — including Apple’s private relay address if you chose to hide your email. We never receive your Apple or Google password. We also store the timezone your device reports, because the daily scan allowance and your “today” have to reset at your midnight, not ours.

Profile and goal data

Answers to the onboarding questions: sex, date of birth, height, current weight, activity level, goal (lose, maintain or gain), target weight and the pace you want to move at. From these we calculate your daily calorie and macro targets. If you edit any of them we recalculate and keep the history of targets, so your past days still show the target you were actually working to.

This is health-adjacent data. Under EU and UK data protection law some of it — weight, body metrics and dietary goals — can amount to data concerning health. We handle it on the basis of your explicit consent (see section 05), we keep it to what the calculation genuinely needs, and we never ask for medical history, diagnoses or medication.

Meal and food data

Every meal you log: title, meal type, the ingredients and their weights, the calories and macros, the time you ate and the day it counts towards. Also your weight log entries and your logging streak.

Meal photos

Photos you take or pick for a scan, plus the AI analysis derived from each one. Section 04 covers these in detail because they deserve it.

Subscription data

Whether you are on the free tier or have an active Biteline Premium subscription, when it renews or expires, and the events that changed it. We never see or store your card number: purchases happen inside the App Store or Google Play, and RevenueCat relays the resulting entitlement to us. We also count how many AI scans you have used today, to enforce the free-tier limit of 3 scans per day.

Device and notification data

If you turn notifications on, we store the push token Firebase Cloud Messaging issues for your device, plus the platform (iOS or Android). The token identifies a device installation, not you personally, but we link it to your account so we can send your reminders and nobody else’s.

Product analytics, in the app

The Biteline mobile app records product analytics through PostHog, on PostHog’s EU Cloud. It answers questions we would otherwise be guessing at: how many people finish onboarding, how often a scan succeeds and how long it takes, which step people give up on, whether anyone gets through the paywall.

Only events we wrote by hand are recorded. There is no autocapture, so a tap or a screen is not logged merely because it happened. There is no session replay: nothing records your screen. There is no advertising SDK, no attribution SDK and no tracking pixel in the app. Every event that exists is one a developer added on purpose, and the full list is short — opening the app, moving through onboarding, signing up and signing in, starting and finishing a scan, logging a meal, seeing the paywall, buying or not buying, hitting the free daily limit, logging a weight, turning a reminder on or off, and deleting your account.

Each event carries a few properties, and we keep your health data out of them deliberately. An event may say that a scan finished with fair confidence in 4,300 milliseconds from the camera, that you are on step 3 of 7 of onboarding, or that an annual plan was selected. An event never carries your weight, a calorie or macro figure, the name of a food or a meal, or a photo. Those stay in your account and are never sent to PostHog. Take weight logged: we record that it happened, never the number.

The identifier attached to every event is your Biteline account id, so all of it is linked to you rather than anonymous. That is precisely why the list of permitted properties is as short as it is: a category, a count, a yes or no, a duration in milliseconds. PostHog also receives the small amount of technical context its SDK sends with each event: whether the device is a phone or a tablet, your screen size, a session identifier, and a random identifier its SDK stores on your device. It does not receive your app version, your operating system, your device model, your language or your timezone — the optional packages that would collect those are deliberately not installed. Signing out resets that identifier, so the next person to use the phone starts fresh instead of inheriting your history.

This website is a separate matter and runs no analytics whatsoever. Section 12 covers it.

Diagnostic data

Separately from the above, we keep the server-side record our API produces while answering your requests: the fact that a request happened, whether it succeeded or failed, and the technical error detail when something breaks. That is how a bug gets fixed. It is kept short-term and it is not used to profile you.

Support correspondence

If you email us, we keep the email and our reply so we can follow up and so the next person who helps you has the context.

This is the part people most want a straight answer on, so:

• Where the photo goes. When you scan a meal, the app asks our API for a short-lived upload permission and sends the image directly to an Amazon S3 bucket we control — the bucket biteline-media, in the AWS Paris region (eu-west-3). Each file is stored under a path unique to your account with a randomly generated filename.
• Who can reach it. The bucket is private. It is not browsable, nothing in it is indexed by search engines, and an anonymous request for a photo is refused — there is no address that opens the image on its own. When the image actually has to be read, our server signs a one-off link for that single file, valid for a few minutes, and that link is what the reader fetches. A link that escapes — in a screenshot, a log, a support ticket — stops working shortly afterwards instead of granting access indefinitely.
• Who analyses it, and where. Our server reads the image and sends it to Amazon Bedrock, together with a prompt asking for a per-ingredient nutritional breakdown. Bedrock runs the model — Anthropic’s Claude, claude-sonnet-5 — inside AWS. We submit that request to Bedrock’s Paris endpoint (eu-west-3), and the model we call is an EU cross-region inference profile: AWS may serve the inference from any region in its EU geography — whichever has capacity — and not necessarily from Paris.
• Your photo stays in the EU. This is the part worth being precise about, so precisely: the image is stored in Paris (eu-west-3), and it is analysed in the EU — in Paris or in another AWS region inside the EU, wherever Bedrock serves it from — by AWS, under our AWS agreement. What we can promise you is the EU boundary, not a single city. It is not sent to Anthropic’s own API, and Anthropic does not receive it. Using the model is not the same as handing the data to the company that made it.
• Training. Amazon Bedrock does not use your images, our prompts or the resulting outputs to train any model, and does not pass them to the model provider. Neither do we: we do not use your meal photos to train, fine-tune or evaluate any model of our own.
• Retention at AWS. Under AWS’s published terms, Bedrock does not store your prompt or the model’s response once the request has been answered.
• What we keep. The photo stays attached to the meal in your diary so you can look back at it. Delete the meal and the photo goes with it. Delete your account and every photo under your account path is erased (section 08).

We also store the raw analysis response, the model used, the prompt version and the token counts. That is how we debug a bad estimate and how we work out what a scan cost us — it is engineering and billing data, not a profile of you.

If you are in the EEA or the UK, the GDPR requires us to name a legal basis for each purpose. Ours are:

• Running your account and the app — creating your account, storing your meals, showing your progress, enforcing the free-tier scan limit, unlocking Premium. Basis: performance of our contract with you (Art. 6(1)(b)).
• Calculating your calorie and macro targets from your body data, and storing your weight history. Basis: your explicit consent (Art. 9(2)(a)) for the health-related elements, alongside contract for the rest. You give that consent by completing the onboarding questions; you can withdraw it at any time by deleting your account, and you can change or clear individual values in Profile at any point.
• Sending push notifications and reminders. Basis: your consent, given through the system permission prompt and the toggles in Profile. Turning them off in either place stops them.
• Transactional email — password reset codes, security notices, and changes to these terms. Basis: contract and our legal obligations.
• Keeping the service secure and working — rate limiting, abuse detection and error diagnostics. Basis: our legitimate interests in operating a functioning, safe product (Art. 6(1)(f)), balanced against your rights by keeping the data minimal.
• Understanding how the app is used — the product analytics described in section 03: how many people finish onboarding, whether scans succeed, where people give up. Basis: our legitimate interests in improving a product whose problems we can otherwise only guess at (Art. 6(1)(f)). We balance that against you in three concrete ways: only events written by hand are collected, never everything you do; every health value — your weight, your calories, your macros, your food names, your photos — is kept out of the event properties, so no Article 9 health data goes into analytics at all; and the events are held in the EU by a processor that may only act on our instructions. Because this basis is legitimate interests, you have the right to object to it, and section 09 says how.
• Accounting and tax records for subscriptions. Basis: our legal obligations (Art. 6(1)(c)).

We do not use your data for automated decision-making that produces legal or similarly significant effects. The AI estimates a plate of food; it does not decide anything about you.

We do not sell your personal data, and we do not share it for advertising. We use a small set of service providers, each under a data processing agreement, each doing exactly one job:

• Amazon Web Services — does three jobs for us. It stores your meal photos in the private S3 bucket biteline-media in Paris (eu-west-3); it analyses them through Amazon Bedrock in the EU — submitted to the Paris endpoint and served from AWS’s EU region group; and it hosts this website via AWS Amplify. Your photos are handled entirely within the EU.
• Railway — hosts our API and the managed PostgreSQL database holding your account, profile, meals and targets.
• RevenueCat, Inc. (United States) — reconciles your App Store or Google Play purchase into an entitlement so the app knows you are Premium.
• Apple and Google — process the payment itself and act as their own controllers for it. Their privacy policies govern that part; we only receive the outcome.
• Google Firebase Cloud Messaging — delivers push notifications to your device.
• Google Sign-In and Sign in with Apple — verify your identity when you choose those sign-in methods.
• Resend — sends password reset codes and service emails.
• PostHog — our product analytics processor, for the mobile app only, running on PostHog’s EU Cloud so the events are stored in the European Union. It receives the named events described in section 03, the technical context of the device that sent them, and the identifier they are attached to — your Biteline account id. It receives nothing else about you: no weight, no calories, no macros, no food or meal names, no photos. It acts only on our instructions under a data processing agreement, it is not an advertising network and not a data broker, it does not sell the data, and it does not combine it with data from any other company’s app or website.

That is the whole list. It has exactly one analytics vendor on it — PostHog, above, in the app and not on this site — and no advertising network, no attribution network and no data broker, because we use none.

We will also disclose data if the law requires it — a valid court order or a lawful request from an authority — and, if we are ever acquired or merged, to the acquirer, in which case we will tell you before your data moves and this policy continues to apply until you are given a new one.

The data most people worry about stays in the European Union. Your meal photos and the AI analysis of them never leave the EU — the photos are stored in AWS’s Paris region (eu-west-3), and the analysis runs on Amazon Bedrock in the EU: we submit it to the Paris endpoint, and AWS may serve it from any of its EU regions. Your account, profile, meals and targets are held in our EU-hosted database, and so are the product analytics events in section 03: we use PostHog’s EU Cloud, which stores them in the European Union.

What does cross a border is narrower: subscription events through RevenueCat, Apple and Google; push notifications through Firebase Cloud Messaging; and service emails through Resend. Those providers are US companies, so that processing can involve a transfer outside the EEA. PostHog belongs in this paragraph too, for a narrower reason: the events themselves stay on its EU Cloud, but the company is US-incorporated, so staff supporting the service can reach them from outside the EEA. We count that as a transfer rather than argue it is not one.

Where it does, the transfer relies on the European Commission’s Standard Contractual Clauses, supplemented by encryption in transit and at rest and by contractual limits on what the provider may do with the data. You can ask us for a copy of the safeguards for any specific transfer by writing to contact@getbiteline.com.

• Account, profile, meals, photos and weight history — for as long as your account exists. This is a tracking app; the history is the product.
• After you delete your account — everything is erased immediately, in the same request that asks for it. Every meal photo you uploaded is deleted from S3 first, then your account record goes, and your meals and their items, every AI analysis and the stored model response behind it, your daily targets, your weight history, your scan counters and your push tokens are deleted with it. Your analytics history goes in the same step: the person record PostHog holds for your account id, and the events recorded against it, are deleted too. There is no grace period and no hidden copy: we cannot undo a deletion, which is why the app asks you to confirm. If you want your data first, ask us for an export before you delete.
• The one thing we keep, anonymised — a record that a purchase event happened: its type, the product, and when the subscription expires. We keep it because it is what stops a repeated billing message from the store being applied twice, and because we need it for our accounts. At the moment you delete, the link to your account is removed and the original message from RevenueCat — which carried your account identifier — is erased. What remains is a billing fact with no person attached to it.
• Backups — encrypted database backups are kept on a rolling 30-day cycle and are overwritten in turn. This is the one place deleted data can outlive the deletion: a row erased today may still sit in a backup taken yesterday until that backup rotates out, within 30 days. We never restore a deleted account from a backup, so it cannot come back into the app.
• Subscription and payment records — retained for as long as accounting and tax law requires, typically up to 10 years, even after account deletion. These are financial records, not diary data.
• Product analytics events — kept in PostHog for 12 months from the day the event happened, then deleted automatically. Deleting your account removes them sooner, as described above.
• Push tokens — deleted when you disable notifications, sign out, or delete the app.
• Support emails — up to 3 years after the conversation ends.
• Server logs — kept short-term for debugging and abuse detection, then rotated out. These are the diagnostic records in section 03, not analytics; the analytics events have their own window, above.

Under the GDPR (and equivalents elsewhere) you can ask us to give you a copy of your data, correct it, delete it, restrict or object to how we use it, hand it over in a portable format, or withdraw a consent you previously gave. Withdrawing consent does not undo processing we did before you withdrew it.

Objecting to the analytics

The product analytics in section 03 rest on our legitimate interests, and that gives you a right to object to them. Write to contact@getbiteline.com from your account address and we will delete the events recorded against your account id in PostHog.

We will not claim more than that. There is no switch in the app that turns the analytics off, so the only thing that stops new events at source today is deleting your account, which stops them along with everything else. If that is not a good enough answer, tell us — we would rather hear it than not.

Deleting your account in the app

You do not need to ask us, and you do not need to explain yourself. Open Profile in the app, scroll down to Account at the bottom of the screen, tap Delete my account and confirm. That immediately closes the account and starts the erasure described in section 08. If you cannot open the app, follow the steps under Delete your account on our support page, or email contact@getbiteline.com from the address on the account.

Deleting your account does not cancel a subscription bought through the App Store or Google Play. Cancel that separately — the support page has the exact steps for both stores.

Getting a copy of your data

Email contact@getbiteline.com from your account address and we will send you a machine-readable export of your profile, meals, analyses, targets and weight history within 30 days, free of charge.

If you are not happy

Tell us first — most things are a misunderstanding we can fix the same week. If we cannot resolve it, you have the right to complain to your local data protection authority. Our lead supervisory authority is the CNIL (Commission Nationale de l’Informatique et des Libertés).

Biteline is not designed for, marketed to, or intended for children. You must be at least 13 to create an account.

In the EEA and the UK, if you are under 16 — or under the lower age your country has set, which is never below 13 — a parent or guardian must consent to your use of Biteline and to the processing of your data. We rely on that consent for the health-related data described in section 05.

Calorie tracking can be harmful for people under 18 and for anyone with a history of disordered eating. We do not recommend the app for either group. If you believe a child has created an account, write to contact@getbiteline.com and we will delete it.

Passwords are stored only as salted hashes — we cannot read yours, and neither can anyone who obtains our database. All traffic between the app, our API and our providers is encrypted with TLS. Stored data, including meal photos, is encrypted at rest, and the photo storage is private: access to any individual image is granted one file at a time, by a signed link that expires within minutes.

Access to production data is limited to the people who need it to operate the service, and every API request is checked against the owner of the record: a request for a meal that is not yours returns “not found”, not “forbidden”, so the existence of other people’s data is not confirmed to you.

No system is perfect. If a breach affects your data and is likely to put your rights at risk, we will notify the relevant supervisory authority within 72 hours and tell you directly.

This marketing site is deliberately light. It loads no analytics script, sets no advertising cookies and runs no cross-site tracking pixels — we genuinely do not know which pages you read here. Any cookie it does set is strictly necessary to serve the page or to remember a preference you expressed on it. The product analytics in section 03 are in the mobile app only and do not reach this site; reading this page is not measured by anyone.

If we ever add measurement that is not strictly necessary, we will ask for your consent before it loads, and this section will say so.

When we change this policy we update the date at the top. If the change is significant — a new category of data, a new processor handling your photos, a new purpose — we will tell you in the app or by email before it takes effect, and where the law requires it we will ask for your consent again rather than assume it.

Previous versions are available on request.

Privacy questions, rights requests and anything else — including help with the app — all go to one address: contact@getbiteline.com. We are small enough that a second mailbox would only mean a slower reply.

Postal: Cloudevia, 145 rue des Meuniers, 92220 Bagneux, France