Kitchive

Privacy Policy

Last updated 10 October 2026

English · Deutsch · Türkçe

Kitchive is a recipe app for your phone. This policy describes what it does with your information, which is very little, and it is written to be checkable rather than reassuring: every claim below corresponds to something in the app's source code or in the server's, and the privacy declarations in the App Store listing say the same thing.

It is also meant to be complete. Who is responsible, the legal basis for each kind of processing, who receives what and where, how long each thing is kept, and your rights under the GDPR and under Türkiye's KVKK are collected in the second half, from "Who receives what" on. This policy is also published in German and in Turkish; where the versions differ, this English version applies.

The short version

Who is responsible

The controller — the one responsible for the processing this policy describes, as the GDPR and the KVKK put it — is:

Soner Sahin, c/o Impressumservice Dein-Impressum, Stettiner Str. 41, 35410 Hungen, Germany — info@kitchive.app.

The same details are in the Impressum. Write to that address about anything in this policy, including the rights described under "Your rights".

What stays on your device

Everything you create. Recipes, the photos attached to them, ratings, tags, folders, favourites, your meal plan, your shopping list, your cooking journal (the days you cooked a recipe, your notes and photos), your pantry (what you have at home, your staples and the days to use things by), your chosen theme and your unit preference are held in a local database that only Kitchive can read. The one exception is a shared shopping list: it is kept in the iCloud of the person who shared it, also with sync off (see "Optional iCloud sync").

Deleting the app deletes all of it, and there is no copy on our servers to fall back on. If that matters to you, Settings → Export all recipes saves a readable JSON file wherever you like. It carries the text of every recipe, including which folder each one is in, your cooking journal — its days and notes, and as many of its photos as fit in the file, newest first, as smaller copies — and your pantry, and not the recipes' photographs — worth knowing before you delete anything. The one exception to "deleting the app deletes it" is iCloud sync, next.

Optional iCloud sync

With Kitchive Pro you can turn on Settings → Sync with iCloud, and your recipes — with their photos, your meal plan, your shopping list, your cooking journal (dates, notes, photos) and your pantry — are stored in your private iCloud database so they appear on your other devices.

This is between you and Apple. The data goes into your own iCloud account, in its private database. Kitchive cannot read it, and neither can anyone with access to our systems, because those systems hold no copy of a recipe to read. Apple's handling of iCloud data is governed by Apple's Privacy Policy.

It is off unless you turn it on.

A shared shopping list. If you share your shopping list (Shopping → More → Share list…, or Settings → Shared shopping list), it is kept in your iCloud too, in its own part of your private database, and the people you invite through Apple's sharing reach it from their devices. Everything on the list is visible to everyone in it, and everyone in it sees the others' iCloud names, yours included, as Apple's sharing shows them. It counts against your iCloud storage, not theirs. Kitchive cannot read it: the list goes between your iCloud and theirs through Apple, and our systems hold no copy. If you joined someone else's list, it lives in their iCloud. If they stop sharing it, delete it or remove you, its items stay on your device as your own list; if you leave it yourself, you choose whether to keep a copy; if you sign out of iCloud or switch to another Apple Account, the list stays with that account and leaves the device. Sharing a list needs Kitchive Pro; joining one does not. If the owner's Pro ends, the list becomes read-only for everyone in it, and the people in it are told that this is because the owner's Kitchive Pro has ended — nothing on it is deleted, and it can be edited again once the owner has Pro again. Your pantry is never part of a shared list: it stays yours alone, also when you clear the shared list's ticked items into it.

Importing a recipe

There are five ways to get a recipe in without typing it: a link, some text you pasted, a photograph of a written recipe, a photograph of a finished dish, and a cooking video saved in your Photos. Each has a device layer and an AI layer.

The device layer, which is the floor under everything

A link is fetched directly by your phone, and the recipe is read out of the page here. The phone asks for the page the way Safari on an iPhone would, and its request says so. Only if the site turns that request away — an HTTP 401 or 403 — or answers with a cookie-consent page instead of the recipe does the phone ask once more, this time identifying itself as a link-preview crawler: the one Facebook uses to draw link previews, which many sites answer with the page itself. For TikTok, whose video pages are a script rather than a page, the phone asks TikTok's public oEmbed address for the caption instead. What each of these fetches tells the site is set out under "What a link fetch tells the site".

Pasted text is parsed on the device and needs no network at all. A photograph of a cookbook page or a handwritten card is read by Apple's Vision framework, which is part of iOS and runs on the device.

A video you share to Kitchive from your Photos is read on the device: Vision reads the text shown on its frames, and Apple's speech recognizer turns what is said into text — strictly on the device. Kitchive forbids the recognizer from using Apple's servers, and skips a language it cannot recognize on the device rather than send it anywhere. The video and its sound never leave the phone; what can leave, only under the AI layer below, is the text that came out of them.

Apple Intelligence, on this device. On an iPhone or iPad with Apple Intelligence switched on, Kitchive can ask Apple's on-device language model for two things: to suggest tags for a recipe you are editing, picked only from the tags you already use, and to sort the lines of a recipe read on the device — which line is the title, an ingredient, a step or a note — when the recipe is written in a language the model supports. The model is part of iOS and runs on the device: the recipe goes neither to Kitchive's server, nor to any AI provider, nor to Apple. It is not what this policy calls AI, and it counts against no allowance. No tag is added until you tap it, and a recipe whose lines it sorted opens as a draft you check before saving. It is on by default where the model exists, and Settings → Privacy → Use Apple Intelligence on this device turns it off. Translate, on a recipe written in another language than the app's, uses Apple's Translation framework on the device in the same way; the system may first ask to download a language from Apple, which is a download of the language, not an upload of your recipe. The allergens and the nutrition estimate on a recipe's page are worked out on the device too (see "Allergens and nutrition").

This layer is free, unlimited and permanent. If you never send anything to AI, it is the whole of what the app does, and nothing you wrote or photographed reaches Kitchive's server or any AI provider. What still leaves the phone without an AI read is the page fetch itself, the subscription check described under "Subscriptions", and — only if you switched them on — iCloud sync and the two anonymous data streams.

Kitchive does not import from Instagram, Facebook or Threads. A link to any of them is refused before any request leaves your phone, and a link elsewhere that redirects to one of them is refused at the redirect, the same way.

A photograph of a finished dish has no device layer. No amount of reading text off a picture turns a plate of food into a recipe, so that route works only with AI, and the app says so before you take the photo rather than after.

Which layer runs, and in what order

On a link whose page publishes machine-readable recipe data, your phone reads that data and AI is never asked. Nothing leaves the phone but the fetch of the page itself.

Everywhere else — a link that yielded only a caption, pasted text, a photographed page or dish, a shared video — AI is tried first, and the device is the floor underneath it. If the model answers, that is the result you get. If it was not asked, was not allowed, or did not deliver, your phone reads what it can.

So what decides whether an import is read with AI is you — the tap under the sentence that says where it goes — and, after that, the allowance you have left. When your free imports are spent, the app does not take its own count's word for it: the first AI request of a session still reaches Kitchive's server, which refuses it before any AI provider sees anything, and from then until the app is next opened, imports are read on your phone.

Being told first, and saying yes

Before anything leaves your device for AI, the import screen names exactly what would leave and where it would go — not "allow Kitchive to use AI", but a sentence about that import:

You are importing The screen says, before anything is sent What sends it
a link the phone opens the page and sends the text it finds — not the link — to Kitchive's server, which passes it to OpenAI (or, if OpenAI is down, to OpenRouter and Google's Gemini) to be read; Kitchive keeps no copy Read the recipe on the link card; for a link shared from another app, Read with AI on the card that offers it — or, once you have said yes to links, its arrival (below)
text you pasted the text goes to Kitchive's server and on to OpenAI (or the backup) to be read; Kitchive keeps no copy Read the recipe under the box
a photograph, of a page or of a dish the photo goes to Kitchive's server and on to OpenAI (or the backup) to be read — or, for a dish, so it can propose a recipe from what it can see — and stays on this phone as the recipe's picture taking or choosing it on the photo screen, the first time only after the question below; for a photo shared from another app, Read the photo
a video from your Photos the video never leaves the phone; the words read out of it go to Kitchive's server and on to OpenAI (or the backup) to be structured Read the video on the shared video's card

Two answers are remembered. Everything else is asked each time.

A no is just not tapping, and nothing records it — a buried permanent "never" is worse than a question you can answer again next week. With no AI route, every screen reads on your phone.

The video route has one more question, and it is iOS's rather than Kitchive's: the first video asks for the system's speech-recognition permission — the same one hands-free cooking asks for (see "Hands-free cooking"). Decline it and the route still works on the text shown in the frames.

Where it goes, and who else is in the chain

Kitchive's server is a set of small functions, with their database, hosted by Supabase in the region London, United Kingdom (eu-west-2). It receives what you sent, passes it to an AI provider, and hands the answer back.

There are two AI providers, and both need naming.

Which one answered is not something the app shows, and no setting picks one. Both are third parties receiving what you sent, which is why both are named here and in the table under "Who receives what".

What the providers may do with it. OpenAI does not use data sent through its API to train its models, and Kitchive's requests tell it not to keep the answers for later use. OpenAI keeps API requests for up to 30 days to detect abuse, and then deletes them — unless the law requires it to keep them longer, or keeping them is reasonably necessary to protect its services or a third party from harm. Kitchive's requests to OpenRouter allow it to use only endpoints that do not collect the data they receive. OpenRouter itself does not train on what it receives and promises no fixed retention period: its privacy policy says it keeps information as long as is reasonably necessary for its business and legal obligations, and keeps images no longer than routing needs except for abuse detection, security, billing or legal compliance. Kitchive uses each of these providers under its data processing terms; where a provider requires a separately signed agreement, Kitchive signs it before that provider receives personal data.

A few small things travel with an AI import besides the content. The language your phone or the app is set to — a tag such as de-DE, nothing more — so the recipe comes back in your language; and, when a photographed dish becomes a recipe, the name of the dish you picked from the app's suggestions, with up to fifteen of the ingredients and up to four of the cuisines the recognition saw in the photo — words the model itself produced a moment earlier, not anything you typed. None of it is stored.

A photographed dish asks a few more services. Once you have picked a dish, Kitchive's server looks its name up on TheMealDB, a public recipe database; on Wikidata, the Wikimedia Foundation's open database, for the ingredients it lists for the dish; and on Wikipedia for the article that says what the dish is made of — Wikidata and Wikipedia in your language and then in English — so the recipe it proposes is grounded in real ones rather than invented. When Kitchive has it switched on, the name is also looked up on Spoonacular, a commercial recipe database. Wikidata, Wikipedia and Spoonacular receive only the dish's name. TheMealDB receives the dish's name and, when that finds nothing, up to three of the ingredient names the recognition saw, one at a time. None of them receives the photo or anything about you or your phone.

A link is not treated like the others. Your phone opens the page itself and only the text it read is sent on. The link never reaches Kitchive's server or either AI provider. Pasted text and photographs have no page to fetch, so those go themselves — a photograph as the smaller copy described below.

What a link fetch tells the site

"The link doesn't leave the phone" is what the link card says, and it is true of us. The link plainly does reach the site it names, since your phone has to fetch the page — with your IP address, as any visit does, and the user agent described above. Some hosts are asked differently:

Nothing about any of these fetches is reported back to us.

A photograph is sent as a smaller copy, never as the original

Before it leaves, the picture is reduced to at most 1200 pixels on its longest side and re-encoded as a JPEG. The original stays on your phone. Nothing else about the photo goes with it — not where or when it was taken, not the camera, not any other tag your phone attached to it — because the re-encoded copy is built from the pixels alone.

Kitchive does keep the photograph — for you. Whichever layer read it, the picture becomes the recipe's own image on your device, and syncs to your private iCloud with the rest of your recipes if you turned that on. Keeping your photo for you is a different thing from sending it somewhere, so this page says both.

What Kitchive's server keeps

Nothing you sent. There is no link column, no text column, no image column, and no recipe column in any table it owns, so there is no database of what you imported. The request is read, answered, and forgotten. The database migrations are in the repository and are the proof.

Nothing you sent is written to the server's log either, with one qualification that is worth making rather than hiding. The functions log failure reasons — a provider name, an HTTP status, a rejection detail — and never a link, a caption, a photograph, a recipe, or your subscription identifier. The qualification is that when an AI provider refuses a call, the first 300 characters of the provider's own error message are logged, because that is where anyone diagnosing a broken deployment has to look. Those messages normally describe the fault; a provider that chose to quote part of the request back in one would put that fragment in the log. Kitchive does not put it there, and cannot promise a provider will not. Supabase keeps these logs for at most seven days.

What is written down is four small tables, and none of them is about you:

How long they are kept. A job on the server runs every day and deletes:

Deleting the app does not delete the rows at once — nothing on them says which installation was yours — but it destroys the key they are filed under, so nothing can use them again, and the job removes them on that schedule.

The device row, and why there is one

Kitchive has no accounts, so it cannot ask who you are — and an endpoint that calls a paid model without asking anything would be free computing power for the whole internet within a week, at the owner's expense.

Instead it asks Apple. The first time an import of yours would go to AI, the app has iOS generate a key in this device's Secure Enclave and asks Apple to vouch that it belongs to a genuine, unmodified copy of Kitchive on real Apple hardware. That vouching — App Attest — is checked against Apple's own certificate authority on the server, and the key is recorded so later requests can prove they come from the same install. The private key never leaves the Secure Enclave and cannot be extracted, by Kitchive or by anyone else.

None of this happens until an import of yours goes to AI. A copy of the app whose user never sends one never generates a key and never registers anything.

A key id identifies a key, not a person. It is not the identifier Apple gives to any other app, there is no route back from it to you, and deleting and reinstalling Kitchive produces a new one. It is still a stable identifier for one installation of one app, held on a server, alongside the date it registered and the date it was last used — which is why it is described here in this much detail rather than waved at, and why the App Store privacy label declares it.

The salted hash is not a second layer of anonymity, and this policy will not sell it as one. It stops someone who has only a key id from looking up that device's counters, which is what it is for. It does not stop anyone holding both the database and the salt from joining the two rows, because a hash that can be recomputed can be matched — and the key id sits in the neighbouring table in the clear. What protects those rows is that they are reachable only with the server's own credentials and that there is nothing in them that says whose they are.

Reinstalling therefore resets the free imports. That is a deliberate trade: the alternative is keeping something that survives a reinstall, which is to say something that identifies you.

Your subscription status, on each AI import

Each AI import carries RevenueCat's anonymous identifier for your purchases to Kitchive's server, which asks RevenueCat whether it has an active subscription — so the server knows whether you get five for life or thirty a day. It is a random identifier tied to purchases, never a name and never an email, and it is never sent to either AI provider. Kitchive's server does not keep the identifier itself: a free user's is used to ask RevenueCat and then discarded, and a subscriber's is kept only as the salted, one-way hash in the subscription-claim row above, which binds the subscription to three devices at a time. This policy will not lean on "it is only a hash" — the note on the salted hash above says why.

The consequence worth stating: RevenueCat learns that an anonymous identifier attempted an import, and when.

Your IP address needs a more careful sentence than the rest

Every server on the internet sees the address a request came from, and the honest answer is not "never seen". Here is who sees yours, and what each does with it:

One thing goes the other way, and it is worth saying. Because the model call is made by Kitchive's server and not by your phone, OpenAI, OpenRouter and Google see the server's address, not yours.

Sharing a recipe out

Sharing is entirely between you and whoever you send it to. Kitchive's share sheet offers three forms of one recipe — a picture of a card, plain text, and a JSON file. All three carry the method as well as the ingredients, so a recipient can cook from what you sent; the card stops at 25 ingredients and 20 steps and says how many more there were. The card also carries the recipe's cover photograph, which is worth knowing before you send one, since that photograph is yours.

Nothing about a share reaches Kitchive. The destination is the one you pick in the iOS share sheet, and the JSON file carries no photographs at all.

Subscriptions

Kitchive Pro is sold through the App Store and managed by RevenueCat. RevenueCat issues the app a random, anonymous identifier; we never call their login API, so that identifier is tied to purchases and not to a person.

RevenueCat is asked at every launch. Each time the app starts, the RevenueCat code built into it contacts RevenueCat with that identifier, to learn whether this install has Pro and to fetch the prices to show. When you buy or restore, it passes the App Store's record of the purchase to RevenueCat to be checked. RevenueCat sees the address the request comes from, uses it to work out your country, and does not keep the address.

Payment happens entirely between you and Apple. Kitchive never sees your card, your billing address, or your Apple Account.

Pro is where the AI layer is paid for. Each AI import costs Kitchive money, so there is a number rather than a word: five AI imports are free, for the life of the install. After that, reading with AI is a Pro feature: thirty a day, on up to three devices at a time — a device that has gone a day without an AI import frees its place for another. Pro also raises the photo limit from one per recipe to twelve, turns on iCloud sync, lets you share your shopping list with the people you invite (joining someone else's list needs no Pro), and adds nutrition estimates — energy, protein, carbohydrates and fat per serving, worked out on the device. Allergen detection is free, and so is every colour theme.

Three honest qualifications on these numbers:

Everything else the device does on its own — writing, saving, scaling, cooking, planning, shopping, searching, organising, detecting allergens, and every on-device import route — stays free and unlimited, for everyone, with or without Pro. The nutrition estimate is the one thing the device works out by itself that is part of Pro.

Anonymous usage data

Kitchive can send a small number of anonymous events to PostHog, on its EU cloud, whose servers are in Frankfurt, Germany, so we can tell which features are used and — most importantly — why imports fail.

This one is opt-in. It is off when you first open the app, nothing is sent and no identifier is created until you switch it on, and it stays off unless you do.

Switch it on, or off again: Settings → Privacy → Share anonymous usage data. Turning it off erases the random identifier it was using, so switching it back on later starts fresh and cannot be joined to the earlier period — unless crash reports are still on, since the two switches share that one identifier. Turn both off and it is erased.

The last row of the table, app_crashed, belongs to the second switch and is described under "Crash reports".

This is the complete list of events. There are no others, and the app contains no general-purpose analytics library that could add any:

Event Sent with
onboarding_completed —
import_started which platform (TikTok, YouTube, web, or a video from Photos — or Instagram or Facebook when such a link is refused)
import_succeeded which platform, which method (AI, structured recipe data, or a parsed caption)
import_failed which platform, why it failed
page_read_succeeded —
page_read_failed why it failed
meal_recipe_succeeded —
meal_recipe_failed why it failed
recipe_saved_manually —
paywall_shown which screen it was shown from
trial_started —
purchase_unconfirmed which screen the paywall was shown from — sent when the App Store finished a purchase but Pro did not turn on
theme_changed which theme
cook_mode_started —
shopping_recipe_added which screen it was added from (the recipe's page, the library, the shopping tab's picker, the weekly plan, or What can I cook?)
meal_plan_entry_added —
app_crashed what kind of crash, and which version it happened to — see "Crash reports"

Every event also carries the app's version number and the random identifier for the install.

What is deliberately absent: no recipe titles, no ingredients, no links, no creator names, no folder names, no device model, no operating system version, no screen recordings, no screenshots, no location, and nothing that identifies you. Every value an event carries comes from a fixed list — a platform name, a failure reason — rather than free text.

"No location" needs one more sentence than the rest of that list. Everything else on it is absent because the app never puts it in an event. A location is different: an analytics service manufactures it on its own, by looking up an approximate city from the connection an event arrives on, so an event that stays silent is stored with a location the app never had. So every event Kitchive sends carries PostHog's documented instruction not to run that lookup at all, and a test fails the build if that instruction ever stops being sent. No city, region, or coordinates are derived.

The address itself is a smaller claim, and it gets the smaller word. Whether PostHog stores the address an event came from is a setting in PostHog's own project, and Kitchive sets it to discard the address before any release of the app can send PostHog an event. That setting lives in someone else's console, not in this app's code, so no build can verify it — and PostHog's own documentation says its location lookup can read the address before it is discarded. That is why Kitchive's privacy declaration lists Coarse Location for analytics instead of claiming the category does not apply: declaring something that turns out not to be collected is harmless, and the reverse is not.

How long. PostHog keeps events for at most one year — Kitchive keeps its PostHog plan's retention at one year, a period that cannot be shortened from Kitchive's side. The identifier the events carry is random, and your phone erases it when both switches are off, so later events cannot be joined to earlier ones.

Crash reports

A separate switch, off by default, and separate on purpose: helping with stability and being counted in product numbers are two different favours, and one control would have decided one of them for you.

Switch it on, or off again: Settings → Privacy → Share crash reports.

A crash report here is two words. If Kitchive stops unexpectedly, it writes one short line to a file on your device: which kind of crash it was, from a fixed list of seven, and which version of Kitchive it happened to. The next time you open the app that line is read, deleted, and — only if this switch is on — sent as the app_crashed event in the table above. Nothing else is captured: no stack trace, no error message, no memory, no screenshot, and nothing from your recipes.

That is deliberately less than a crash report usually means. Apple collects the detailed kind when you have turned on Share With App Developers in iOS Settings → Privacy & Security → Analytics & Improvements, and what it sends is governed by Apple, not by us. This is not a second copy of that; it is a count, so we can see that a particular release started crashing without waiting for Apple's reports.

The line is written to your device whether or not this switch is on, and it is read and deleted on the next launch either way. That is what stops a crash from months ago being sent as though it had just happened, the first time somebody turns the switch on. Nothing leaves the device unless the switch is on.

Some endings are not counted: if iOS closes Kitchive to reclaim memory, or you force-quit it, no line is written and nothing is reported. The number is therefore lower than the true one — chosen over treating every launch that followed an unclean shutdown as a crash, a bigger number that means nothing.

Hands-free cooking

Cook mode has a Hands-free switch, off until you turn it on. While it is on, the phone listens for a few spoken commands — "next", "repeat", "start timer" and the like — and reads steps aloud. The first time, iOS asks for the microphone and for speech recognition; decline either and hands-free stays off, and everything still works by touch.

What you say is recognized on the device and never leaves it. Kitchive uses Apple's on-device speech recognition only, and treats a language the device cannot recognize by itself as unavailable — it says so — rather than send the sound anywhere. No audio and no transcript is recorded, kept or sent: each phrase is compared with the commands and forgotten. The microphone is open only while hands-free is on in cook mode, and it stops when you turn it off, close cook mode, put the app in the background, or go ten minutes without a command. On recent iPhones, iOS may download its speech model for your language the first time; that download comes from Apple and carries nothing you said. The steps are read by the voices built into iOS, on the device.

Allergens and nutrition

A recipe's page shows the allergens its ingredient names mention, and the library's filter can hide the recipes that mention one. With Kitchive Pro the page also shows an estimate of the energy, protein, carbohydrates and fat in a serving. Both are worked out on the device, from a list of foods built into the app — the nutrition values come from USDA data — and from the recipe's own ingredient lines: nothing about the recipe is sent anywhere for them, and the results are held in memory while the app runs, not saved. Allergen detection is free; the nutrition estimate is part of Pro. Both are read from ingredient names only, so they are estimates, not medical or dietary advice — always check the labels.

Notifications

Cook mode can set timers that notify you when a step is done. These are local notifications scheduled on your device. Nothing leaves it, and Kitchive asks for permission before scheduling the first one.

This website

kitchive.app is a static website hosted by Vercel, which serves it from its network of servers around the world. When you open a page, Vercel processes what every web request carries — your IP address, the page you asked for, the time, and your browser's user agent — to deliver the page and to protect the site from attacks, on our behalf. The logs of this that Vercel makes available to us keep it for at most a day. The legal basis is our legitimate interest in a website that works and is secure (Art. 6(1)(f) GDPR).

The site sets no cookies, loads nothing from any other host — no fonts, no scripts, no analytics — and has one form, the contact form described under "The contact form"; an email link opens your own mail app.

If you write to us

If you email info@kitchive.app, we receive your address, what you write and anything you attach, and use them only to answer you. The legal basis is Art. 6(1)(b) GDPR when your message is about using the app or a purchase, and otherwise Art. 6(1)(f) — our interest in answering the people who write to us. The mailbox is hosted by Apple (iCloud Mail). We keep the conversation until your question is settled, and delete it 12 months after that, unless the law requires us to keep it longer.

The contact form

The contact form on this website is a second way to write to us. It asks for your email address and your message, and lets you add your name; a field that people never see tells it bots from people. When you send it, a small function on this website, run by Vercel in Frankfurt, Germany, checks the fields and hands them to Resend, an email service, which delivers them as an ordinary email to info@kitchive.app. That email's reply address is yours, so our answer comes from our mailbox like any other. We use what you send only to answer you. The legal basis is Art. 6(1)(b) GDPR when your message is about using the app or a purchase, and otherwise Art. 6(1)(f) — our interest in answering the people who write to us.

Resend (Plus Five Five, Inc., United States) delivers the message as our processor, under its data processing addendum, which is part of its terms and includes the European Commission's standard contractual clauses. It keeps its copy of the sent email for 30 days, the data retention of the Resend plan Kitchive uses. In our mailbox the message is kept like any email: until your question is settled, and deleted 12 months after that, unless the law requires us to keep it longer. To limit abuse, the function counts the messages sent from each IP address for ten minutes, in its memory only and under a salted hash that is never written down; its log says only whether a message went out — never your name, your address or what you wrote. The site itself stores nothing, and the form needs no JavaScript and sets no cookie.

Who receives what, and where

Recipient What for Where Their policy
Supabase Hosts Kitchive's server functions and their database, and keeps their logs (processor) US company; the project is hosted in London, United Kingdom (eu-west-2) supabase.com/privacy
OpenAI Reads an import with AI — the provider asked first (processor) United States openai.com/policies/privacy-policy
OpenRouter Reads an import with AI when OpenAI cannot answer, by passing it to the model provider it routes to (processor) United States openrouter.ai/privacy
Google Serves the Gemini model OpenRouter routes to (sub-processor) United States policies.google.com/privacy
RevenueCat Manages subscriptions: the launch-time check, purchases and restores, and the check on each AI import (processor) United States revenuecat.com/privacy
PostHog Anonymous usage data and crash counts, only if switched on (processor) Stored in Frankfurt, Germany; US company posthog.com/privacy
Vercel Hosts this website and runs its contact form (processor) United States; served worldwide, and the contact form runs in Frankfurt, Germany vercel.com/legal/privacy-policy
Resend Delivers a message sent with the contact form to info@kitchive.app (processor) United States resend.com/legal/privacy-policy
Apple The App Store and purchases, App Attest, optional iCloud sync and the shared shopping list, and the info@kitchive.app mailbox Apple's own services, under its own terms apple.com/legal/privacy
TikTok Its public oEmbed address, asked by your phone for the caption of a TikTok link you import its own controller tiktok.com/legal/privacy-policy
YouTube (Google) Asked by your phone for a YouTube link you import: the Data API and, if that does not answer, the watch page, as described above its own controller YouTube Terms of Service, policies.google.com/privacy
TheMealDB Looked up by dish name — and, when that finds nothing, by up to three ingredient names — from Kitchive's server, when a photographed dish becomes a recipe; receives no personal data — themealdb.com
Wikipedia (Wikimedia Foundation) Looked up by dish name from Kitchive's server, for the article's first paragraph; receives no personal data — wikimediafoundation.org/privacy
Wikidata (Wikimedia Foundation) Looked up by dish name from Kitchive's server, for the ingredients it lists for the dish; receives no personal data — wikimediafoundation.org/privacy
Spoonacular Only when Kitchive has it switched on: looked up by dish name from Kitchive's server, for recipes of the dish; receives no personal data — spoonacular.com/food-api/privacy

Beyond that table, the only other host this app ever contacts is a site you pasted or shared a link to, which your phone opens the way a browser would.

A processor works on Kitchive's behalf and under its instructions (Art. 28 GDPR). Kitchive uses each processor under its data processing terms; where a provider requires a separately signed agreement, Kitchive signs it before that provider receives personal data. Apple, TikTok and YouTube are not Kitchive's processors: what they receive, they handle under their own policies.

Transfers outside the EU. OpenAI, OpenRouter, Google, RevenueCat, PostHog, Supabase, Vercel and Resend are US companies, and what they process for Kitchive may be processed in, or accessed from, the United States. Each such transfer relies on the EU–US Data Privacy Framework where the company is certified under it (the European Commission's adequacy decision, Art. 45 GDPR), and otherwise on the European Commission's standard contractual clauses (Art. 46(2)(c) GDPR), which are part of each company's data processing terms; where those terms must be signed separately, Kitchive signs them before that company receives personal data. Write to info@kitchive.app for a copy of the safeguards that apply.

Nothing is sold, and nothing is shared with advertisers. Kitchive contains no advertising identifier and no tracking SDK.

Legal bases

Each kind of processing, and the GDPR article it rests on:

What Legal basis (Art. 6(1) GDPR)
Reading an import with AI — the text, photo or words you send, through Kitchive's server to OpenAI, or to OpenRouter and Google (b): it is the service you asked for — by your tap, or by the yes you gave for shared links
Fetching the page, TikTok's oEmbed caption and YouTube's API and watch page, from your phone (b): reading the link you asked to import
The device row, the counter row and the App Attest registration (b): providing the free imports or the Pro you use; and (f): our legitimate interest in an AI service that scripts and forged requests cannot use at our expense or turn against other users
The subscription check on each AI import, and the subscription claim (b): providing the Pro you bought; and (f), for the three-device bound: our interest in a subscription that cannot be multiplied
RevenueCat at launch (b) if you have bought Pro; otherwise (f): our interest in recognising a subscription you hold without making you restore it by hand, and in showing you the prices that apply
The address limits in the server's memory, Supabase's request logs and the server's own log (f): our interest in running a service that is secure and not abused
Anonymous usage data and crash reports (a): your consent — the two switches, off until you turn them on
This website's logs at Vercel (f): our interest in a website that works and is secure
The contact form's count of messages per IP address, as a salted hash in memory (f): our interest in a form that cannot be used to flood our mailbox
Answering your email, or a message from the contact form (b), or (f) as described under "If you write to us" and "The contact form"

You do not have to provide any of this. Without it, everything your phone does on its own still works; only AI import (which needs the server and the device row), Pro (which needs the subscription check) and the two optional streams depend on it. Where we rely on our legitimate interest, you may object (see "Your rights").

How long things are kept

What How long
Everything on your phone Until you delete it, or the app
The device row and its counter row Deleted once the installation has gone 13 months without the server seeing it
A subscription-claim row Deleted once it has gone 90 days unused (a device's place frees up after a day)
Service-wide daily counts (no device in them) Deleted after 400 days
Your address in the server's limits Only in one instance's memory, never written down — until the instance ends or newer addresses push it out
Supabase's request logs and the server's own log At most seven days
At OpenAI Up to 30 days, for abuse monitoring — longer only if the law requires it or it is reasonably necessary to protect OpenAI's services or a third party from harm; not used for training, and the answer is not kept for later use
At OpenRouter No fixed period is promised: OpenRouter keeps information as long as is reasonably necessary for its business and legal obligations (images no longer than routing needs, unless abuse detection, security, billing or the law requires more) and does not train on it; it passes requests only to endpoints that do not collect what they receive
At RevenueCat The purchase record of the anonymous identifier, for as long as Kitchive uses RevenueCat — it is what restores a subscription; the address is not kept
At PostHog At most one year — set by Kitchive's PostHog plan, and not shortened from Kitchive's side
This website's logs at Vercel At most a day in the logs available to us
Your address in the contact form's count A salted hash, only in the function's memory, for ten minutes — never written down
At Resend 30 days — the data retention of the Resend plan Kitchive uses
Your email, or a message from the contact form, in our mailbox Until 12 months after your question is settled, unless the law requires longer

Your rights

Under the GDPR you have the right:

To use any of them, write to info@kitchive.app. We answer within one month.

What we can and cannot find. Kitchive holds no record with your name, your email address or an account on it. The server rows are pseudonymous: they are filed under an installation's attestation key id, or a salted hash of it, and the app does not show you that id — so nothing you could send us lets us tell which rows are yours. Under Art. 11 GDPR we are not required to collect more information just to identify you, and Art. 15 to 20 then apply only if you give us information that does identify your data. What you can do yourself, at any time, without asking anyone:

"Delete all data" does not give you your free AI imports back. The count of imports used lives beside your settings on the phone and in the counter row on the server, keyed to this installation. Deleting the app resets both, because the next install registers a new attestation key.

You may complain to a supervisory authority. You have the right to lodge a complaint with a data-protection supervisory authority, in particular in the EU member state where you live or work or where you believe your rights were infringed (Art. 77 GDPR).

No automated decisions. Kitchive makes no decision based solely on automated processing that has legal or similarly significant effects on you (Art. 22 GDPR). The limits — five free imports, thirty a day, three devices — are the same rules for everyone, and decide only how many AI imports are left.

If you are in Türkiye (KVKK)

The Turkish version of this policy is also Kitchive's information notice under Article 10 of the Personal Data Protection Law No. 6698 (KVKK). In short:

The limits under "What we can and cannot find" apply here too: we can act on a server row only if what you tell us lets us find it.

Children

Kitchive collects nothing that would identify anyone, children included: there is no account to create, no profile, and no social feature. The two data switches rest on consent, so if you are under 16 — or under the age of digital consent where you live — switch them on only with a parent's permission.

Changes

If this policy changes in a way that affects what Kitchive collects, the change will be described in the app's release notes rather than quietly published here. What changed before, newest first:

Contact

Questions about this policy, or about anything Kitchive does with your information: info@kitchive.app, or the contact form. The postal address is under "Who is responsible", and the same details are on the site's support page and in its Impressum.