Privacy policy

Effective 31 October 2026 · A notice about a recipe, sent by email, is kept for two years

Diet Handbook is an iPhone app for keeping recipes and planning meals around dietary restrictions. It is run by Ivan Shakhorski as an individual developer. This policy covers the app, the service behind it at api.diet-handbook.com, and this website.

Questions, requests, or anything this page does not answer: privacy@diet-handbook.com.

The short version

Your account holds what you type in: recipes, meal plans, shopping lists, and the diet profiles that say what you avoid.
Diet profiles are health data. They are the most sensitive thing here and they are treated that way.
There is no analytics SDK, no crash reporter in the app, no advertising, and no tracking of any kind — across apps, across sites, or otherwise. Nothing is sold or shared for marketing.
You can export everything, and you can delete the account. Deletion happens at once, once you have signed in again to confirm it is you, and cannot be undone.

What is stored, and why

Kind	What it is	Why
Account	An account id, and the identity Apple or Google gave when you signed in — an opaque subject, sometimes an email address, sometimes a display name. An Apple private-relay sign-in may leave us no address at all. Your name, which you can change. If you offer a recipe to the community and agree to your name being shown on it, also a random id that groups your recipes under it.	To know whose handbook is whose, and to let you add a second sign-in method to the same account. No mail is ever sent to it. Your household sees your name. Nobody else does until you agree to it the first time you share a recipe with the community; then it is the one thing about you they see — “By …” on your approved community recipes — and you can change it in Settings.
Diet profiles (health data)	Allergen hard stops, dietary systems, macro targets, who you are cooking for — often a household member’s first name — and a private model of what you tend to cook, worked out on our server from your likes, saves, plans and cooking history.	This is what the app does. It is used to filter and order recipes for you and for nothing else. The model of what you cook only changes the order; it never hides a recipe.
What you write	Recipes, ingredient lines, steps, photographs, notes, and reports you file about somebody else’s recipe (a reason, and a note if you add one). A recipe an AI model wrote for you is marked “Written with AI”, and that mark cannot be removed. Each ingredient line records how it came in: typed, pasted, shared to the app, or written for a wish.	To keep your handbook, to share it with your household, and to run the public catalogue if you offer a recipe to it. A recipe written with AI can never be offered. When a line names a food the handbook cannot read yet, the people who add foods see how many recipes name it and how they came in; from a recipe that is not public they see a count and the food’s name, never the line, the recipe or who wrote it.
Planning	Meal plans, saved plan shapes, shopping lists, and the cupboard.	To plan a week and shop for it.
Engagement	Likes, ratings, saved recipes, what you cooked when, and the community authors you blocked. An author you block is never told.	Shown back to you, and — for likes and ratings — counted on public recipes. A block hides that author’s recipes from you.
Feedback	What you write on the app’s Send feedback page, and the app version that sent it. Nothing else goes with it: not your diet profile, not your household.	Read by the person who runs the service, to fix what is broken and decide what comes next. Nobody else sees it.
Notices	An email about a recipe sent to the support address, usually from the Report a recipe page and often by somebody without the app: the email, with the address it came from, and our answer. Both stay in the mailbox. We add what is wrong to the recipe as a report, which holds no address and no account.	To decide about the recipe, to tell you what we decided, and to answer a later question about the same decision. The recipe’s author is never given your address.
Household	Households you are in, who else is in them, and the household’s link. The link’s code is stored as a hash, and the link lapses when nobody has looked at it for six months.	So several people can cook from one handbook.
Plus	If you subscribe to Plus: which plan, Apple’s id for the subscription, and when the paid period ends. If we gave you Plus, when that ends. No price, card or Apple Account detail — Apple takes the payment and never hands those over.	To know who has Suggest meals. One subscription covers a household, so the other members see that somebody pays and who; never the plan or the dates.
Sessions	One row per signed-in device: a hash of its refresh token, the app build, a device label you typed, and a coarse region worked out from where the request came from. The address itself is not stored.	Security. So that “signed in from somewhere I have never been” is a question you can answer.
Operational	A short-lived record of requests already handled, so a phone with bad signal cannot create the same recipe twice; rate-limit counters keyed on a secret hash of an address rather than the address; moderation leases.	Keeping the service working and abuse-resistant.
AI requests	When you ask for a recipe to be read from pasted or shared text, for a recipe to be written for a wish, or for a week to be filled: which feature, which model answered, what it cost, and whether it worked. What you typed is not kept — only a digest of it, which cannot be turned back into the text. The answer (the recipe read from what you pasted or written for your wish, a proposed week, and any allergy or diet your request named, which that week was held to) is kept only until your phone has collected it. A pasted or written recipe becomes a recipe only when you save it. For a TikTok, YouTube or Pinterest link you share, the post’s public credit — the platform, the link, the creator, the thumbnail’s link and the caption’s opening words — is kept with the request as long as the answer. When a recipe you offer to the community is checked, the same record is kept, and the model’s yes/no answers stay with the recipe and its photos for the reviewers.	To run the request, to stop one account running up an unbounded bill, and to trace a bad answer to the instructions that produced it.
Audit	That a privileged action happened — a moderation decision, a role grant, a change to ingredient safety data — by account id, never by name.	Safety-relevant decisions have to stay attributable.

Health data

“Avoid peanuts” stored against a named person is health data, and this app is built around storing exactly that. It is declared as health data in the App Store privacy labels. It is never used for advertising, never shared with anybody outside the service, and never sent to a third party for analysis. Within the service, it is read only to decide which recipes to show you and in what order. The one part of a profile that leaves our server is a daily energy or protein goal, when you ask for a week to be filled: it goes to the AI model as a number with no name beside it, so the week can be balanced toward it, and is gone when the request ends.

If you join a household, its members can see the diet profiles shared into it, and every recipe you keep except drafts — that is what a household is for. They also see which recipes you saved, on a shelf of everything the household saved, without your name beside them. They see a daily calorie target but not the protein, carbohydrate and fat split under it. The age, height and weight a target is worked out from never leave your phone. Leaving one removes those rows from your device immediately, and stops the sharing in both directions.

Photographs

A photo of dinner carries the coordinates of the kitchen it was cooked in. Every uploaded image is re-encoded before it is stored, which drops that metadata: no EXIF reaches the storage bucket, let alone the public catalogue. Images are never publicly readable — each view goes through the service, which checks who is allowed to see the recipe.

A photo, a screenshot or a scanned page, picked in the app or shared to it, used to read a recipe into the paste box stays on your phone. The words are read there, and only those words are sent, the same way pasted text is. The picture is not uploaded.

So does a video you save and share to Diet Handbook, or pick in it. What is said in it is turned into text on your phone, and the words on screen are read there too. Only those words are sent. The video and its sound are not uploaded.

What is deliberately not collected

No device identifiers. No IDFA, no vendor id, no fingerprinting.
No analytics. There is no analytics SDK in the app and no event pipeline in the service.
No crash reporting in the app. The server reports its own failures, as described below; nothing in those reports comes from your phone or is about you.
No location. The app never asks the device where it is.
No photo of a page you are reading in. A photo, a screenshot or a scanned page, picked in the app or shared to it, used to turn a page into a recipe stays on your phone. Only the words read from it are sent. The same goes for a video: only the words said and shown in it leave your phone.
No advertising, and no sale of data. There is nobody to sell it to and it is not for sale.

Who else sees it

Who	What they get
Hetzner Online GmbH (Germany)	Everything, as the hosting provider: the servers running the service, the database, and the storage holding recipe photographs. They are a processor acting on our instruction and do not use any of it for their own purposes.
Apple and Google, for sign-in	What they learn from their own side of the sign-in exchange. Nothing about you is sent to them by this service: it verifies the identity token you bring against their published keys, which is a request for keys and not for anybody.
Apple, for Plus	Apple sells the subscription and takes the payment; what they learn is their own side of that sale. Nothing about you is sent to them by this service. The phone tags the purchase with your account id, so the service can file it under the right account, and checks Apple’s signature on the record of it.
A website you ask the importer to read	A request from our server for a page you named. Your own address is never forwarded — the fetch is ours, from our address — so the site learns the page was imported, not by whom.
Google (YouTube Data API)	When you share or paste a YouTube link: the video’s id, with our service’s key, from our server’s address. Never your address, your account or anything about you.
TikTok and, when enabled, Pinterest	When you share or paste a link to a post there: a request from our server for that post, to read its caption or the page a pin links to. Your own address is never forwarded — the request is ours, from our address — and nothing about you goes with it.
OpenRouter, Inc. (United States), and the AI model provider it routes to	Only when you use an AI feature or offer a recipe to the community. To read a recipe: the text you pasted, dictated or shared to Diet Handbook from another app, or the words read on your phone from a photo, a screenshot or a scanned page, picked in the app or shared to it — the picture stays on your phone — or the words spoken in a video you saved and shared to Diet Handbook or picked in it, turned into text on your phone, with the words read from its frames — the video and its sound stay on your phone — every time. A link is different: our server fetches the page itself, and a model sees the page’s text only when the page does not publish its recipe in a form our server can read on its own. For a TikTok or YouTube link, a model sees the post’s caption or the video’s description, without its links, its lines of hashtags alone and the runs of hashtags that close a line (a single hashtag, one inside a line, a list item that is one hashtag, or the hashtags after an amount — “2 tbsp #peanut #butter” — reach the model as words). To write a recipe for a wish: the words of your wish, and then, if some of the model’s own ingredient lines could not be recognised, those lines again so it can name them more plainly. To fill a week with a request: the sentence you typed, the dates and meals to fill, how many people are eating and each one’s daily energy and protein goals as bare numbers (“person 1: 1,980 kcal”), the energy and protein of meals already planned, and the titles, meal types, times, cuisines, main ingredients, energy and protein of recipes on your shelf, or in Discover when you include it. When you offer a recipe to the community: its title, ingredient lines and method, and each of its photos with its title, so a model can check it is a real recipe and a photo of food before anyone else sees it. Never a name, an allergen, a diet or anything else from a diet profile — which recipes are safe for whom is decided on our server before anything is sent, and the model can only choose among those. Every request asks for providers that do not store or train on what they receive. At present the models are Google’s Gemini, and an OpenAI model for the community check.
Functional Software, Inc. (Sentry), data held in the EU (Germany) — or a GlitchTip we run ourselves, which takes the same reports	Only when something on our server breaks — a failed request, a background job that gives up, or a crash: what kind of error it was, where in our code, which address of the API it happened on (the pattern, such as “a recipe”, not which one), and a reference number that lets us find our own log line. The message is cleaned first, so values and email addresses are cut. Never what you sent or received, your account, or anything from a diet profile. It tells us the service failed before you have to. If neither is set up, nothing is sent.
Squarespace and Google (Gmail), for our email addresses	Any email you send to support@ or privacy@diet-handbook.com (Squarespace forwards it to a Gmail mailbox), a notice about a recipe included, with your address and the name your mail program gives, and our answer. Nothing from the app or your account goes there unless you write it.
UptimeRobot	Nothing about you. Every few minutes it asks our server whether it is up, and tells us when it is not.
USDA FoodData Central	Nothing. It is read when ingredient reference data is built, never in the path of anything you do.

A recipe you offer to the community is checked first, by a model and sometimes by a person, and once it is in the catalogue everybody can see it, which is what publishing means. Each of its photos waits until a model or a person has looked at it. Three people reporting it take it back out for a person to look at; you are never told who reported it or why. The people who review community recipes see your name, when you made your account and how your earlier community recipes were decided; never your email address. Choosing Community is also your word that you wrote the recipe and the photos are yours to share, under the community recipes part of our terms; which version of those terms you agreed to is recorded with the recipe. When you edit a recipe that is already in the catalogue, the edit is kept beside it and checked the same way, while everybody else goes on seeing the version that was approved; only you and your household see the edit until it is approved. Nothing else you write is visible to anyone outside your household. When you send a recipe, a link goes with it only if the community can already read it.

How long it is kept

Most of it, for as long as the account exists.
A deleted recipe or profile leaves a tombstone for 180 days, so other devices learn it is gone, and is then removed outright.
A draft untouched for 90 days is deleted automatically, and then follows the same path.
A session ends when it is revoked, or 60 days after it was last refreshed — whichever comes first.
Replayed-request records: 7 days. Rate-limit counters: 24 hours past their window.
AI requests: what you typed, only until the request is picked up — seconds. The answer, 10 minutes after your phone first collects it and 24 hours at most, and a shared post’s public credit as long as the answer. The record of the request itself (model, cost, whether it worked): 30 days.
Which version of the community terms you agreed to when you offered a recipe: as long as the recipe is kept, which for a recipe left in the catalogue after you delete your account means as long as it stays there — it is what we keep showing it under. The submission’s audit entry records it too.
A notice sent by email, and our answer: 2 years after we answer, then deleted from the mailbox. The report it became on the recipe stays, like any report, with no address on it.
Audit entries are kept indefinitely. A record that expires cannot answer the question it exists for.
Backups: up to 14 days. The database is dumped nightly and a dump is deleted once it is a fortnight old. Backups are not edited to remove a deleted account — rewriting history inside a backup is how a restore silently loses unrelated data — so a dump taken before a deletion still holds those rows until it ages out. This is the real number, which is why it is the one stated here.

Getting your data, and deleting it

Export

Settings → export produces a machine-readable file containing everything held against your account, section by section. It is generated on request from the live database rather than from a copy kept for the purpose.

Deletion

Settings → delete account asks you to sign in again, to confirm it is you, and then deletes the account at once. There is no waiting period and no way back. You leave any household first, just as if you had walked out. Everything above is destroyed, with three exceptions, all deliberate:

Recipes you published to the public catalogue are kept, and severed from you. They are in other people’s meal plans and shopping lists, and withdrawing them would delete a stranger’s dinner for a reason that has nothing to do with them. Your name goes with your account, so they read “From the community”. Your photographs are not kept: those are deleted, because a picture of your kitchen is a more personal thing than a method. Which version of the community terms you agreed to stays with each of them, without your name.
A report you filed about a recipe stays as an anonymous row. That it was you goes; that a recipe was reported, dismissed and reported again is what makes moderation possible.
Audit entries stay. The record that a moderation decision or a role grant happened has to remain attributable — it holds an account id and a timestamp.

Anything else — correction, a question about what is held, or a deletion you would rather arrange by email — is privacy@diet-handbook.com. If you are in the UK or EU/EEA, the rights of access, rectification, erasure, restriction, portability and objection all apply, and you may complain to your national data protection authority.

Where it is held

On servers in Germany. Sign-in verification talks to Apple and Google, who operate globally; nothing about you is sent in either direction. When you use an AI feature or offer a recipe to the community, what is described above goes to OpenRouter in the United States for the length of that request. Error reports are held by Sentry in Germany.

Children

The app is not directed at children, and an account is not knowingly created for anyone under 13. If you believe a child has one, write to the address above and it will be removed.

This website

These pages set no cookies, run no analytics, and make no requests to any other host — they use your device’s own font for that reason. The web server keeps ordinary access logs for a short period to diagnose faults, except for the links the app sends — a household invitation at /join/ or a recipe at /r/ — which it does not log at all. The page those links show in a browser says nothing about the household or the recipe.

Changes

When this policy changes, the date at the top changes with it, and a change that widens what is collected will be announced in the app before it takes effect.