Last updated: 3 August 2026

Privacy Policy

This policy explains how FoodCore.io Ltd collects, uses and stores personal data in connection with our kitchen management software. It covers two different things: the data we hold about you as an account holder, and the data your business puts into FoodCore about your customers and staff. Those two are treated differently in law, and this policy is written to meet our obligations under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

What changed in this update — 3 August 2026

In plain English, here is what is new since the 22 July version:

  • We have corrected what we said about our AI provider. The 22 July version implied that scanning a receipt could send your customers' details to Anthropic. That was wider than the feature is. The photographs it handles are supplier purchase documents — the receipt or delivery note for stock you buy in — not your own customers' receipts. Neither AI feature sends your customer records. See section 4.
  • We have added a security section, because we can now say something true about backups. Backups are encrypted, taken daily, and kept both locally and off site. That section also gathers the specific controls already in place. See section 10. Uploaded images are still not included in backups.
  • We have described the shop import more accurately. Only orders come in from Shopify or WooCommerce, and an order carries contact and address details, so buyers are matched on that — not on a name alone. See section 3.9.
  • Sections have been renumbered from 10 onwards to make room for the new security section. Nothing in them changed.

Still current from the 22 July update:

  • What “delete” does. Deleting a customer in the app marks them inactive; it does not erase them. Receipts are voided, never deleted. A real erasure has to be asked for. See section 15.
  • Version history has no retention limit. The record of who changed what is currently kept indefinitely. We would rather say so than invent a number. See section 16.
  • Recipe photos are reachable by anyone holding the link. The web addresses are long and unguessable, but they are not secret and there is no password check on the image itself. See section 3.7.
  • The full list of sub-processors — including Stripe Connect, Google Calendar, Shopify/WooCommerce and Resend — is on our Sub-processors page.

1. Who We Are — and When We Are a “Controller” vs a “Processor”

FoodCore.io Ltd (FOODCORE.IO LIMITED), company number 17168660, VAT number [VAT number TBC], registered in England and Wales, 66 Paul Street, London EC2A 4NA.

Two words come up throughout this policy, so here they are in plain English:

  • Controller — the business that decides why personal data is held and what is done with it. The controller carries the legal responsibility for it.
  • Processor — a business that handles that data on the controller's instructions, and does not get to decide what it is used for.

FoodCore wears both hats, depending on whose data we are talking about:

Data Who is the controller? FoodCore's role
Your own account — your name, your business, your billing details, your support emails, this website's visitor data FoodCore.io Ltd Controller. Covered by section 2.
Everything you put into FoodCore about other people — your customers, your staff, your orders, your rota You (the subscribing business) Processor. We hold and process it on your instructions. Covered by section 3.

This matters practically. Where you are the controller, the legal duties sit with you: deciding what you are allowed to record, telling your customers and staff what you hold about them, and answering their requests. We help you carry that out — we do not carry it for you. Each subscriber gets their own private instance of FoodCore; we do not pool your data with another business's.

The other companies we use to run the service (our “sub-processors” — suppliers who handle data on our behalf) are listed in section 11 and, in full, on our Sub-processors page.

For all data protection queries or Subject Access Requests, contact us at info@foodcore.io with the subject line "Data Protection" or "Subject Access Request".

2. What We Collect About You (Where We Are the Controller)

This section is about you — the person or business holding a FoodCore account, or browsing this website. What you put into the app about other people is section 3.

Data you provide directly as a subscriber:

  • Account registration: name, business name, email address, phone number.
  • Billing: name and address for invoicing. Payment card details are processed entirely by Stripe — we do not store them.
  • Communications: information you provide when contacting us by email, contact form, or live chat.
  • Trial requests: name, business name, and email address — used solely to set up your trial account.
  • Newsletter signup: email address, collected via our signup form on foodcore.io. Managed through Sender.net (account ID: ad6083267e6001). Used solely for marketing communications you have opted into.

Usage and technical data: IP addresses, browser type, pages accessed, session duration, click and scroll behaviour. Collected automatically when you visit our website. Website usage analytics are collected by Google Analytics 4 (property ID: G-EJJZYBXJYE) and PostHog (visitor analytics, session recordings, and heatmaps — EU-hosted) with your consent. PostHog may record screen activity during your visit in the form of a session replay to help us understand how visitors interact with our website and identify usability improvements. No payment card data or account passwords are ever captured in recordings.

AI features: what is sent to our AI provider, and what that can contain, is set out separately in section 4.

Affiliate partner data: if you apply to or participate in our affiliate programme, we collect your name, business or trading name, email address, payment details (for commission payments), and referral performance data. This data is processed via Endorsely (our affiliate platform) and by us to administer the programme and pay commissions.

3. What We Process On Your Behalf (Where You Are the Controller)

Everything in this section is data your business puts into FoodCore about other people. You decide what goes in and why. We hold it, and only do things with it that the app does on your instruction. We do not use it to market to anyone, we do not sell it, and we do not mix it with another subscriber's data.

What this means for you

Because you are the controller for this data, the duty to tell your customers and staff what you hold about them — and to answer them when they ask — is yours, not ours. If you record dietary or allergy information, or you keep staff rotas and edit history, you will need your own privacy notice covering it. This section is written so you can see exactly what is in the app and describe it accurately.

3.1 Customer records

For each customer you add, FoodCore can hold: name, email address, phone number, postal address, birthday (optional), free-text notes, tags you apply, a “how they found you” marketing attribution field, and the customer's linked order history.

Contact details used to be copied onto every single order. They are now stored once on the customer record and referenced by the orders instead. That is a genuine improvement: the same phone number is no longer duplicated across dozens of rows, correcting it in one place corrects it everywhere, and there is less personal data lying around than there used to be.

3.2 Dietary and allergen flags on a customer

A customer record has an optional field for dietary requirements and allergens. It is up to you whether you fill it in.

A note that a named person has, say, a nut allergy or is coeliac may amount to health data — what UK GDPR Article 9 calls a “special category” of personal data. Special category data is held to a higher standard than ordinary contact details: recording it lawfully needs more than the usual justification. If you use this field, this is something to work through for your own business, and it is worth taking advice on.

Factually, here is how the field behaves today: it is stored for reference only, so that whoever is preparing the order can see it. Orders are not automatically checked against it. FoodCore will not warn you, block an order, or cross-reference the flag against a recipe's allergens. It is a note to a human being, not a safety control.

3.3 Marketing and SMS consent

Marketing consent and SMS consent are stored as two separate flags per customer, one per channel, and each carries its own timestamp recording when it was set.

  • Both default to off. A new customer is not opted in to anything.
  • Consent is never inferred. Placing an order, giving you a phone number, or being imported from your online shop does not switch either flag on. Someone has to set it deliberately.
  • Agreeing to email does not agree to texts, and vice versa — they are genuinely independent.
  • The timestamp records when permission was actually given. Editing a customer's address or adding a note later does not refresh it, so it stays a truthful record of when you got permission rather than when the row was last touched.

Withdrawing consent: open the customer record and switch the relevant flag off — that takes effect immediately for that channel. A customer who asks you directly to stop should be actioned this way. If a customer contacts FoodCore rather than you, we will pass the request to you, because it is your record to change.

3.4 Staff working patterns (rota and shifts)

If you use the rota, FoodCore holds for each shift: the date, start and end time, the position worked, the site, free-text notes, and an optional hourly rate stored against that shift.

This is employee data, and you are the controller for it. Telling your staff what you record about their hours and pay, and on what basis, is your responsibility as their employer — not FoodCore's. We hold it for you; we do not have an employment relationship with your team.

3.5 Who edited what — version history

Every change to a recipe or an ingredient is attributed to the named person who made it. That attribution is now visible inside the product, in a “Version history” drawer, to anyone with read access to that record — not only to an administrator.

We are going to name this for what it is: this is employee monitoring in the ordinary sense of the phrase. It exists for good reasons — food safety traceability and being able to see who changed an allergen declaration and when — but a member of staff can see that a colleague changed a recipe at a particular time, and their employer can too. If you use FoodCore, you should cover this in your own staff privacy notice. Do not assume your team already knows.

3.6 Photographs of delivery notes and supplier receipts

You can photograph a supplier purchase receipt or delivery note — the paperwork for stock your business buys in — and have FoodCore read the lines into stock. These are business-to-business purchase documents, not your own customers' receipts. Such a document normally shows your business details, and occasionally the name of the person who signed for the delivery. They are sent to our AI provider to be read; see section 4 for exactly what that involves.

  • The image is deleted as soon as the scan is resolved — whether you apply it, discard it, or it fails.
  • A backstop sweep removes scan images that were never reviewed (default: after 30 days), so a forgotten scan does not sit there forever.
  • They are stored in a private directory and are never served as static files. Only an authenticated request — one carrying a valid login — can read one.
  • Only ordinary raster photographs are accepted (JPEG, PNG and similar). The file type is verified by inspecting the file's own contents rather than trusting its name, and SVG files are rejected outright.

3.7 Recipe photographs

You can upload photographs to recipes. This is user-generated content and it may contain people — a chef in shot, a customer at an event.

Every upload is re-encoded on our server before it is stored. That strips all EXIF metadata, including GPS coordinates, and the original file is never kept. So a photo taken on a phone in your kitchen does not carry your kitchen's location with it. Images are also served with headers that force the browser to download the file rather than run anything in it.

Please read this one — recipe images are not password-protected

A recipe image is reachable by anyone who has its web address. The addresses are long and effectively unguessable, so nobody will stumble across one — but they are not secret, and there is no per-request login check on the image itself. This is a real limitation, not a technicality: a browser's <img> tag cannot carry a login token, so the image loads without one. If you paste an image link into a message, forward it, or share it in a group chat, whoever holds that link can open the picture without logging in to FoodCore. Treat recipe photo links as shareable, and do not upload anything to a recipe photo that you would not be willing for a link-holder to see.

One further thing worth knowing: uploaded images are not included in our database backups. Your recipe text, costings and records are backed up; the photographs attached to them are not. If an image is lost, it cannot be restored from a backup.

3.8 Orders, payments and receipts

FoodCore holds your order records, including deposits taken and balances outstanding, and the receipts issued against them.

Receipts work differently from the rest of the app, and it is worth understanding why. A receipt stores a snapshot of the customer's name, email, phone and address exactly as they were on the day it was issued. That is deliberate — reprinting a receipt from eight months ago should show what it showed at the time, not what the customer's details happen to be now. A receipt that silently rewrote itself would not be much of a record.

The consequence is that customer details exist in a second place. Editing or deleting the customer record does not reach back into receipts already issued. Any deletion request has to account for both. See section 15.

3.9 Buyers imported from Shopify or WooCommerce

If you connect your Shopify or WooCommerce storefront, orders arrive in FoodCore carrying the buyer's name, email address, phone number and delivery address. Fulfilment status flows back out to the shop, so the connection runs in both directions.

Two things about this deserve to be said plainly. First, the buyer gave those details to your shop, not to FoodCore — they may have no idea FoodCore exists. Your own storefront privacy notice should mention that order data is passed to a kitchen management system.

Second, imported buyers are matched into the same customer record as your walk-in and phone orders. Only orders are brought in, and an order carries the buyer's contact and address details, so the match is made on that combination rather than on a name alone. A person who orders online in March and phones up in June ends up as one profile, not two. That is convenient, and it is also a merge: data collected in different places, at different times, under different notices, ends up combined into a single record with a single order history. That combined profile is yours to justify.

4. AI Features — What Is Sent to Anthropic

FoodCore uses Anthropic, PBC (the Claude API) for two features, and nothing is sent unless you use one of them. There are two paths: AI Checks, which send structured recipe and ingredient text, and receipt scanning, which sends a photograph of a supplier purchase receipt or delivery note. Neither path sends your customer records to Anthropic.

A clarification to our previous policy

Our 22 July update described receipt scanning more widely than the feature actually is, and we are putting that right here. The photographs this feature handles are supplier purchase documents — the receipt or delivery note for stock your business buys in — not your own customers' receipts. Your customer data is not sent to Anthropic by either feature.

4.1 AI Checks (recipe and ingredient text)

When you run an AI Check, structured recipe and ingredient data is sent: recipe names, ingredients, quantities, allergen flags and nutritional values. This is structured product data pulled from named fields, so it does not contain your customers' personal details. Note that a recipe title or an ingredient note is free text you control — if you type a customer's name into a recipe name, it will be sent along with the rest.

4.2 Supplier receipt and delivery-note scanning (photographs)

When you photograph a supplier purchase receipt or delivery note so FoodCore can read the lines into stock, the photograph itself is sent to Anthropic. These are the documents that come with stock you buy in — from a supplier, a wholesaler or a cash-and-carry. They are not your own customers' receipts, and no customer record is attached to the scan.

A supplier document is a business-to-business purchase record: what you bought, from whom, at what price. It will normally show your own business name and delivery address, and occasionally the name of whoever signed for the delivery.

The image itself is handled tightly: it is deleted as soon as the scan is resolved — whether you apply it, discard it, or it fails — and a backstop sweep removes scan images that were never reviewed (default: after 30 days). While it exists it sits in a private directory and is never served as a static file; only an authenticated request — one carrying a valid login — can read one.

We read stock lines and prices, and we do not extract anything else into your records. If a particular document has something on it you would rather not send, do not scan it; type the delivery in by hand instead.

4.3 What Anthropic does with it

Anthropic's API terms provide that inputs submitted through the API are not used to train their models. Anthropic is based in the United States; that transfer is covered in section 17. Their handling is described in Anthropic's privacy policy.

Both features are optional. Every other part of FoodCore works with no AI processing at all — see section 20.

5. How We Use Your Data

The table below covers our own processing as controller — the data in section 2. It does not set out lawful bases for the data you hold about your customers and staff under section 3; you are the controller for that, so those decisions are yours.

Purpose Lawful basis (UK GDPR Art. 6)
Providing the subscribed service (account management, billing, support)Contract performance — Art. 6(1)(b)
Processing subscription payments via StripeContract performance — Art. 6(1)(b)
Retaining financial and billing recordsLegal obligation (HMRC) — Art. 6(1)(c)
Security monitoring and fraud preventionLegitimate interests — Art. 6(1)(f)
Product improvement (anonymised analytics)Legitimate interests — Art. 6(1)(f)
Website analytics via Google Analytics 4Consent — Art. 6(1)(a) (withdraw via cookie settings)
Visitor analytics, session recording, and heatmaps via PostHogConsent — Art. 6(1)(a) (withdraw via cookie settings)
Affiliate programme administration and commission paymentsContract performance / legitimate interests — Art. 6(1)(b)/(f)
Marketing emails via Sender.net (newsletter subscribers)Consent — Art. 6(1)(a) (unsubscribe any time)
AI compliance analysis via Anthropic Claude API (AI Checks feature)Contract performance / legitimate interests — Art. 6(1)(b)/(f)
Live chat support via Tawk.toConsent / legitimate interests — Art. 6(1)(a)/(f)

We do not sell your personal data to any third party. We do not use your data for advertising profiling.

6. Legal Basis for Processing

We rely on the following lawful bases under UK GDPR Article 6:

  • Contract performance (Art. 6(1)(b)): processing necessary to deliver the service you have subscribed to, including account management, billing, and service communications.
  • Legal obligation (Art. 6(1)(c)): retaining financial records as required by HMRC and applicable law.
  • Legitimate interests (Art. 6(1)(f)): security monitoring, fraud prevention, and anonymised product analytics — balanced against your interests and rights.
  • Consent (Art. 6(1)(a)): analytics cookies (Google Analytics 4), visitor session recording and heatmaps (PostHog), marketing emails (Sender.net), and live chat (Tawk.to). You may withdraw consent at any time without affecting the lawfulness of prior processing.

7. Who Can See What — Access Control Inside Your Account

Customer records are gated by the role you give each user:

  • Admin, manager, chef and front-of-house can view and edit customer records.
  • Dietitian and viewer roles are read-only — they can see customer records but cannot change them.

If you run more than one site, a user can be pinned to a single site. A site-pinned user cannot read or create customer records belonging to any other site. So a member of staff at your Leeds shop does not see the Manchester shop's customers.

These limits are applied on our server, from the user's login token — not from anything the browser sends. In practice that means the restriction is not something a user can get around by editing what their device asks for; the server decides what that login is entitled to see, and ignores the request's own claims about who it is.

8. Offline Mode — What Is Never Stored on the Device

FoodCore works offline in the kitchen, but it deliberately caches only what is needed to cook and label: recipes, ingredients and label templates.

Customers, orders, receipts, the staff rota and scanned receipt images are never stored on the device. This is a deliberate design choice rather than a limitation. A tablet left on a counter, lost on a delivery run or stolen from a van exposes no customer personal data — whoever has it can see your recipes, and that is all.

9. Card Details

FoodCore never collects, transmits or stores card details. All card entry happens on payment pages hosted by Stripe. No card field is rendered on any FoodCore page — neither for your own subscription, nor for your customers paying you. Card numbers never touch our systems, so they cannot be exposed by them.

10. Security — What Actually Protects Your Data

This section lists the measures that are genuinely in place. We have kept it to things we can stand behind rather than a page of reassurance.

10.1 Backups

Backups are encrypted. They are taken daily and held in two places — locally and externally, off site — so a single failure at one location does not take your records with it.

One limitation is worth repeating from section 3.7: uploaded images are not included in our database backups. Your recipe text, costings and records are backed up; the photographs attached to them are not, and a lost image cannot be restored from a backup.

10.2 The specific controls in place

  • Access control is decided on our server. What a user is entitled to see is worked out from their login token on our side, not from anything the browser claims — including the site pinning that keeps one site's staff out of another site's customer records (section 7).
  • Uploaded photographs are stripped of metadata. Every image is re-encoded on the server before it is stored, which removes all EXIF data including GPS coordinates, and the original file is not kept (section 3.7).
  • Uploaded files are checked by content, not by filename. The file type is verified by inspecting the file's own bytes rather than trusting its extension, and SVG files are rejected outright.
  • Scanned supplier receipt images are held privately. They are never served as static files, only an authenticated request can read one, and they are deleted once the scan is applied, discarded or fails (section 4.2).
  • Calendar subscription links are stored hashed — the stored value cannot be turned back into the link — and can be revoked and regenerated at any time (section 12.2).
  • The Google refresh token is encrypted at rest with a key unique to your instance, and no FoodCore API will hand it back out (section 12.1).
  • Card details never reach us at all. Card entry happens only on Stripe-hosted pages; no card field is rendered on any FoodCore page, so card numbers cannot be exposed by our systems (section 9).

Two things we are not claiming. Recipe photograph links are long and unguessable but they are not secret — there is no login check on the image itself, as set out in section 3.7. And no set of measures makes a system impossible to breach; this section describes what is in place, not a guarantee.

11. Sub-processors (Companies That Handle Data For Us)

A sub-processor is a supplier who handles data on our behalf so we can run the service — for example the company that sends our emails. We share data with them only to the extent necessary to operate the Service. We will notify you at least 14 days before making any material change to this list.

The table below is the full current list. A standalone version, kept up to date, is on our Sub-processors page.

Service Purpose Data shared Location / transfer basis
Google Analytics 4
ID: G-EJJZYBXJYE
Website usage analytics Anonymised usage data; no personal data from customer accounts. Consent-gated. US — Standard Contractual Clauses (SCCs) in place
Google Ads
ID: AW-724508800
Conversion tracking for website advertising Conversion events (e.g. trial sign-ups). No account data transmitted. US — SCCs in place
PostHog
EU cloud — eu.i.posthog.com
Visitor analytics, session recording (screen replay), and heatmaps Anonymised usage data; session recordings of visitor interactions with our website; heatmap data. No personal account data, passwords, or payment details are captured. Consent-gated. EU-hosted — no international transfer
Endorsely Affiliate link management — may inject product recommendations into blog page content Affiliate click data (anonymised). No personal account data shared. EU / EEA
Sender.net
Account: ad6083267e6001
Email marketing and newsletter distribution Email addresses of newsletter subscribers only (consent-based). EU-based
Resend Transactional email from the app; and adds opted-in free-tool users to our marketing audience and sends the welcome email Recipient email address and the contents of the message being sent. Also the email address of visitors who tick the optional marketing opt-in on a free tool (consent-based). US — Standard Contractual Clauses (SCCs) in place
Tawk.to Live chat widget — loads on all pages Chat transcripts and any information you volunteer in a chat session. May collect IP address and browser data. US / global — SCCs in place
Stripe Your FoodCore subscription billing; and, via Stripe Connect, taking payments from your own customers where you connect your own Stripe account Billing name and address for your subscription. Where you connect your own Stripe account, your customers' payment data goes to Stripe under your Stripe agreement. Card data is handled entirely by Stripe on Stripe-hosted pages — we never receive or store card numbers. US-headquartered — Standard Contractual Clauses (SCCs) in place
Anthropic
Claude API
AI Checks compliance analysis; and reading photographed supplier purchase receipts and delivery notes into stock AI Checks: recipe names, ingredients, quantities, allergen flags, nutritional values.
Receipt scanning: a photograph of a supplier purchase receipt or delivery note — a business-to-business purchase document, which normally shows your own business details and occasionally the name of whoever signed for a delivery.
Neither sends your customer records (see section 4). Anthropic's API terms provide that inputs are not used to train their models.
US — Standard Contractual Clauses (SCCs) in place
Web3Forms Delivers submissions from our website forms (contact form and free-tool email requests) to our inbox The details you enter in a form — e.g. name, email address, message, and (for free tools) the result you asked us to email you. No account or payment data. US — SCCs in place
Cloudflare CDN, DDoS protection, and performance optimisation Technical identifiers, IP addresses. No personal account data. US / global — SCCs in place
Google
Calendar API
Putting staff shifts into a Google calendar — only where an individual user connects their own Google account Staff shift data. Nothing is sent unless a user connects their own calendar. See section 12. US-headquartered — SCCs in place
Shopify / WooCommerce Two-way sync with your own online shop, where you connect one — orders in, fulfilment status out Inbound: buyer name, email, phone, delivery address and order lines. Outbound: fulfilment status. See section 3.9. Shopify: US — SCCs in place. WooCommerce: runs on your own hosting, wherever you host it.
Hosting / infrastructure provider Runs the servers and database on which FoodCore operates All data held in FoodCore, at rest — your account data and everything in section 3. Details available on request to info@foodcore.io.

We do not currently use any SMS or WhatsApp messaging provider. If that changes, we will add it to this list and notify you before it takes effect.

12. Calendar Connections

12.1 Connecting a Google calendar

An individual user can connect their own Google account so their shifts appear in Google Calendar. Nothing is sent to Google unless someone does this.

  • We ask Google for the narrowest permission available. The scope we request is calendar.app.created, which grants access only to a calendar FoodCore itself creates. FoodCore cannot read, edit or delete your existing calendars — not your personal diary, not your work calendar. We could not see them if we wanted to.
  • Google's Limited Use requirements apply. Data obtained through this connection is not used for advertising, is not sold, and is not used to train models — ours or anyone else's.
  • The connection key is protected. The refresh token Google issues is encrypted at rest with a key unique to your instance, and is never returned by any FoodCore API — there is no request that will hand it back out.
  • Disconnecting really disconnects. When a user disconnects, or an account is deactivated, we revoke the token both in our own records and with Google, so the permission stops existing at Google's end too.

12.2 Subscription calendar links (Apple Calendar, Outlook)

For calendar apps that subscribe to a link, FoodCore issues a long web address you paste into the app.

The link is the password

There is no separate login on a subscription link — anyone holding the address can read that calendar. Do not post one in a group chat or a shared document you would not treat as confidential. On our side the links are stored hashed (scrambled so the stored value cannot be turned back into the link). They are revocable at any time, and regenerating a link immediately kills the old one, so if a link does get out you can cut it off.

12.3 How little goes into a calendar

  • “My shifts” contains only the shifts of the user whose calendar it is. No colleague is named in it.
  • The collection calendar shows a customer's first name and last initial only — for example “Sarah M.” It never contains a phone number, an email address or a postal address.

13. Cookies

We use cookies on this website. A consent banner is shown on your first visit. Essential cookies are set regardless of consent. Analytics and marketing cookies (Google Analytics 4, PostHog, Google Ads, Endorsely, Tawk.to, Sender.net) are only set if you accept all cookies. PostHog specifically uses cookies to support session recording and heatmap functionality — these are only active with your consent.

For a full list of cookies, their purposes, and duration, see our Cookie Policy.

14. Your Rights Under UK GDPR

As a data subject you have the following rights:

  • Right of access: obtain a copy of the personal data we hold about you.
  • Right to rectification: have inaccurate data corrected without undue delay.
  • Right to erasure: request deletion of your data in certain circumstances. Read section 15 before relying on this — it explains what deletion in the app does and does not reach.
  • Right to restriction: restrict how we process your data in certain circumstances.
  • Right to data portability: receive your data in a structured, machine-readable format.
  • Right to object: object to processing based on legitimate interests or for direct marketing.
  • Right to withdraw consent: withdraw any consent at any time without affecting the lawfulness of prior processing. To withdraw analytics cookie consent, clear your browser cookies and decline on next visit, or email us.

To exercise any right, email info@foodcore.io with subject line "Data Rights Request" or "Subject Access Request". We will respond within 30 days at no charge. We may need to verify your identity before processing your request.

If you are a customer or employee of a business that uses FoodCore

Your rights are exercised against that business, not against us — they decide what is held about you, and we only hold it for them. Contact the bakery, caterer or kitchen you dealt with. If you write to us instead we will not ignore you: we will pass the request on to them and help them action it, but we cannot make decisions about their records on their behalf.

15. What “Delete” Actually Does — and How Erasure Works

This is the section most likely to matter if one of your customers asks you to wipe their details. We would rather set out the real behaviour than let you assume something that is not true.

15.1 Deleting a customer marks them inactive — it does not erase them

When you delete a customer in the app, FoodCore performs a soft delete: the record is marked inactive and disappears from your lists, but the record itself and the linked order history remain in the database. There are two reasons for that — orders point at the customer record, so removing it outright would break the order history; and that financial history has to be kept anyway (see 14.3).

So “Delete” in the app is not erasure. If you have told a customer their data has been erased because you pressed Delete, that is not accurate. For an actual erasure, see 14.4.

15.2 The 30-day Undo window

Deleted recipes, customers, orders and production runs are recoverable for 30 days, so that an accidental deletion on a busy morning is not a disaster. That is a deliberate design choice with an obvious consequence: for those 30 days the data still exists. After the window closes it is purged.

15.3 Receipts are voided, never deleted

A receipt cannot be deleted. If one is wrong, it is voided — marked cancelled, with a reason recorded against it — and it stays visible. The receipt numbering sequence has to run unbroken for the records to be trustworthy, so a mistake stays on the books with an explanation rather than vanishing. This is normal accounting practice and it is not something we can switch off for an individual record.

Remember also that receipts hold a snapshot of the customer's contact details as at the day of issue (see section 3.8), so customer data lives there too.

15.4 Asking for a real erasure

Article 17 of the UK GDPR gives people a right to erasure (often called “the right to be forgotten”). There is no self-serve erasure button in FoodCore. An erasure request is handled by contacting us at info@foodcore.io, and we act on it together with you as the controller.

The right to erasure is not absolute, and it commonly runs into a legal duty to keep financial records (see section 16). Where those two collide, the usual resolution is to strip the personal identifiers while keeping the transaction record — the sale, the amount and the date remain for the accounts, but the name, address, email and phone number are removed from them. That satisfies the individual's rights without destroying records you are obliged to keep. Which parts can be removed depends on the specific records involved, so tell us what you need and we will go through it with you.

15.5 Restore is not a way round any of this

The version-history restore feature only rewrites a fixed, allow-listed set of recipe and ingredient fields back to an earlier value. It cannot recreate deleted data and is not a route around an erasure request. Restoring an old version of a recipe will not resurrect a customer, an order or anything that has been erased.

16. Data Retention

  • Account and billing data: retained for the duration of your subscription plus 2 years after termination (longer where required by HMRC accounting obligations).
  • Customer data you upload: retained for the duration of your subscription. On cancellation, retained for 30 days for export, then permanently deleted.
  • Deleted recipes, customers, orders and production runs: kept for 30 days so they can be undone, then purged. Deleting a customer is a soft delete — see section 15.
  • Financial records (receipts and payments): ordinarily kept for six years to meet HMRC record-keeping requirements. Receipts are voided rather than deleted.
  • Version history / audit log (who changed what): there is currently no retention limit on this — it is kept indefinitely and grows over time. We would rather tell you that than quote a period we do not actually apply. Reviewing this is on our list.
  • Photographs of supplier receipts and delivery notes: deleted as soon as the scan is applied, discarded or fails. Scans left unreviewed are swept up and removed by a background job (default: 30 days).
  • Usage/log data: up to 12 months. Anonymised analytics may be retained indefinitely.
  • Newsletter email addresses: retained until you unsubscribe. A suppression record (email address only) is kept for 3 years to evidence consent.
  • AI Check results (reports stored in-app): retained for the life of the account; deleted on account closure or on request via account settings.
  • Data submitted to Anthropic API: retained by Anthropic for up to 30 days per their policy; not retained by FoodCore beyond the check result.
  • Credit transaction log: retained for 7 years for financial record-keeping.
  • Stripe payment references (credit top-ups): retained for 7 years for financial record-keeping.

17. International Transfers

Some of the companies we rely on are based outside the UK, which means data can travel to them. In plain terms, an “international transfer” just means the data is handled by a company in another country, and UK law requires us to have a proper contractual safeguard in place when that happens.

United States. The following are US-headquartered: Anthropic (AI Checks and receipt scanning), Stripe (subscription billing and Stripe Connect), Google (Analytics 4, Ads, and the Calendar API where a user connects their own calendar), Shopify (where you connect a Shopify storefront), Tawk.to, Cloudflare, Resend and Web3Forms. These transfers are covered by Standard Contractual Clauses (SCCs) with the UK International Data Transfer Addendum — the standard contract terms UK law recognises as giving your data an appropriate level of protection abroad.

No transfer. Sender.net is EU-based. PostHog is hosted on EU infrastructure (eu.i.posthog.com).

WooCommerce is different: it runs on hosting you control, so where that data sits is determined by where you host your own shop, not by us.

18. Customers Based in the United States

FoodCore is available to food businesses in the United States, and the app includes a US Compliance Region with FDA / FALCPA labelling features. Regardless of where you are based, FoodCore.io Ltd (a UK company) remains the data controller and processes your personal data under the UK GDPR and the Data Protection Act 2018 as described in this policy. We do not sell personal data. The sub-processors listed above (including those operating in the United States) handle data on our behalf under appropriate contractual safeguards. US-based customers may exercise the same access, correction and deletion rights set out in this policy by emailing info@foodcore.io; where US state privacy laws grant you additional rights, we will honour applicable requests on a good-faith basis.

19. Affiliate Programme — Data We Hold About Partners

Our affiliate programme is operated via Endorsely. If you participate as an affiliate partner, we collect and process the following data:

  • Registration data: name, business/trading name, email address, website or social media URL.
  • Performance data: referral click counts, conversion counts, commission amounts earned, referral attribution (tracked via Endorsely cookies with a 30-day attribution window).
  • Payment data: bank account or payment details necessary to remit commission payments.

This data is processed on the basis of contract performance (Art. 6(1)(b)) and legitimate interests (Art. 6(1)(f)). Affiliate performance and payment data is retained for 3 years after termination of the affiliate relationship (or longer where required by HMRC). You may request access to or deletion of your affiliate data by emailing info@foodcore.io. For full affiliate programme terms, see our Terms & Conditions.

20. AI Checks — User Rights and Opt-Out

Users may request deletion of their AI Check history at any time via account settings or by emailing info@foodcore.io. Note that credit transaction records may be retained for statutory financial record-keeping purposes even after other data is deleted.

Both AI features are opt-in by use — nothing is sent unless you actively run them:

  • If you do not want recipe or ingredient data sent to Anthropic, do not run AI Checks.
  • If you do not want a photograph of a supplier receipt or delivery note sent to Anthropic, do not use receipt scanning — enter the delivery manually instead. You can also make this decision receipt by receipt.

All other FoodCore features operate without any third-party AI processing.

21. Changes to This Policy

We will notify active subscribers by email at least 14 days before material changes take effect. The date at the top of this page reflects the most recent revision. Continued use of the Service after the effective date constitutes acceptance.

22. Contact and Complaints

If you have concerns about how we handle your personal data, please contact us first:

If you are not satisfied with our response, you have the right to lodge a complaint with the Information Commissioner's Office (ICO) — the UK's data protection supervisory authority: