Privacy Policy

This English page is a support translation. The Turkish legal text prevails in case of inconsistency.

1. Controller

The data controller for iştebu! services is POİEX TEKNOLOJİ LİMİTED ŞİRKETİ. Company contact details are listed on the Company Information page.

Who is the controller for your data?

POİEX is also the independent data controller for the personal data of people who use iştebu! — not the organization you belong to (your employer, school, etc.). POİEX determines the purposes and means of processing this data under KVKK Article 3 in its own name. The organization you belong to runs a separate service relationship through iştebu! and acts as its own controller only for its own processes. KVKK Article 11 rights concerning this data on iştebu! are exercised directly against POİEX at privacy@istebuyemek.com.

2. Data we process

The AI-assisted dish workspace processes, linked to the acting authorized Seller-admin account, dish names and descriptions, recipe ingredient names and grams, recipe chat, assistant responses, response scope/model/prompt/provider-request metadata, and successive draft versions. OpenAI produces an energy estimate, food labels, and an illustrative dish image. This field is for dish/product information only; the admin is instructed not to enter information about a person or child, health data, or other sensitive personal data. The working draft and history are stored immediately. The admin can edit the entire draft, and nothing is applied to the dish catalog without final confirmation.

An in-app support thread contains its category and status, user and staff messages, source screen, app version, interface language, optional active-organization context, and private notes used by authorized POİEX operators. A message may include up to three JPEG, PNG, or WebP images together with filename, content type, and size. Images are re-encoded without cropping first on the device and then by the server, which validates the actual image bytes and removes EXIF/GPS metadata. Incomplete uploads are deleted from private Cloudflare R2 storage within one day; submitted images are held under a 30 MB total per-user support-image limit and opened only through short-lived signed links. The thread and public replies are visible only to you and authorized POİEX operators, not organization admins or Sellers. No email copy is created. A generic native push may announce a reply and link to the thread, but never contains the reply text.

The organization-lifecycle audit records the company’s onboarding, active, or inactive status; transition and timestamp; the acting POİEX operator, company admin, or Seller admin who activates the relationship; deactivation reason; and an operator note of up to 500 characters. If deactivation encounters open relationships, services, current/future assignments, or orders, the operator sees impact counts; a separately confirmed cleanup closes or removes those records atomically and records the removed counts in the audit. Assignments included in a settlement or containing a review are never removed through this flow. The note must not contain child, health, dietary, allergy, or other sensitive personal data.

For aggregate kitchen-demand forecasting, recent individual meal selections, each beneficiary’s roster join/end timestamps, and successful unique join-invite SMS sends from the preceding 96 hours are evaluated on demand. Failed or older sends and phones already represented by the matching active eater/guardian record are excluded. Person-level intermediate results exist only transiently during the request: they are not stored or shown to the Seller. The Seller sees only aggregate kitchen and dish quantities, never the phone numbers.

Only an active admin of the same organization can use People management to view active or ended organization enrollments for employees, admins, guardians, and students, including the record’s system creation and optional end timestamps, role, contact details, guardian relationship, and class/distribution group. When an account-backed meal beneficiary’s active membership in that organization ends, the active beneficiary enrollment also ends and its pre-deadline future selections are cancelled; the ended membership/beneficiary enrollment and historical meal and cost records remain under their existing audit, billing, and dispute-retention terms. Supported admin flows retain the acting user when available, the lifecycle source, and the prior enrollment link for a new or ended student meal enrollment; no actor is inferred retroactively for legacy records. A student’s ended and current enrollments share the child profile that preserves organization-scoped meal and cost history continuity. Person and student detail may show that organization’s weekly meals and costs; ratings, review labels, and review text are never attributed or shown there. This view creates no separate analytics or person-history record.

A school-family/student departure is separately previewed before confirmation, showing the students, guardian memberships, and pre-deadline future selections affected. Family confirmation atomically ends the selected member and every active student they guard in that school, together with local guardian links. Student confirmation reconciles each guardian’s remaining scope: another active student preserves guardian permission; an admin or active staff/self-eater keeps membership without guardian permission; otherwise the school membership ends. Pending child-scoped guardian invitations expire. Deadline-closed selections, historical meal/cost records, user accounts, other-organization memberships, and global child-profile guardian links remain.

For phone-based enrollment, the current People flow lets a company or school admin add one person or process up to 2,000 Excel rows in the browser, choosing “Add new people” or “Update full list”; the Excel file is not uploaded and the raw list is not retained. The single-person dialog first searches active and ended students, staff, or employees in the same organization; selecting a registered student shows current guardians and permits several new guardians in one submission. A school admin selects student/guardian and staff scopes separately, and a full-list sync in one scope does not affect the other. Company or school employees match by phone. Students match by whitespace-collapsed, Turkish-normalized full name, never by guardian phone. One exact name match is automatic; for duplicate names, the admin sees candidate class and active guardian names within their school and must choose—the system never guesses. In single-person enrollment, submitting an exact new or selected record validates a server state token and applies atomically without a separate second confirmation screen; a similar or ambiguous student match pauses for comparison and explicit confirmation. In the Excel flow, the preview shows every create, link, class/group update, roster ending, guardian-permission or membership effect, future-selection cancellation, and each masked SMS recipient with the exact rendered message before one atomic apply; unresolved or invalid rows block apply. Once applied, the membership and guardian relationship become active immediately. The SMS is informational, not an acceptance or authorization gate. A newly active membership receives the existing no-code login notice with the organization name, https://istebuyemek.com/app, and same-phone sign-in instruction; an existing active school member newly linked as guardian receives a relationship notice. The local outbox retains recipient, rendered body, queue/send state, provider message id or last error; queue/provider acceptance is not a handset delivery receipt. Add-only never removes a missing person. Full-list reconciliation ends missing active student/employee organization enrollments and cancels their open future selections. Local active guardian relationships of students leaving the roster end, while additional guardians of students who remain active survive even when omitted from the upload. An active student cannot be left without a guardian: guardians cannot remove children, and a school admin may remove one guardian only while another remains or may end the student. User accounts, memberships in other organizations, and historical records remain. Active admins are protected from staff and membership removal.

We process account and role data, phone-based login records, meal selections, cancellation and bulk-order records, delivery and billing-period data, invoice legal name, tax identifier, tax office, billing address, Seller payout IBAN, order totals, and the menu/assignment pricing snapshot (payout including VAT, effective PHB, Buyer total, VAT/fee components, and formula version), food business registration number and verification status, the Seller’s two verification documents (tax certificate and food business registration certificate) which — like the food registration number — are Seller compliance data stored in a private bucket, read only by our reviewer via short-lived links, and not disclosed to organizations, invoice number and evidence, the payment date, reporting account and report timestamp for a company-admin payment declaration and its optional privately stored PDF/image receipt, the rejection time, acting account and reason when a declaration does not match, settlement/collection/payout references, and — for the invoice-upload SMS sent to company admins — the recipient user/phone, rendered message, queue/send status, provider message id or last error, and invoice-scoped idempotency key. We also process support and privacy-rights messages, ratings and sentiment labels. A 1–3 star rating must include a negative label or non-blank note; 4–5 stars require neither. A free-text dish-review note remains optional, is shared with the Seller, and is shown back to you in your own history, but never to organization admins; because the note text can identify you, you are told it is shared with the Seller before you write it. We also process in-app product feedback you submit about the application itself (together with the screen it was sent from, the app version, and the interface language; stored only in the authorized POİEX operations console with no email copy, with your account link and phone number available so we can follow up if needed), uploaded avatars, organization logos, dish images, language and cookie preferences, backup records, cron monitoring metadata, masked diagnostic events, opt-in analytics data, and — at school-segment customers — a child/student’s name plus the meal selection, cancellation, rating, and review note a guardian enters on their behalf (no child health, dietary, or allergy data is processed; allergens are product information on dishes). Production web and native diagnostic events also contain the startup or tab-navigation milestone name and duration, application release and platform, and a route with its organization identifier replaced by a placeholder; those custom fields contain no name, phone number, meal, billing, or free-text business content. We also process the phone number, message content, referred school name, city, source organization (attribution only), and our response records when a school parent/guardian contacts us from inside the app to introduce iştebu! to another school their child attends; no child data is involved in that flow.

Meal-operation records also include whether a selection was manual or automatic, an explicit “not eating” choice and its authorized actor, the organization’s automatic-ordering policy and extra-meal percentage, and the cutoff finalization’s chosen menu/dish snapshot, status, and counts including the extra-meal quantity. An organization admin enables or disables automatic individual ordering through an impact preview and explicit confirmation. When enabled, an eligible beneficiary with neither a manual selection nor a not-eating record receives the most common valid exact manual combination across all menus after every deadline for that service-day closes. With no manual selection, the first complete valid combination whose contents are declared is used. If no complete valid combination exists, no automatic selections are created and printing is blocked. An admin may separately confirm one payable extra-meal percentage for all services. At cutoff it is applied once to the manual and automatic meal total, rounded up, and added as one billed system-sourced bulk order; zero disables it and later settings do not rewrite past orders. The source is shown in the app and on the physical label. Automatic-individual policy changes use the existing Vatansms and native-push channels for operational notice.

When a visitor starts a WhatsApp conversation from the floating contact button or an audience-specific company, school, or caterer contact page, we process the sender’s phone number, prefilled demo message, conversation content, and our response records. The in-app school-referral variant additionally carries the referred school, city, and source organization; neither website variant nor the referral includes child data.

For an admin-triggered meal-selection reminder we process the organization, service day, selected audience, acting admin, recipient user/phone, the first name of a still-missing child in a guardian message, the rendered SMS (organization name, long-form date and selection link), request identifier, queue/send state, provider message id, and last error.

For a delivery-terms change SMS we process the recipient user/phone, SMS-safety-normalized and length-bounded Seller and customer-organization names, rendered content carrying the current delivery and order-deadline times and the statement that existing meal selections did not change, queue/send state, provider message id, and last error.

On Android, if you accept the operating system’s one-message access prompt during login, the verification SMS is handed to the app only on the device. The app extracts the six-digit code and fills the login field; it does not retain the SMS body or send it to the iştebu! backend. Refusal, cancellation, timeout, or an unavailable system service leaves manual code entry available. This transient processing rests on contract establishment/performance and legitimate interest in secure, usable account access; it is not used for marketing and creates no new off-device transfer.

For native app installations, including before sign-in, mobile live updates process the app identifier and version, native build, platform, operating-system version, an Android random UUID generated for the installation and stored in app preferences, Apple’s identifierForVendor (IDFV) on iOS, installed bundle identifier, update channel, live-update plugin version, and IP address. Names, phone numbers, meal data, and billing content are not sent through this update flow.

When a signed-in native user reaches the first usable app screen, the app first shows an in-app explanation and opens the operating-system notification prompt only if the user explicitly chooses to enable notifications. On Android versions without a notification runtime prompt, registration likewise starts only after that explicit choice. We process an encrypted FCM registration token, a random installation UUID, the account association, platform, app/native version and build, locale, time zone, and last refresh time only for users who enable notifications. A send carries the notification title, body, in-app link, and provider acceptance/error metadata. Each current installation may receive a generic, lock-screen-safe reminder for a same-day delivered meal that is still unrated; the notification contains no child, dish, or organization name. Topics, Firebase Analytics, and BigQuery delivery export are not enabled.

For a Seller team invitation we process the inviting admin, organization, invited affiliation-only member role, invitation status and creation/expiry/redemption/revocation times, and the redeeming or revoking account. The intended teammate’s phone is normalized only transiently to create a nonce-bound keyed match inside the 72-hour link. The SMS includes a sanitized, length-bounded form of the inviting Seller’s display name and the invitation link; the platform persists neither the raw phone, create-request ID, phone-authentication tag, nor SMS body. The server stores the SHA-256 digest of the invite token, a boolean recording whether the synchronous SMS send call succeeded, and the organization, creator/redeemer/revoker, status, and timestamp audit. The boolean is not a handset delivery receipt.

After redemption, an active Seller team member’s name, verified phone, Seller organization, affiliation-only member role, membership status and timestamps, OTP/session records, and redeemer-side invitation audit are processed. This membership grants no operational or administrative access unless a current admin separately promotes the member.

A school creates and controls each student’s organization-scoped meal enrollment. A guardian membership or permission never copies that student into another organization. The first guardian may share an 8-character, single-use code valid for 72 hours; redemption links the second guardian only to the school and exact child named by the code, without a separate child-consent gate. Each organization admin sees only that organization’s enrollment and meal operations; a Seller sees only the minimum data needed for the meal it serves in that organization.

When an authorized POİEX operator deletes an inaccurate individual or bulk order, we retain an audit containing the acting operator and the deleted order’s date, meal service, recipient/orderer, quantity, menu, and dishes. Reviewed or invoice-settled orders cannot be deleted through this operation.

For a possible student match, when one name is a contiguous part of the other and the surnames match, the admin compares the current and Excel child names, class, and active guardian names with masked phones, then explicitly chooses same or different. An exact guardian name-and-phone match is recommendation evidence only, never an automatic merge. The admin may keep the current child name or explicitly update it to the Turkish-title-cased Excel name. An unresolved possible match is protected from full-list removal.

3. Purposes and processors

The AI-assisted dish draft is processed for contract performance and legitimate interest in accurate and efficient Seller-catalog operations, support and troubleshooting, and longitudinal product-quality evaluation. Recipe content and chat are sent to the OpenAI API; no web search is enabled, text responses are requested with store=false, and output is not applied to the dish catalog without human editing and confirmation. OpenAI is an overseas provider for this flow; its current transfer status is published on Sub-processors.

Organization-lifecycle records keep abandoned company accounts out of operational action queues, prevent unsafe activity while inactive, support an explicit return to onboarding, and preserve an accountable transition history. Processing rests on contract performance and legitimate interest in accurate, secure, and accountable service operations.

The distribution-group name is free text; the organization admin must not enter health, allergy, or dietary information in it.

An organization admin may assign a beneficiary to one distribution group, such as a class, age band, or department, to make handout easier. Names or phone numbers pasted for bulk assignment are compared transiently only with active beneficiaries in that organization; the raw list is not retained as a separate record. Exact unique matches, duplicates, missing people, and possible same-name matches are shown to the admin before any change. When active beneficiaries share a name, the admin also sees the candidates’ current group and active guardian names only in this preview to select the intended child. “Add listed people” skips unresolved rows and changes only matched people. “This is the full group list” cannot be applied until every row is resolved; once applied, it clears only the current group value of people absent from the list and does not change organization enrollment, guardianship, meal selections, headcount, billing, or history. Pasted phone numbers and guardian names shown for matching are not disclosed to the Seller. The current group appears with the name only in the authorized Seller print view and on the physical label; it is not derived from date of birth, must not be used for health or dietary information, is not copied into meal or billing history, and is not shown on the public QR page.

Aggregate kitchen-demand forecasting is part of corporate meal coordination and headcount operations. It rests on service performance, pre-contractual onboarding, and reliable-operation legitimate interest for adults, prospective members, and organization-managed student rosters.

When a Seller changes the delivery time or order-deadline offset on an active link, the system queues one current operational SMS for active members of the customer organization. The message identifies the Seller and customer organization with SMS-safety-normalized, length-bounded labels, shows the current delivery and order-deadline times, and says existing meal selections did not change. Delivery uses the existing Vatansms processor; the recipient, rendered message, and queue/provider records follow the retention terms of the related meal-coordination records. This processing rests on contract performance and legitimate interest in reliable service communication.

Data is used for secure login, corporate meal coordination, headcount, delivery, invoicing, collection, Seller payout settlement, support, privacy-rights handling, service quality, media storage, backup and disaster recovery, security, cron monitoring, error monitoring, and optional analytics. Current starter processors include Hetzner, Cloudflare, Cloudflare R2, Google Workspace, Sentry, Healthchecks.io, Microsoft Clarity, Vatansms, Paraşüt (e-invoicing/accounting), and WhatsApp/Meta. See Sub-processors for the current full list and the KVKK Article 9 transfer mechanisms. Organization admins access the operational data of their own organization (headcount, beneficiary selections — including the specific dishes each member chose for the day, never the price — name/phone, billing records). Sellers (food-service sellers) receive only the operational data needed to produce and deliver the meal: daily headcount, menu assignments, bulk-order line items, delivery location, the name needed for a beneficiary to find their own meal on the delivery label, and the current distribution group assigned by the organization admin, if any. The label shows the beneficiary’s first and last name plus the current distribution group, so boxes can be routed to the correct person and group at handout. The beneficiary’s phone number and email address are not shared with Sellers. The QR code on the delivery label contains an unguessable, unique link to that meal’s info page; the page opens without login for whoever holds the link, shows no more personal data than what is already printed on the label (first name, that day’s meal selection, the Seller’s name, date, and delivery time) plus the dishes’ declared food information (description, allergens, dietary tags, special warnings, energy — product information, not personal data), and allows a one-time rating of the meal for 24 hours after delivery. It contains no price, phone number, or other contact details. This 24-hour upper bound applies only to the unauthenticated QR link; signed-in users and guardians may later rate any delivered, previously-unreviewed own or child meal in the app, still only once. The QR on the box label of a bulk-ordered meal works the same way; that page shows no beneficiary identity — only the ordering organization’s name and that day’s dishes — and allows one rating per box without login. A bulk-box rating is linked to no person, so it carries no personal data and no identity link to erase. So the Seller can issue the food invoice, the billing identity of the organization it is actively linked to (legal name, tax identifier, tax office, billing address) is disclosed to that Seller; the intermediation invoice and collection run through POİEX. Once a Seller’s verification is complete, its seller identifying information (trade title and tax identifier/VKN) is shown publicly on the marketplace and to actively linked client organizations in the app, as required by the seller-transparency obligation under Law No. 6563 and Article 5 of the E-Commerce Regulation; the Seller’s food business registration number remains internal compliance data and is not disclosed to clients. When a parent/guardian uses the in-app card for a school referral, the prefilled message they choose to send is transported over WhatsApp/Meta infrastructure outside Turkey; the legal basis is pre-contractual steps at the data subject’s own request and legitimate interest in answering inbound sales inquiries (KVKK Article 5/2-c and 5/2-f). Because the parent/guardian initiates the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message under Law No. 6563 / İYS; no child data is shared, and any later marketing message back to the parent/guardian would require separate explicit consent.

The floating contact button opens a generic prefilled message in the WhatsApp Business line. Demo links on the company, school, and caterer pages first route to a contact page that shows the cross-border-transfer notice, then open the relevant audience-specific WhatsApp message. Opening a link does not itself send the message. If you choose to send it, your phone number, message, and our replies transit WhatsApp/Meta infrastructure outside Turkey. This processing rests on pre-contractual steps at your request and legitimate interest in responding to the inbound sales inquiry (KVKK Article 5/2-c and 5/2-f). The same basis applies to the in-app school-referral card, which shares no child data. Because you initiate the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message; unrelated later marketing requires separate explicit consent.

For an open lunch day, an authorized organization admin may independently select still-missing self-eaters and guardians, preview the message, and confirm an operational reminder. Recipients are recomputed within that organization at send time; one account missing both its own and a child’s selection receives one combined SMS. A new explicit confirmation may send another SMS even when an earlier reminder exists; only a retry with the same sender-scoped request identifier is deduplicated. Delivery uses the existing Vatansms processor. The audit and delivery fields above follow the retention terms of the related meal-coordination records. This processing rests on contract performance and reliable-service legitimate interest for the organization’s meal operations and admin audit data.

When a Seller records a food-invoice PDF, the app creates an in-app payment action and queues one operational SMS through the existing Vatansms processor for each active company admin. The SMS contains a sanitized, length-bounded Seller display name, the number of covered settlements, the invoice gross amount, and a prompt to review payment details in the app. The recipient user/phone, rendered message, queue/send status, provider message id or last error, and invoice-scoped idempotency key are retained as billing-related records; this is not a handset-delivery confirmation.

Billing records also include the company admin’s designated-buyer declaration and the invoice’s withholding rate, code and threshold, withheld VAT, and bank-payable amount. The declaration is off by default and applies only to reconciliations that have not yet been invoiced. For food invoices dated in 2026, if the VAT-inclusive total of the completed weeks selected by the Seller for one invoice exceeds TRY 12,000, the system freezes the 5/10 rate, food-service withholding code 604, withheld VAT, and bank-payable amount on the invoice and each week. The invoice gross does not change: the Buyer pays gross less withheld VAT through the bank channel and declares/pays the withheld part through VAT 2. A later declaration change does not rewrite an issued invoice, collection, or payout record; a withholding invoice is blocked until the threshold for a new tax year is configured.

After an EFT/bank transfer, a company admin may record the payment date and an optional receipt in the app. The reporting account and report timestamp are recorded automatically; an uploaded receipt is stored in private Cloudflare R2 object storage and opened only through a short-lived authorized link. This is an operational bank-verification signal, not confirmation of collection, debt discharge, or authorization of the Seller payout. If a declaration does not match the bank record, its rejection time, acting account, and reason are retained with the prior declaration and reporting is opened again.

Capawesome Cloud (Genz IT Solutions GmbH) receives only the technical update-delivery data listed above to check native compatibility, deliver signed bundles, measure adoption, diagnose delivery, and support rollback. The EU endpoint is configured. Capawesome operates from Germany and uses some United States sub-processors; the KVKK Article 9 safeguard for this transfer is not yet completed. This processing rests on pre-contractual steps before sign-in, contract performance for signed-in users, and legitimate interest in secure service delivery and continuity.

After the user signs in, completes any required welcome steps, and reaches the first usable app screen, the app first shows an in-app explanation. The operating-system native push prompt opens only if the user chooses to enable notifications; on Android versions without a notification runtime prompt, registration is still created only after that explicit choice. Google LLC’s Firebase Cloud Messaging receives the Firebase installation ID, target registration token, and notification payload to deliver an operational notification to that exact installation; FCM uses APNs for the iOS transport. The capability-test TTL is one hour; a pending rating reminder expires at the relevant organization’s local midnight, and an operator-confirmed service announcement expires after 24 hours. Processing rests on contract performance and legitimate interest in reliable service communication, and is not used for marketing. The KVKK Article 9 safeguard for the United States/global infrastructure transfer is not yet completed.

An authorized POİEX operator may combine one direct phone number already lawfully held for a current service or support relationship with the active eater, guardian, and admin audiences of one selected organization. The console previews deduplicated recipient/device counts and queues SMS and/or native push only after the operator records an internal reason and explicitly confirms both that the message is operational rather than marketing and, when a direct number is entered, that it is lawfully held for that current relationship. A direct number without an account is SMS-only; push is limited to current installations that the user enabled. The batch audit stores the message title/body, internal reason, actor, organization, audience flags, confirmations, counts, and deduplication hashes but not the direct phone or recipient list. Each SMS outbox row stores its phone/body snapshot and provider state; account erasure scrubs those fields on rows linked to that user. Terminal push delivery rows are deleted after 90 days. Operators are instructed not to include child, health, allergy, dietary, or other sensitive personal data. This processing rests on contract performance and reliable service/support communication legitimate interest for enrolled users, and on pre-contractual steps at the person’s request and customer-support legitimate interest for a current direct contact. It is not used for marketing or unsolicited commercial electronic messages.

The main legal-basis groups are: OTP/session records for account access and security under contract and legitimate interest; meal, delivery, headcount, and feedback records for service performance and quality; onboarding an intended Seller teammate as an affiliation-only member and maintaining that membership lifecycle under performance of the Seller service and pre-contractual onboarding, plus legitimate interest in secure, accountable team access; organization-managed student enrollment and guardian-proxy meal coordination under performance of the customer service and legitimate interest in an accurate, reliable school meal roster; support/demo messages for pre-contractual requests, contract performance, and customer-support legitimate interest; privacy-rights request records for legal obligation; and media uploads, backups, and diagnostics for service operation, security, and continuity.

Seller team-invitation creation and redemption requests are processed through the existing application infrastructure by Hetzner and Cloudflare. A sanitized, length-bounded form of the inviting Seller’s display name and the invitation link are sent with the target phone by SMS through the existing Vatansms processor; no new processor is used, and the platform does not persist the raw phone or rendered SMS body. The invitation record contains only a boolean indicating whether the synchronous SMS send call succeeded; this is not a handset delivery receipt. Only an account verified with the same phone can redeem the invitation. Redemption grants an affiliation-only member role with no menu, client, kitchen, delivery, billing, payout, or team-administration access; a current admin may grant admin access later through a separate role-promotion action.

Some infrastructure, storage, business email, monitoring, analytics, and messaging providers operate outside Turkey, primarily in Germany, the United States, Latvia, and Ireland. The KVKK Article 9 cross-border safeguards (Board adequacy decision, Standard Contractual Clauses notified to the Board within 5 business days, written undertaking, or Binding Corporate Rules) are currently being put in place for the affected processors. This page and the company’s records will be updated as each safeguard is recorded.

4. Retention

The original paste, complete recipe chat, assistant-response metadata, and successive draft versions are currently retained in the application database without a scheduled deletion period, including after confirmation. The proportionality, definite retention period, and legal basis for this indefinite retention must be validated by counsel before production use. A confirmed recipe and generated dish fields remain on the dish until replaced or no longer needed for the active service relationship. Cost/usage audit rows separately keep provider request metadata and token/image counts. OpenAI may retain API inputs and outputs in default abuse-monitoring logs for up to 30 days unless law requires longer.

Organization-lifecycle audit records remain for the active customer period, or for 10 years when tied to billing, an access dispute, or a legal record.

Retention depends on purpose: refresh sessions last 7 days, cookie consent lasts 6 months, language preference lasts 1 year, error/replay diagnostics last 90 days, private database backups rotate after 30 days, cron monitoring records remain for the active service account and may remain in provider backups for up to 2 months, Clarity analytics may last up to 13 months, active-customer support records and in-app product feedback are retained for the active customer period plus 2 years unless tied to legal or billing records, WhatsApp demo and school-referral inquiries are retained for 1 year, and invoice/legal records are retained for 10 years. A Seller team invitation is accepted by the server for no more than 72 hours; its browser-session copy lasts until redemption, explicit clearing, or the relevant tab session ends. The intended person’s raw phone and keyed match are not retained on the server; the authorization audit containing the organization, inviting/redeeming/revoking account, status, timestamps, and SMS send-success confirmation is retained for the active customer period, or for 10 years when tied to a billing, access-dispute, or legal record. The send-success confirmation is not a handset delivery receipt. Uploaded images remain until replaced, deleted, or no longer needed for the active service relationship. Where a dispute, security incident, or legal obligation applies, the relevant records may be retained for as long as necessary. These are the retention periods for which the relevant data is kept; in-app personal records are retained for the service relationship and statutory retention obligations, and are removed when that obligation ends or when you delete your account, on the schedule described in Section 5.

Capawesome delivery metadata and inactive update bundles are retained for 30, 60, or 90 days under the active plan (90 days maximum). After service termination, active-system data is deleted after a 30-day export period; immutable backups rotate within 30–90 days.

Our push registration is deleted when the app next opens or returns to the foreground after notification permission is disabled in operating-system settings, when the user logs out or closes the account, when the provider reports an invalid token, or when the registration has not refreshed for 30 days. Terminal push-outbox rows are deleted after 90 days. Firebase states that it retains Firebase installation IDs until the customer invokes its deletion API and removes them from live and backup systems within 180 days after that call.

5. Account deletion and what is kept afterwards

When account-erasure processing runs, image-attachment records from that user’s support threads and their private object-storage files are deleted. The de-identified thread text may remain under the support-history period because visual content cannot be reliably anonymized.

After lifecycle guards pass, starting the in-app “Delete my account” flow closes your account immediately: your sessions are revoked, the account can no longer be signed into, your active memberships are ended, in-progress (pre-deadline) meal selections are cancelled, your server-side native push registration is deleted, and your phone number is detached from the account so the same number can be reused for re-registration (the in-app record is replaced with an anonymous sentinel).

This account-closure flow also covers an active affiliation-only Seller team member and ends that Seller membership. The requirement to appoint another admin does not apply to this role; it applies only if the member was previously promoted and has become the organization’s sole active admin.

Your personal data is not yet destroyed at the moment of closure: your name, profile image (including the image file in object storage), the phone-number record, the technical fields on consent records (IP address, device), the content of SMS messages sent to you, and the free-text notes you added to dish reviews continue to be stored with access closed, for the purpose of proving that the underlying transactions were real and of establishing, exercising, or protecting a legal right (KVKK Article 5/2-e). This data is deleted or anonymized in the periodic destruction cycle following closure (within six months at the latest). If you want your data destroyed sooner, a KVKK Article 7 request to privacy@istebuyemek.com is completed within 30 days at the latest.

When the deletion is processed (on request or in the periodic destruction cycle): your name, phone number, profile image, and the technical fields on consent records are erased; the eater (meal-subject) name on your meal records is also stripped. Past meal selections, bulk orders, ratings, and billing-related records are retained — with the identity link cut — for the statutory retention period required by Vergi Usul Kanunu m. 253 and Türk Borçlar Kanunu m. 146. They appear as “Anonymous user” in any per-person historical view; aggregate billing, headcount, and quality analytics are unchanged. Consent records’ existence and timestamps are retained for audit; personal fields are scrubbed. Free-text product feedback you submitted about the application is retained to improve the product; when the deletion is processed the identity link is cut (the feedback’s link to your account is removed) and the text itself is kept. The free-text note you added to a dish review is scrubbed (its content cleared); the review record itself is not deleted but retained anonymized, with the identity link cut, together with the structured star rating.

The meal selections, ratings, and review notes entered for a child are kept for the service relationship. A guardian cannot remove the child, and the last guardian relationship of an active student cannot end. A school admin may remove one guardian while another remains or end the student enrollment. If an account is the sole guardian of an active student, in-app account closure or organization departure is refused until the school links another guardian or ends the student; a written KVKK Article 7 request remains separately processed within 30 days with school coordination. The guardian exercises the child’s KVKK rights and may write to privacy@istebuyemek.com; historical child-consent records are retained as audit history but no longer gate meal operations.

Guardian-initiated account closure or school departure remains subject to the existing lifecycle guard while the account is an active student’s sole guardian. A school admin may instead complete the family departure through the impact preview above without leaving an active student guardianless; this does not erase the child’s identity and does not replace the written KVKK Article 7 process.

If you are the sole active admin of an organization, the deletion may be refused until another admin is appointed. This is not a refusal of your KVKK Article 7 right; it is a procedural prerequisite to protect other users’ access to a paid service.

You can keep using iştebu! on your own after your organization’s contract ends, delete your account at any time, or rejoin with another organization using the same phone number.

6. Contact

The personal-data export generated for your authenticated account includes your account details, active and ended memberships, and Seller team-invitation audit rows tied to you as creator, redeemer, or revoker. An invitation row shows the SMS send-success confirmation but contains no raw target phone, create-request ID, phone-authentication tag, invite token, or SMS body. An affiliation-only Seller team member is included in this scope.

Privacy questions and data protection rights requests can be sent to privacy@istebuyemek.com.