Eatline Privacy Policy
Last updated: 27 October 2026.
Eatline is an iOS app that maps restaurants and ranks what to order at each one for your goal, operated by Trela Studios Pty Ltd (ABN 60 702 927 393), an Australian company ("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 Sign in with Apple, or with a one-time 6-digit code Supabase emails you — there is no password to set or store, and no separate sign-up screen. With Sign in with Apple, Apple gives us the email address you choose to share (or a private relay address). Eatline does not ask Apple for your name.
Once signed in, the app can hold: favourites, saved dishes ("My orders" in the Saved tab), subscription status, usage counters, restaurant claims and menu submissions you've made, reports you've filed, messages you've sent us through Talk to us, the days you opened a restaurant's menu, any code you entered or were given, your notification token if you allowed notifications, and the menu notifications we've sent you — see the sections below for each. All of it is keyed to your account id. Your goal-setting profile (sex, weight, height, age, activity level, goal) stays on your device: it travels with each request so our server can work out your calorie and protein targets for that one answer, and is not kept on the server. Chat questions and "Healthify" requests are answered and not stored — see "Chat and Healthify" below.
Deleting your account. You > Delete account (or You > Delete my data, if you never signed in) 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 same request also asks RevenueCat, our subscription provider, to delete its record of your purchases, asks Singular, our ad-measurement provider, to erase what it holds under your account, and ends Eatline's Sign in with Apple access.
Some records outlast that delete; "Retention" below lists each one and how long it is kept. 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. The email of a listing claim or a menu submission stays in our inbox until you ask us to delete it (see "Claiming a listing, and submitting a menu" below). So does the email of a message you sent through Talk to us (see "Talk to us" below).
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.
Our API's own log lines for account deletion record your account id only — never your email or access token; like every request, the delete request's IP address and user agent are in Railway's request logs (below).
Sessions and IP addresses. Supabase, which handles sign-in, keeps the IP address and your device's user agent (its app and system version) for each signed-in session, until that session is signed out or, for a session left behind on a device (for example when you delete the app while signed in), until your account is deleted. Supabase's own logs of the requests the app makes to sign you in and keep you signed in also record the IP address and user agent, and can include your account id and email; they are kept for 7 days under Supabase's log retention for our plan. Our API server is hosted by Railway, whose request logs record the IP address and user agent of every request to it; they are available to us for 30 days under Railway's log retention for our plan, and Railway holds them under its own retention policy. Our server itself uses the IP address only in memory, to limit how often one address can call it: it drops the address after about 10 minutes without a request (a daily count for signed-out requests is cleared after the day ends, UTC), and never writes it to our database.
Your goal profile
To tell you what to order "for your goal" — high protein, calorie deficit, bulk, maintain, low carb, or GLP-1 portions — 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.
Apple Health
With your permission, Eatline reads today's dietary energy (calories), protein, carbohydrate and fat already logged in Apple Health, to show a live meal budget on the restaurant sheet — for example, "940 kcal had · 840 left for this meal." If you choose to log a dish you've ordered, Eatline can also write that dish's own calorie and macro figures back to Apple Health.
This is entirely optional. The app works fully without it, you choose whether to turn it on, and you can revoke access at any time in iOS Settings > Health.
Health data read from or written to Apple Health never leaves your device: Eatline does not send it to our servers, does not store it in our database, and never uses it for advertising, marketing, or any other data-mining purpose.
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.
A search, including the one under "Add a restaurant", can also go to Google, in two ways.
To find places to add, our server sends what you typed and an area around your location or the part of the map you're searching (a circle of about 50 km) to Google Text Search. Nothing from a Text Search is written to our database or tied to your account. So the same search isn't sent to Google twice, our server keeps the search words, that area rounded to about 1 km, and Google's answer in memory for up to 24 hours.
To move the map to a suburb or city you searched for, our server can send what you typed and the country you're searching in to Google Geocoding — never your coordinates or your account id. We keep the words you searched and the suburbs or cities Google matched to them in our database, never tied to your account — see "Retention" below.
The base map is Google's Maps SDK. As in any app built on it, Google's map component sees the area you're viewing and, by Google's own declaration, collects a device identifier, how you use the map, and crash and performance data, which Google uses for analytics. That's Google's client-side behaviour, not a server call our code makes. What Google receives through its map and through the Google services above is covered by the Google Privacy Policy.
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 and you're signed in, opening a place 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. We do record each of these lookups against your account (your account id and the time, nothing about the place) to enforce a daily limit, and delete those records with your account.
Picking a result under "Add a restaurant" in search sends that place's Google id to our server. If we don't already list it, our server looks it up on Google to create the restaurant's listing and queues its menu to be read, and looks it up on Google again when that menu is read, to find the restaurant's own website. The add-menu panel (after adding a restaurant, or from a restaurant's card) lets you paste a link, upload a PDF, or let Eatline look on the restaurant's own website. What is read becomes part of the restaurant's own menu record, never linked to any location of yours. When a menu you send changes a restaurant's menu, we may record which account sent it, so the change can be reviewed and undone; that record is removed when you delete your account.
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 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.
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. So they reach that person, each claim and each menu submission is also emailed to our team's inbox (hello@eatline.app, hosted by Microsoft 365) through Resend, our email-sending provider. A claim's email carries everything above; a menu submission's carries the link or text and your note.
Both are deleted from our database with your account. The emails are not deleted automatically: they stay in our inbox until you ask us to delete them (write to hello@eatline.app), and Resend keeps its own record of each email it sent under its retention settings.
Adding a restaurant, and "Report a change"
Picking a restaurant under "Add a restaurant" sends only that place's Google id from your device; when that creates a new listing, we log the request against your account to enforce a daily limit.
"Report a change" (flagging a wrong, stale or offensive menu) stores which restaurant, one of six 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.
Notifications
If you allow notifications, the app sends our server this device's notification token (the address Apple gives your phone for this app), stored against your account (push_tokens). We use it for one thing: when you add a restaurant or ask us to read its menu, we send you one notification when that read finishes, saying the menu is ready or that we couldn't find it online, and we record that we sent it (menu_ready_notices) so you never get a second one for the same restaurant. That notification is never marketing. Apple's push service delivers it and receives the token, the notification's words (which name the restaurant) and our id for that restaurant, never your account id, email or location. Signing out removes the token from your account, and deleting your account deletes the token and the record. You can turn notifications off in iOS Settings at any time.
The app also schedules reminders about your plan, your free week and your order for the day on your phone, and what they say never leaves it; You > Reminders turns them off.
Talk to us
You > Talk to us (also offered when a menu read fails, when a restaurant won't load, and when you answer "Not really" to "Enjoying Eatline?") sends us a message from the app. Before you send it, the screen lists everything that goes with it: your message; the address you'd like a reply at, if you give one (it starts as your sign-in email, and you can change or clear it); the app version, iOS version, device model and App Store country; your goal (for example Calorie deficit); the screen you opened it from; and, if you have an account, your account id. When you came from a restaurant that failed, it also names that restaurant. It never includes your location or anything from Apple Health.
We store the message in our database and email it to our team's inbox (hello@eatline.app, hosted by Microsoft 365) through Resend, with your reply address as the one we answer. We reply by email; nothing is answered in the app.
A message sent with an account is deleted from our database with your account; one sent while signed out isn't tied to any account, and we delete it when you ask. The email is not deleted automatically: it stays in our inbox until you ask us to delete it (write to hello@eatline.app), and Resend keeps its own record of each email it sent under its retention settings.
"Enjoying Eatline?" is a card the app shows at most once every 90 days. "Yes" hands over to Apple's own rating prompt; "Not really" opens Talk to us. The counts that decide when it appears are kept on your device only.
Which days you opened a menu
When you open a restaurant's menu, our server notes the day. Which days you opened a restaurant's menu, and whether you compared two places that day — never which restaurant or what time — kept 90 days, deleted with your account. We use it to count, week by week, how many new trials actually use Eatline at a meal.
Your permission before anything goes to Anthropic
Chat, Healthify and menu reading (a PDF or link you add, or "Let Eatline look") use Claude, an AI model made by Anthropic. The app asks your permission before any of them sends anything to Anthropic, on a "Before you start" screen the first time you use one of them, and says what is sent. If you choose "Not now", those features stay off and nothing is sent to Anthropic until you agree. Your answer is kept on your device. Unless You > Share usage stats is off, the app also counts the answer (agree, not now, or closed without an answer) in analytics (see "Analytics" below).
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, except during the test drive (below), 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 (for example Calorie deficit or GLP-1 portions) with its targets, never your name, email, or account id.
Outside the test drive, both need an active subscription or trial and are rate-limited per account (a usage counter, not the content).
Your questions and the app's answers are not stored on our servers: each turn is answered and discarded, and the conversation exists only on your device while the panel is open.
Test drive. During setup, before you subscribe, you can open two of the restaurants in your plan preview and ask up to two questions about their menus without an account. Our server limits this with a pass sent with your preview, which holds only a random id, the restaurants it covers and when it expires (after an hour), and with daily counts per IP address (for IPv6, per network block) kept in memory. None of it is written to our database or tied to you. Questions are handled exactly like Chat above.
Menu PDFs
If you add a menu as a PDF ("Add the menu", or "Update the menu" on a restaurant's card), the file travels only inside that one request — there is no upload endpoint or storage bucket for it. Its text is read on our server and sent to Anthropic's model API to extract dish names and, where legible, prices. The current version of the app does not take menu photos; if an earlier version sends one, it is read the same way. We do not store the PDF or 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. The only thing that may be kept about you is which account sent it, as described under "Location" above.
Analytics
Eatline counts how the app is used, with PostHog, our product-analytics provider, so we can see where people get stuck, such as the step of setup where they leave. It is on in the app, and you can turn it off (see "Your rights" below).
It counts which screens are reached and which buttons are tapped, that a setup step was finished and how long you spent on it (never your answer to a setup question), whether you allowed location access, whether you allowed notifications, which of the app's reminders you opened (only which one, never what it said), whether you are signed in and how you signed in (with Apple or by email), your answer on the "Before you start" screen for Anthropic, how some steps end (for example, a purchase started, finished or was cancelled, and how many seconds Apple's payment sheet was open), and when the app is installed, updated (with the version you updated from), opened or put in the background. On the paywall it counts the plan you choose (yearly or weekly) and how a purchase ended, never a price or a receipt. When the plan step builds your plan, it records whether your location was used and, when it was, roughly how many restaurants with a read menu are within 2 km and 5 km of you, and how many of those within 2 km are not chains, as ranges (such as 5 to 19), never where you are, which restaurants they are or anything about your goal. When the map first tries to open a restaurant for you after setup, it records only whether one was opened. When you open a restaurant, it records only where in the app you opened it from (such as the list, a pin or search), never which restaurant or how its numbers are labelled. In the setup's live preview map, it records how many times you moved or zoomed the map and how many places you tapped, and for each tapped place only whether it fits your plan and whether it was the dinner picked for you, never which place. It also records when you have looked at a second different restaurant during setup, never which ones. Each time the map loads restaurants, it records roughly how many it found and how many of those have a read menu, as ranges (such as 5 to 19), never where you are. Each event carries a random id made for this install of the app, a random id for each app session, your device model and maker, screen size, the iOS version, the app's version and build number, the language and region and the time zone set on your device, and your answer to Apple's tracking prompt. Once you answer the age question in setup, each event also carries your age range (such as 25 to 34), never your age, so we can understand who uses the app. Once you have a free trial or a subscription, each event also carries whether it is a free trial or paid, whether it is set to renew, and how many days ago it started, never a price or a receipt. The random id is not your account id, and a new one is made if you delete and reinstall the app.
During setup, up to the paywall at its end, the app also records what is on the screen, as screenshots, and where you tap, so we can see where people get stuck. Recording pauses from the first setup question after your name until the location step, so it holds nothing of those questions, not even where you tapped. On the other screens, the recording shows the app's own words and images, and hides anything you type, your answers, your plan's numbers, maps, addresses and where you are. It does show how long each recorded screen was open. Recording stops when setup ends, and the rest of the app is never recorded. It is off under You > Share usage stats.
No event includes your goal, your body details (sex, exact age, height, weight, activity level), what you picked in the setup questions, anything about GLP-1, anything from Apple Health, your account id, your email, your location, a restaurant's name or identity, or anything you search for or type. PostHog is set not to keep the IP address the events come from, and not to work out a location from it.
Analytics is never used for advertising and is never shared with Singular, Meta or TikTok. PostHog hosts it in the EU (Frankfurt, Germany).
Crash reporting
When the app crashes or hits a serious error, a crash report goes to Sentry, our crash-reporting provider. It holds the error and its technical details, the app and iOS versions, your device model, and the app's last few steps before the error. Search details are removed from web addresses. Sentry may also keep the IP address the report was sent from, which can show roughly where you were.
Your account id is attached to crash reports, so a crash can be traced back to your account for debugging.
Advertising measurement
We advertise Eatline on Apple Ads, Instagram/Facebook and TikTok. Singular, a mobile measurement company, tells us which of those ads lead to installs, trials and subscriptions. There is no TikTok code in the app. The app includes Meta's software development kit (SDK), which runs only if you tap Allow (below).
When you first open Eatline, iOS asks whether you'll allow Eatline to track you. Your answer decides what reaches Meta and TikTok:
- If you tap Allow, Eatline shares your advertising ID, device details and install, onboarding, trial and subscription events with Singular, which passes them to Meta and TikTok so we can see which ads work. Meta's SDK in the app also sends Meta the fact that the app was installed and opened, with your advertising ID, device details and IP address, so Meta can measure Eatline's ads. We also tell Meta, from Meta's SDK, when you finish setting up Eatline, when you look at a second restaurant during setup and when your free trial starts (our server tells Meta instead when the trial started on an older version of the app or with a friend's code), and RevenueCat, our subscription provider, tells Meta when you pay for a subscription or renew it, so Meta can measure our ads. None of this carries your account id, name, email, goal or body details, and nothing else goes to Meta from the app.
- If you tap Ask App Not to Track, Singular still receives a device ID for this app, your IP address and in-app events so we can count installs and trials, but passes nothing to Meta or TikTok. Meta's SDK is never started, so Meta receives nothing from the app. Our ads are then measured through Apple's SKAdNetwork, which identifies no one.
Nothing in the app depends on your answer, and you can change it at any time in iOS Settings > Privacy & Security > Tracking. If you turn tracking off after allowing it, Meta's SDK sends no new events from then on (events it had already queued may still be sent) and is not started again.
The events Singular receives are: the app was installed and opened, you finished onboarding, you started a trial, and you subscribed. No event carries your name, email, goal or body details, a restaurant's identity, or a location coordinate. Your account id is attached to them, from sign-in until sign-out, which is also how our subscription provider's own purchase events line up with the right install. If you came from an Apple Ads ad, Apple tells RevenueCat and Singular which campaign, ad group and keyword it was, with nothing that identifies you.
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. See our Terms of Service for subscription plans, pricing, and cancellation.
We store your subscription's status, product, trial and renewal dates, when your free trial started, which plan it was on and when you first paid, when you first turned off auto-renew, RevenueCat's own purchaser id, and a short record of the latest update we received from RevenueCat (what happened, the product, the kind of period, the store, whether it was a test purchase, the reason for a cancellation or an expiry, and when), against your account.
We never see or handle your card details — Apple is the merchant of record.
Creator codes and referrals
If you enter a code at the paywall or under You > Have a code? — a creator's code, or a friend's — we store that code against your account, and where you entered it. When you open You > Share Eatline, we make you a personal code and keep it with your account.
For each Apple subscription that started with a code, we keep a one-way hash of the App Store transaction id (never the id itself), the code, the plan, and the dates of the free trial, the first payment and the payment that counts towards a creator's commission. We use it to pay creators for the subscriptions their code started and to give referral rewards. If a friend's first payment lands on your personal code, we record that you're owed a free month and whether you've claimed it.
A code tells its owner only a count, never who: a friend who shares their code sees how many friends have joined with it and whether a free month is ready; a creator is told how many trials and payments started with their code each month. Free weeks and months are Apple's own offers (an offer code for the friend or for someone who entered a creator's code, a promotional offer for the person who shared), redeemed through the App Store; Eatline itself unlocks nothing with a code.
When you delete your account, the code you entered, your personal code and any free months you were owed are deleted. The record of a subscription that started with a code keeps the code and its dates, so a creator's monthly count stays right, but your account id is cleared from it, so it no longer identifies you.
Third parties
| Who | What they get | Why |
|---|---|---|
| Supabase | Your account id/email and everything in this policy that's stored in our database (favourites, saved dishes, subscriptions, usage counters, claims, reports, Talk to us messages, the days you opened a menu, codes and referrals, notification tokens), and, for each signed-in session, the IP address it was started from and your device's user agent (its app and system version); its logs of the app's sign-in requests record the IP address and user agent too | Runs our database and handles sign-in |
| Railway | Every request to our own API server, and, in its request logs, the IP address and user agent each request came from | Hosts our backend |
| Google (Maps SDK, on your device) | The map area you're viewing, a device identifier, how you use the map, and crash and performance data | Draws the base map; Google's own analytics of its map SDK |
| Google (Text Search, server-side, only once a key is configured) | What you typed into a search, including the "Add a restaurant" search, and an area around your location (a circle of about 50 km) — never your account id | Finds places to add for that search — see "Location" above |
| Google (Geocoding, server-side, only once a key is configured) | What you typed into a search and the country you're searching in — never your account id | Finds the suburb or city you searched for — see "Location" above |
| Google (Place Details, server-side, only once a key is configured) | The Google id of a place you add or open — never your account id | Called to create the listing for a place you add, and again when its menu is read, to find the restaurant's own website; fetches live hours and rating when you open a place — see "Location" above |
| Anthropic | The specific menu (a link's page, a PDF's text, or a photo from an earlier version of the app) or question needed to answer one request and, for Chat and Healthify, your goal and its targets — never your name, email, or account id | Reads menus; answers in-menu chat questions; suggests order swaps |
| RevenueCat | A purchaser id, the product bought, transaction/renewal events and, if you came from an Apple Ads ad, which campaign it was | Manages your subscription entitlement |
| Sentry | Your account id plus a crash's technical details, device model, iOS version and the app's last steps before the error (search details removed from web addresses), and possibly the IP address the report was sent from | Find and fix crashes |
| PostHog | Which screens are reached and which buttons are tapped, that a setup step was finished and how long it took, whether the plan step used your location, whether your first orders were shown to you after setup, or whether a first restaurant was opened for you instead, how you used the setup's live preview map (moves, zooms and taps, and whether a tapped place fits your plan, never which place), where in the app you opened a restaurant from (never which one or its label), whether you allowed location access and notifications, whether you are signed in and how, the plan you choose on the paywall (yearly or weekly), how a purchase ended and how long Apple's payment sheet was open (never a price or receipt), roughly how many restaurants the map found and how many have a read menu (ranges), roughly how many restaurants with a read menu are near you during setup (ranges), whether you looked at a second restaurant during setup, whether you are on a free trial or a paid plan, whether it renews and how many days in, and when the app is installed or updated (with the version you updated from), with a random id for this install, a random id for each app session, your device model and maker, screen size, the iOS version, the app's version and build number, your language and region, time zone, your answer to Apple's tracking prompt, and your age range (see "Analytics" above); during setup only, and paused for the setup questions after your name, screenshots of the screen and where you tap, showing the app's own words and images and hiding anything you type, your answers, your plan's numbers, maps, addresses and where you are — never your goal, exact age or other body details, what you picked in the setup questions, GLP-1 or Apple Health data, account id, email or location. Hosted in the EU (Germany); off under You > Share usage stats | Shows us where people get stuck in the app; never used for advertising |
| Singular | A device ID for this app, your IP address, device details and the events named under "Advertising measurement" above, with your account id attached; your advertising ID only if you tap Allow | Tells us which ads lead to installs, trials and subscriptions; passes data to Meta and TikTok only if you tap Allow |
| Meta (Facebook/Instagram) and TikTok | Only if you tap Allow: your advertising ID, device details and install, onboarding, trial and subscription events, through Singular; and, for Meta, install, app-open and finished-setup events, that you looked at a second restaurant during setup, and the start of your free trial, with your advertising ID, device details and IP address, from Meta's SDK in the app (the start of your free trial from our server instead when it started on an older version of the app or with a friend's code), and your subscription payments and renewals from RevenueCat | Measure and improve Eatline's ads |
| Resend | For a listing claim: the restaurant, your role, contact email, website and note. For a menu submission: the restaurant, the link or text and your note. For a Talk to us message: the message, your reply address if you gave one, the app version, iOS version, device model, App Store country, goal, screen, the restaurant when you came from one that failed, and your account id if you have one — never your location or health data | Sends each one as an email to our team's inbox |
| Microsoft (Microsoft 365) | Those emails, and anything you write to hello@eatline.app | Hosts our email inbox |
| Apple (App Store) | Your payment method, handled entirely by Apple | Processes payment; hosts the app |
| Apple (push notifications) | This device's notification token, and each menu notification's words (which name the restaurant) with our id for that restaurant — never your account id, email or location | Delivers the notifications you allowed — see "Notifications" above |
Retention
| What | How long |
|---|---|
| Account, favourites, saved dishes, subscriptions, usage counters, claims, owner-menu submissions, add-a-restaurant requests, hours/rating lookup records, menu reports | Until you delete your account, then removed in one step |
Talk to us messages (support_messages) | Sent with an account: until you delete your account. Sent while signed out: until you ask us to delete it |
| The email of a Talk to us message (our hello@eatline.app inbox, and Resend's record of sending it) | Kept in our inbox until you ask us to delete it, even after you delete your account; Resend's record is kept under Resend's retention settings |
The days you opened a restaurant's menu (menu_open_days) | 90 days, and deleted sooner with your account |
Your notification token (push_tokens) | Until you sign out on that device (when it can reach us then), another account signs in on it, Apple tells us the token no longer works, or you delete your account |
The menu notifications we've sent you (menu_ready_notices: which restaurant, whether the menu was ready or not found, when) | Until you delete your account |
The code you entered (code_entries), your personal code (codes) and free months you're owed (referral_rewards) | Until you delete your account |
A subscription that started with a code (code_starts: the hashed transaction id, the code and its dates) | Kept for creator payments; your account id on it is cleared, not the row, when you delete your account |
| Your purchase record at RevenueCat | Deleted when you delete your account |
| An account made when you buy or restore a subscription without signing in (it has no email; your purchase and anything you save sit under it) | Until you delete it with You > Delete my data, or until it has gone 30 days unused with no live subscription (active, in a free trial, paused or in a billing retry), when we delete it and everything under it |
| Your goal profile, chat questions and answers, Healthify requests | Not stored on our servers — profile stays on your device; chat and Healthify are answered and discarded |
| Test-drive pass and its counts, in our server's memory | Deleted within a minute of the pass expiring (an hour after your preview); the per-IP daily counts within a minute of the day ending (UTC); never written to our database |
Map-pin taps (poi_taps) | Kept indefinitely for coverage planning; your account id is cleared, not the row, when you delete your account |
| Live hours and rating from Google when you open a place | Not stored beyond the single request that needed it — see "Location" above |
| A search sent to Google Text Search (the words, the area rounded to about 1 km, Google's answer) | Kept in our server's memory for up to 24 hours, never tied to your account or written to our database |
A search sent to Google Geocoding (the words you searched and the suburbs or cities Google matched to them, in geocode_cache) | Kept in our database, never tied to your account. An answer older than 30 days is no longer used, and can be replaced the next time the same words are searched; we don't currently delete old rows |
| A menu PDF you add (or a photo sent from an earlier version of the app) | Not stored at all |
Which account sent a menu (menus.submitted_by), where we record it | Until you delete your account; the menu itself stays, and its link to your account is removed |
| The email of a listing claim or a menu submission (our hello@eatline.app inbox, and Resend's record of sending it) | Kept in our inbox until you ask us to delete it, even after you delete your account; Resend's record is kept under Resend's retention settings |
| Each signed-in session's IP address and user agent (at Supabase) | Until that session is signed out; a session left behind on a device, until your account is deleted |
| Supabase's logs of the app's sign-in requests (the IP address and user agent, and on some entries your account id and email) | 7 days, under Supabase's log retention for our plan, including after you delete your account |
| The IP address and user agent of each request to our API, in Railway's request logs | Available to us for 30 days, under Railway's log retention for our plan, including after you delete your account; Railway holds them under its own retention policy |
| The IP address a request to our API comes from, in our server's memory | Used only to rate-limit requests: dropped after about 10 minutes without a request (a daily count for signed-out requests is cleared after the day ends, UTC), never written to our database |
| Crash reports (Sentry) | Held under our Sentry project's retention settings, then deleted |
| Analytics (PostHog) | Kept for our PostHog plan's retention period: 1 year on PostHog's free plan, 7 years on its paid plans. Setup recordings are kept for the recording retention set in our PostHog project: at most 30 days on PostHog's free plan and 90 days on its pay-as-you-go plan. It carries no account id, so deleting your account cannot find it; turning off You > Share usage stats stops anything new being sent |
| Ad-measurement data at Singular | Held under Singular's retention settings; we ask Singular to erase what it holds under your account when you delete your account |
| Install, app-open, finished-setup, trial and subscription events at Meta (only if you tap Allow) | Held under Meta's own retention. We never send Meta your account id, so deleting your account cannot find them there. To see or remove what Meta received from Eatline, use Accounts Center on Facebook or Instagram (Your information and permissions > Your activity off Meta technologies), or write to hello@eatline.app and we will pass your request to Meta |
Age and children
Eatline's App Store rating is 13+. To create an account you must be able to form a binding contract in your country, or have a parent or guardian's consent. Eatline is not directed at children under 13.
Your rights
You can see and change your goal profile in the app: your goal and details (sex, age, height, weight, activity level and, for GLP-1 portions, how your appetite is running) under You > Update my plan, and your goal also from the goal button on the Map, Plan and Saved tabs. You can delete your whole account — and everything under it — from You > Delete account, with the exceptions listed under Retention above, such as map-pin taps and the email of a listing claim or a menu submission.
You can switch Ask, Healthify and menu reading off at any time under You > AI features (Anthropic). While it is off, nothing is sent to Anthropic, and each of them asks your permission again before it sends anything.
You can turn analytics off at any time under You > Share usage stats. From then on the app sends nothing to PostHog, not even that it was opened, and events not yet sent are dropped; a batch already on its way when you turn it off may still arrive. It stays off after you restart the app, until you turn it back on.
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
The restaurant sheet, the Plan tab and every Healthify/Chat answer carry this line, verbatim, from the code:
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.
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
Trela Studios Pty Ltd, Australia. Email: hello@eatline.app.