Eatline Privacy Policy
DRAFT — rewritten by lane 186, 10 Sep 2026, to ground every claim in the current code (cited in an HTML comment after each paragraph) rather than in what the product was planned to do. Have a lawyer review before publishing. This replaces the previous draft of this file; see this lane's own report for what changed and why.
Last updated: [date of publication]. Effective date: [date].
Eatline is an iOS app that maps restaurants and ranks what to order at each one for your goal, operated by [LEGAL ENTITY] ("we", "us"). This policy covers what the app and its backend actually collect, why, how long it's kept, and who else sees it.
Account and sign-in
You sign in with a one-time 6-digit code Supabase emails you — there is no password to set or store, and no separate sign-up screen.
Sign in with Apple is designed in the same screen's code but not shipped — it needs a paid Apple Developer account Eatline does not have yet.
Once signed in, the app can hold: your goal-setting profile, saved cities, favourites, chat history, "Healthify" swap requests, subscription status, usage counters, restaurant claims and menu submissions you've made, and reports you've filed — see the sections below for each. All of it is keyed to your account id.
Deleting your account. Settings > Delete account calls the app's own /account/delete endpoint, which deletes your Supabase Auth record; Postgres cascades that one delete through every table above automatically, in the same request — nothing is left behind under your account.
The one exception: if you ever tapped a restaurant pin on the map, that tap record is kept for coverage planning, but your account id on it is cleared rather than the row being deleted.
Deleting your account does not cancel an active App Store subscription — that's a separate system billed by Apple. The deletion screen links directly to managing it.
Server logs for account deletion record your account id only — never your email, access token, or any other identifying detail.
Your goal profile
To tell you what to order "for your goal" — cut, bulk, maintain, high protein, low carb, GLP-1 portions, or budget — the app asks for sex, weight, height, age and activity level, and stores the calorie/protein/carb targets it computes from them.
This is used only to compute your own targets and rank menu items against them — never for advertising (see "Third parties" below) — and is deleted with your account.
Location
The map uses your device's location in the foreground only, to centre the map and to tell our server "what's near me"; the permission prompt says exactly that.
Your coordinates are sent to our server with each map search to run that query; we do not keep a location history tied to your account — no such table exists.
The base map itself is Google's own Maps SDK, so Google's map component sees the area you're viewing the same way it would in any app built on that SDK — that's Google's client-side behaviour, not a server call our code makes.
If you tap a restaurant pin we haven't verified yet, we log that tap for coverage planning: the place's Google id, its coordinates, and your account id if you're signed in (nothing identifying if you're not).
When a Google Places API key is configured on our server (none is, as of this writing) and you're signed in, that same tap can also fetch live opening-hours and rating information from Google to show you — used once to answer that one request and not stored anywhere, by us or in any cache.
Tapping "Verify now" sends only the place's id to our server, which queues it; a background worker — never triggered live by your own tap — may later call Google once to find that restaurant's own website. The result becomes part of the restaurant's own menu record, never linked back to you or to any location.
A database table exists that could hold a place's Google id, latitude and longitude for up to 30 days (the limit comes from Google's own terms) — but as of the current code, no live, user-triggered request path writes to it at all; the one thing that does is an internal backend coverage job, unrelated to any single visit of yours.
Saved cities
Cities you save for "Travel mode" are written from the app straight to our database under your account (a snapshot of the city's name and centre point taken when you saved it) — this goes directly through Supabase, not through our own API server.
Deleted with your account.
Claiming a listing, and submitting a menu
If you tell us you own or work at a restaurant ("Own this place? Claim it"), we collect your claimed role (owner, manager, staff, or other), a contact email, and, optionally, the business's website and a short note.
If you submit a menu for a place — whether or not you claimed it — we store the link or the text you pasted.
A person on our team reviews these by hand; nothing paid or public unlocks automatically from them.
Both are deleted with your account.
Verify-now requests and "Report a change"
Tapping "Verify now" on an unread pin sends only that place's id from your device; we separately log the request against your account to enforce a daily limit.
"Report a change" (flagging a wrong or stale menu) stores which restaurant, one of five fixed reasons, and an optional note (500 characters max) against your account, so the same person can't report the same place more than once a day.
Both are deleted with your account.
Chat and "Healthify my order"
Asking about a specific menu (Chat) or asking for lower-calorie/higher-protein swaps to an order (Healthify) requires signing in, and is answered from the menu's own data first. Only when that isn't enough is a request sent to Anthropic's model API — carrying the relevant menu items, their macros, and your goal's targets, never your name, email, or account id.
Both are metered for a free account (a few uses a day) and unmetered once you're paid.
Your questions and the app's answers are stored under your account so a conversation can continue, and deleted with it.
Menu photos ("Snap the menu")
If you photograph a menu for a place we haven't read yet, the photo travels only inside that one request — there is no upload endpoint or storage bucket for it — and it's sent to Anthropic's model API to extract dish names and, where legible, prices. We do not store the photo itself.
What the model reads becomes part of that restaurant's own shared menu, available to every diner who looks at that place afterwards — it is not kept as your personal data.
Analytics
Product analytics (PostHog) runs only in a build that has a PostHog key configured at build time; an unconfigured build — every build shipped so far — sends nothing at all.
Exactly eight events exist in the code and nothing else: app opened, a goal selected, a place opened, "Verify now" tapped, the paywall viewed, and a purchase started, completed, or restored. No event carries your name, email, a restaurant's identity, or a location coordinate — properties are limited to things like which goal you picked.
Your account id is attached to these events (so a specific bug report can be investigated) from sign-in until sign-out.
Crash reporting
Crash reports (Sentry) work the same way: active only in a build with a Sentry key configured; otherwise an error is only logged to the device's own console and never leaves it.
When Sentry is configured, your account id is attached to crash reports the same way as analytics, so a crash can be traced back to your account for debugging.
Purchases and subscriptions
Subscriptions are billed by Apple through the App Store. RevenueCat manages entitlement on our behalf and notifies our server of every purchase, renewal, cancellation, or billing event.
We store your subscription's status, product, trial and renewal dates, RevenueCat's own purchaser id, and the complete event RevenueCat sent us, against your account.
We never see or handle your card details — Apple is the merchant of record.
As of this writing, no RevenueCat project has a live key configured, so every build shipped so far runs a local mock instead of a real purchase — this section describes what the shipped code does once a key is set, not a hypothetical design.
Third parties
| Who | What they get | Why |
|---|---|---|
| Supabase | Your account id/email and everything in this policy that's stored in our database (profile, saved cities, favourites, chat, subscriptions, claims, reports) | Runs our database and handles sign-in |
| Railway | Requests to our own API server in transit | Hosts packages/api |
| Google (Maps SDK, on your device) | The map area you're viewing, per Google's own client SDK behaviour | Draws the base map |
| Google (Place Details, server-side, only once a key is configured) | A tapped place's id | Live hours/rating for a tap card, and finding a restaurant's own website during verification — see "Location" above |
| Anthropic | The specific menu, question, or photo needed to answer one request — never your name, email, or account id | Reads menus; answers in-menu chat questions; suggests order swaps |
| RevenueCat | A purchaser id, the product bought, and transaction/renewal events | Manages your subscription entitlement |
| Sentry (only if configured) | Your account id plus a crash's stack trace and device details | Find and fix crashes |
| PostHog (only if configured) | Your account id plus one of the eight named events above | Understand what's used |
| Apple (App Store) | Your payment method, handled entirely by Apple | Processes payment; hosts the app |
Named in earlier planning but not found anywhere in the current code (checked 10 Sep 2026 — grepped `apps/mobile/src`, `packages/api/src`, `packages/pipeline`, `packages/jobs`, `packages/crawler`, and every `package.json`): Singular (attribution), Resend (transactional email), and Cloudflare R2 as a location for the shipped map's own tiles — the production map is the Google Maps SDK above, not the self-hosted tile set, which CLAUDE.md itself says is "kept only for the web QA build... no longer the product map." FatSecret and Nutritionix appear only as reference URLs noting where a chain publishes its *own* nutrition page for our crawler to read — never as a live, per-request API call, and never carrying any user's data. If any of these go into the shipped app, this section needs updating before it's accurate again.
Retention
| What | How long |
|---|---|
| Account, profile, saved cities, favourites, chat, Healthify requests, subscriptions, usage counters, claims, owner-menu submissions, verify-now requests, menu reports | Until you delete your account, then removed in one step |
Map-pin taps (poi_taps) | Kept indefinitely for coverage planning; your account id is cleared, not the row, when you delete your account |
| Anything Google-sourced beyond a place's id (hours, rating, price, coordinates) | Not stored beyond the single request that needed it — see "Location" above |
| A menu photo you snap | Not stored at all |
| Analytics/crash data (only if those tools are configured) | Held under PostHog's/Sentry's own project retention settings [to confirm once those projects exist] |
Age rating and children
Flagged, not decided, by this draft. Nothing in the shipped code checks or enforces an age. Other documents in this repository assert a 17+ App Store rating, but the one place age appears in the schema allows a profile age as low as 13 — the two are inconsistent, and this draft does not resolve that. Arthur/the lead needs to confirm the intended App Store age rating before this section can say anything firmer about children's data.
Your rights
You can see and change your goal profile directly in the app (Settings), and delete your whole account — and everything under it — from Settings > Delete account, with the one exception described under Retention above.
There is no automated "download my data" feature in the app today — the API has no such endpoint.
For a copy of what we hold, a correction, or any other request, contact hello@eatline.app.
About the numbers Eatline shows
Every calorie/macro figure and every Healthify/Chat answer carries this line, verbatim, from the code:
Estimates, not medical advice. Check with your doctor for anything that depends on being exact.
This is a statement about the product's limits, not about how we handle your data — included here because it's part of what this draft was asked to quote exactly.
Changes to this policy
We'll post updates here with a new "last updated" date and, for anything material, tell you in the app.
Contact
[LEGAL ENTITY], [POSTAL ADDRESS], [JURISDICTION]. Email: hello@eatline.app.