PrepCart privacy
This is written in plain English and describes exactly what the code does. We store the minimum needed to plan your week, fill your cart and email you about it. Your data is never sold, and never used to decide anything about your health: the service gives no medical, dietary or dietitian advice.
What is stored, and where
In your browser (chrome.storage.local, only on the computer where the extension is installed, never synced):
| Key | What |
|---|---|
profile | your household as you described it: each person's name, age, sex, height, weight, activity, goal and daily targets, how strict they are, allergies and foods to avoid, what they eat outside the plan, breakfast and snack choices, your cooking equipment, your cook-up schedule (which days you cook and who they feed), the day your week starts, and any changes you made for a particular week |
chat | the conversation that built the profile |
plan | the current week: the plan, its outline and cook sessions, pantry ticks, the plan's id, whether you approved it, and the history of swaps |
account | your sign-in session token, email, first name, role and household |
installId | a random id for this install, used to rate-limit sign-in codes |
site, stores | the website address and a cached copy of the store configuration and store health, so the cart feature knows what the supermarket's pages look like |
micHintShown, tip and voice flags | whether you have seen a hint and whether spoken replies are on |
Signing in on the website sets one cookie, pc_session, holding your session; it is HttpOnly and lasts 90 days or until you sign out. The website also keeps one value in localStorage, pc_consent: whether you accepted or declined the cookie banner (see Meta, below).
On the PrepCart server (Postgres on Vercel; the schema is in server/sql/):
| Table | What | Why |
|---|---|---|
users | email address, first name, country, timezone, email preferences, your Google account id (sub) if you sign in with Google, and onboarding_prefill: if you arrived from the macro calculator, the targets and stats you typed there (goal, sex, age, height, weight, activity, training days), so onboarding can start from them | sign-in, pricing by country, cook-day emails at the right hour |
households, household_members | who shares a plan: the owner, the one other adult they invited, and the brand the household bought from | one subscription, two sign-ins; the brand drives theme, tone and emails |
subscriptions | Stripe customer and subscription ids, status, currency, renewal date | the paywall; no card numbers ever reach PrepCart |
plans | the week's plan, one row per household and week: the recipes, cook sessions and schedule, the shopping list, the weekly budget and currency, whether there are kids, each adult's daily calorie and protein target, and the portions: each person's name, how strict they are, serves and grams per meal, breakfast and snack extras, top-ups and what they eat outside the plan | the proposal and cook-day emails, and the portions the extension shows |
email_log | which email went to whom, for which plan and session | so nothing is sent twice |
login_codes, sessions | hashed sign-in codes (with the install id that asked), hashed session tokens | sign-in without passwords |
invites, invite_log | the invited address, their first name and which person in the plan they are, the hashed invitation code, when it was sent and how many times; invite_log keeps a count of invitation emails per household for the last 30 days | the one invitation each account can send, and the cap on invitation emails |
google_signins | email, install id and time of each Google sign-in | rate-limiting sign-ins |
stripe_events, resend_events | Stripe and Resend event ids | so a retried webhook is a no-op |
waitlist | email, country and brand of people who asked to be told (outside the countries on sale) | to tell them when it reaches them |
billing_reviews | a note, with the email, when a card's country differs from the price charged | a human looks; nothing is cancelled automatically |
cart_runs | your household's current cart run: the store, which step it is up to, each item's name and whether it is in the cart yet, start and update times; replaced by the next run | so a run that was interrupted can carry on where it stopped |
product_matches | for each store and search term, which product was chosen and how often it was swapped; no household | better product matches over time |
recipe_feedback | when a recipe is swapped or kept: a fingerprint and name of the recipe, the household's profile tags (such as "vegetarian" or "no fish"), the reason you gave, the brand and the household id | better recipes over time |
store_runs, store_health | anonymous cart-run outcomes: store, config version, step, ok or not, the failing selector key; no user, product or account data | to notice when a supermarket changes its site and show you the list instead |
store_diagnostics | sanitised Diagnostics captures you choose to send (page structure, product names, prices and sizes only; never account, cart or Rewards data), kept while a store is failing | so the selectors can be fixed quickly |
recipes | the public recipe library on the website; no user data | the recipe pages |
email_suppressions | a hash of each address that bounced, complained, or asked not to be invited, with the reason and time; never the address itself | so we never email it again |
quality_runs, quality_profiles | the founders' test runs of the planner on made-up households; the id of the founder who started one | checking plan quality; no customer data |
Sign-in codes, session tokens and invitation codes are stored only as salted SHA-256 hashes. Codes expire after 10 minutes and allow 5 attempts.
Not stored on the server: your chat, your household profile as a whole (it stays in your browser; the server receives it only while planning your week and matching products, and keeps of it what the plan row above lists), voice audio (Chrome's speech service handles that in the browser), your supermarket credentials, your supermarket cart or anything from your supermarket account.
Who else sees data
- Anthropic (Claude) receives the conversation, profile and plan context needed to answer, and product candidates for cart matching. Keys live only in the server's environment.
- Google, if you choose Continue with Google: Google tells PrepCart your verified email address, your name and a Google account id, nothing else; PrepCart never receives a Google access token and cannot read anything in your Google account.
- Stripe handles payment. PrepCart receives the customer id, subscription status and currency, never card details. Stripe's customer portal (Manage billing on your account page) is where you update your card, see invoices and cancel.
- Resend sends the emails: sign-in codes, invitations, the weekly proposal and cook-day recipes. Resend tells us when an email bounces or is marked as spam, and we stop emailing that address.
- Meta (Facebook and Instagram ads), only when the operator has turned it on (
META_PIXEL_ID) and only if you accept the cookie banner: the website asks once, declined by default, and remembers your choice in your browser; "Cookie settings" in the footer changes it. After you accept, the website's pages load the Meta Pixel, which records a page view, a recipe or calculator view, landing on the sign-up page, an account being created and a subscription starting (the amount and currency, and an id so a reloaded page counts once). The pixel sets Meta's own cookies in your browser; that is the only identifier Meta gets. No email, name, phone number, address, plan, chat or household data is ever sent to Meta, from the browser or from our server: our server never contacts Meta at all. The extension, your account page and the admin pages never load the pixel. Decline, and nothing from Meta loads. - Woolworths and Coles: the cart feature acts in your own signed-in tab, at human pace, and never touches checkout, payment, address or account settings. PrepCart's server never visits a supermarket site.
Logs
Server logs record durations, status codes and error types. They never contain email bodies, sign-in codes, tokens, API keys or your messages.
Emails
Every email names the sender and links to a settings page where you can turn emails off without signing in. Turning emails off stops the weekly proposal and the cook-day emails; sign-in codes still arrive when you ask for one. An address that bounces or marks us as spam is put on the suppression list (hashed) and gets nothing more, sign-in codes included; the account page says so and how to reach us.
Deleting your data
Settings → Delete my account removes your user record, sessions, codes and invitations. For a household owner it also removes the household, its plans, the cart run, the email log and cancels the Stripe subscription; the other adult loses access at the same time. The browser copy is cleared by removing the extension (or from Settings on delete). Product-match and recipe-feedback rows carry no name or email and stay as counts.