KVKK Disclosure Notice

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

1. Data controller

The data controller is POİEX TEKNOLOJİ LİMİTED ŞİRKETİ. Contact details are available 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 requests concerning this data on iştebu! are addressed directly to POİEX through the channel listed in section 5.

2. Data subjects and categories

For an authorized Seller admin, the AI-assisted dish workspace processes, linked to the acting admin account, the entered dish name and description, ingredient names and grams, recipe chat, assistant responses, response scope/model/prompt/provider-request metadata, and successive draft versions, together with the energy estimate, food labels, and illustrative dish image generated by OpenAI. The field is limited to dish/product information and instructs the admin not to enter information about a person or child, health data, or other sensitive personal data. The original paste, chat, and draft versions are retained in the application database without a scheduled deletion period, including after confirmation. A confirmed recipe and dish fields remain until replaced or no longer needed for the active service relationship. Cost/usage audit rows separately retain provider request metadata and token/image counts.

For users who open an in-app support request, the processed categories include the request category and status, user and support-team messages, up to three attached JPEG, PNG, or WebP images with filename, content type and size, source screen, app version, interface language, optional active-organization context, and private internal notes of authorized POİEX operators. 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 conversation remains between the user and authorized POİEX operators; organization admins and Sellers cannot access it. A generic native push without the reply text may link the user to the conversation.

An active admin of the same organization may view active or ended organization enrollments for employees, admins, guardians, and students for organization management, including the record’s system creation and optional end timestamps, role, contact details, guardian relationship, and class/distribution group. The single-person dialog searches active and ended records within that organization; an admin may submit one or more guardians for a selected active student. An exact selection is validated by a server state token and applied atomically without a separate second confirmation screen, while a similar or ambiguous student match pauses for comparison and explicit confirmation. An admin may remove one guardian while another active guardian remains or end the student. 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 only that organization’s weekly meals and costs. Ratings, review labels, and review text are never attributed or shown on these pages. No separate analytics record is created for this purpose.

A school admin may preview and confirm the student, guardian/membership, and pre-deadline future-selection effects of a family departure. Confirmation ends the selected member and every active student they guard in that school, together with the local guardian links, in one transaction. When one student leaves, every guardian’s remaining scope is reconciled: another active student preserves guardian permission; an admin or active staff/self-eater keeps membership without guardian permission; otherwise the school membership ends. Deadline-closed selections and historical meal/cost records remain.

When an authorized POİEX operator deletes an inaccurate individual or bulk order, the audit records the acting operator and the deleted order’s date, meal service, recipient/orderer, quantity, menu, and dishes. An order with a submitted review or settled invoice cannot be deleted through this operation.

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.

Aggregate kitchen-demand forecasting evaluates recent individual meal selections, each beneficiary’s roster join/end timestamps, and successful unique join-invite SMS sends from the preceding 96 hours when the phone is not yet represented by the matching active eater/guardian record. Failed or older sends are excluded. Person-level intermediate results exist only transiently during the request: they are not stored or disclosed to the Seller, which sees only aggregate kitchen and dish quantities.

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

For a delivery-terms change SMS, categories additionally include 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.

iștebu! processes data relating to website visitors, unauthenticated native app installers, organization admins, beneficiaries, Seller (food-service seller) admins, prospective Seller team members, active affiliation-only Seller team members, prospects, support contacts, privacy-rights requesters, and — at school-segment customers — children/students (an account-less eater whose name, optional class/distribution group, meal selection, cancellation, rating and optional dish-review note are processed) and their guardians (whose name, phone, school membership, and actions for the child are processed). No health, dietary, or allergy data is processed about a child — allergens are product information on dishes, not person-linked health data. In the current People flow, a company admin may add one employee or up to 2,000 Excel rows containing the required phone, optional account name, and optional existing distribution group. A school admin may add one student with one or more guardian phones, or up to 2,000 rows containing the required child name and guardian phone, optional guardian name, and optional existing class/distribution group. The pasted table is processed transiently for preview and apply and is not retained separately. Enrollment creates no meal selection or headcount, and an optional employee or guardian name fills only an entirely blank account name. Supported older clients may continue to provide a phone-only selected-scope roster during the compatibility window. Separately, an active Seller admin may enter the intended teammate’s phone for an affiliation-only team invitation. That 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, member role, creator/redeemer/revoker, status, and timestamp audit. The boolean is not a handset delivery receipt. After redemption, the active 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 role has no menu, client, kitchen, delivery, billing, payout, or team-administration access unless a current admin separately promotes the member. Categories also include identity, phone number, email address, role, organization, meal selections, delivery and billing records, invoice legal name, tax identifier, tax office, billing address, Seller payout IBAN, order totals and menu/assignment pricing snapshots (payout including VAT, effective PHB, Buyer total, VAT/fee components, and formula version), food business registration number and verification status, the Seller’s verification documents (tax certificate and food business registration certificate, stored privately and not disclosed to organizations), invoice evidence, a company-admin payment declaration’s payment date, reporting account, report timestamp and optional privately stored PDF/image receipt, the rejection time, acting account and reason when a declaration does not match, settlement/collection/payout references, support and privacy request messages, verification and response records, ratings and sentiment labels. A 1–3 star dish 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, shown back to the author, and not shown to organization admins. Categories also include in-app product feedback about the application itself (with the screen it was sent from, the app version, and the interface language), uploaded avatars, organization logos, dish images, cookie choices, device data, backup records, cron monitoring metadata, diagnostic events, and security logs. A school parent/guardian may also contact us from inside the app to introduce iştebu! to another school their child attends; for this inbound inquiry we process their phone number, message content, referred school name, city, source organization (attribution only), and our response records, and no child data is involved.

For production web and native diagnostic events, the categories also include the startup or tab-navigation milestone name and duration, application release and platform, and a route with its organization identifier replaced by a placeholder. These custom performance fields contain no name, phone number, meal, billing, or free-text business content.

At a school, the administrator may alternatively select a staff scope with the same employee fields: required phone, optional account name, and optional existing distribution group. Staff and student/guardian scopes are previewed and applied separately.

A landing visitor may initiate a WhatsApp conversation from the floating contact CTA or an audience-specific company, school, or caterer contact page. For that inquiry 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 native app installations, including before sign-in, live-update delivery processes 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. This flow carries no name, phone number, meal data, or billing content.

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. Only for users who enable notifications do we process an encrypted FCM registration token, random installation UUID, account association, platform, app/native version and build, locale, time zone, and last refresh time. A send includes 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.

On Android, if the person signing in accepts the operating system’s one-message access prompt, the verification SMS body is processed transiently only in device memory. The app extracts the six-digit code and fills the login field; it does not retain the message or send it to the iştebu! backend. Refusal, cancellation, timeout, or an unavailable system service leaves manual entry available.

A school creates and controls each student’s organization-scoped meal enrollment. Guardian membership or permission never copies that student into another organization. A child-scoped code links a 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 that organization’s meal.

Meal-operation data also records 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 selected menu/dish snapshot, status, and counts including 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 choice nor a not-eating record receives the most common valid complete combination across all menus after all service-day deadlines. If there is no manual choice, the first complete valid combination with declared contents is used. If none exists, no automatic selection is 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. This processing uses the existing legal bases, recipients, and retention period for meal coordination and introduces no new processor or sensitive-data category.

3. Purposes, legal basis, and transfers

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 output is requested with store=false, and no output is applied to the dish catalog without the admin’s editing and confirmation. The proportionality, definite retention period, and legal basis for retaining the original paste, chat, and draft versions indefinitely must be validated by counsel before production use. OpenAI may retain API inputs and outputs in default abuse-monitoring logs for up to 30 days unless law requires longer. OpenAI, L.L.C. operates on United States/global infrastructure; its KVKK Article 9 safeguard is not yet complete and the current status is published on Sub-processors. The system does not add a user’s name, phone, organization name, meal selection, employee, guardian, or child record to this flow.

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 support accurate handout. A name or phone list entered for bulk assignment is compared transiently only with active beneficiaries in that organization and is not retained as a separate record. Before any change, the admin sees exact unique matches, duplicates, missing people, and possible same-name matches. When active beneficiaries share a name, the candidates’ current group and active guardian names are shown only in this preview so the admin can select the intended child. Add mode skips unresolved rows and changes only matched people; full-list mode cannot be applied until every row is resolved and then clears only the current group value of people absent from the list. It does not change organization enrollment, guardianship, meal selections, headcount, billing, or history, and entered phone numbers and guardian names shown for matching are not transferred to the Seller. The current group appears with the beneficiary 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 historical meal or billing records, and is not shown on the public QR page. This processing relies on contract performance and legitimate interest in accurate delivery.

This aggregate forecast supports meal coordination and headcount operations. The processing rests on contract performance, pre-contractual onboarding, and reliable-operation legitimate interest for adults, prospective members, and organization-managed student rosters. No phone number is disclosed in the result, and no new processor or person-level recipient is introduced.

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 Turkey-based Vatansms processor. The recipient user/phone, rendered body, queue/send state, provider message id or last error, and event-scoped idempotency key are retained with the related meal-coordination records. This processing rests on contract performance and legitimate interest in reliable service communication.

In the current People flow, an authorized company or school admin may 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 records in the same organization; selecting a registered student shows current guardians and permits several new guardians in one submission. 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, direct link, class/group update, roster ending, guardian-permission or membership effect, future-selection cancellation, and every masked SMS recipient with the exact rendered message before one atomic apply; invalid or unresolved rows block it. Once applied, the membership and guardian relationship become active immediately. The SMS is informational and not an acceptance gate. A newly active membership receives the no-code Vatansms login notice with the organization name, https://istebu.app/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; 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. The roster and child meal coordination processing rests on performance of the customer service and legitimate interest in accurate, limited and reliable meal operations.

The separate family/student departure flow shows the affected students, guardian memberships, and pre-deadline future selections before confirmation. Family confirmation atomically ends the selected member and every active student they guard in that school; student confirmation ends the student and any last guardian’s school membership only when that guardian has no other active scope. User accounts, memberships in other organizations, deadline-closed selections, and historical records remain.

At a school, staff and student/guardian are separate full-list scopes; reconciliation in one does not affect the other. School staff are matched by phone, and active admins are protected from staff-roster removal.

Mobile live-update technical records are collected electronically when the native app checks for updates at startup and in the background. They are processed under pre-contractual steps before sign-in, contract performance for signed-in users, and legitimate interest in secure service delivery, continuity, diagnostics, and incident recovery.

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; FCM uses APNs for iOS delivery. This processing rests on contract performance and legitimate interest in reliable service communication and is not used for marketing. 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. The KVKK Article 9 safeguard for the United States/global infrastructure transfer is not yet completed.

For Android OTP AutoFill, the message body is collected on-device only after the person accepts the operating system prompt for that one verification request and is discarded after code extraction, cancellation, or timeout. The processing rests on contract establishment/performance and legitimate interest in secure, usable account access. The operating-system prompt is a technical device-access choice, not marketing consent. This flow sends the message body neither to the iştebu! backend nor to a new recipient.

Data is collected electronically through the website, app, OTP flow, organization actions, image uploads, support messages, privacy-rights requests, business email, and system logs. Processing is based on contract performance, pre-contractual steps, legal obligation, legitimate interest in customer support, security, service reliability, and explicit consent for optional analytics cookies. An active Seller admin enters the intended teammate’s phone in the app; the server normalizes it transiently, binds it to a 72-hour invitation, and does not persist it. A sanitized, length-bounded form of the inviting Seller’s display name and the invitation link are sent by SMS through the existing Vatansms processor; the platform does not persist the raw phone, create-request ID, phone-authentication tag, or rendered SMS body and records only a boolean indicating whether the synchronous SMS send call succeeded. This boolean is not a handset delivery receipt. The recipient verifies the same phone through the existing OTP flow and explicitly redeems 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. This processing rests on performance of the Seller service and pre-contractual onboarding, plus legitimate interest in secure, accountable team access. In the current People flow, an authorized school or company admin enters one person or up to 2,000 Excel rows. The single-person dialog first searches active and ended records within the same organization. Submitting an exact new or selected record performs transient server-side preview and state-token validation, then applies atomically without a separate second confirmation screen; a similar or ambiguous student match pauses for comparison and explicit confirmation. The Excel table is processed transiently for preview and the selected add-only or full-list apply and is not retained as a separate list. Each Excel row remains visible as ready, unchanged, or invalid; duplicate rows, invalid phones, and unknown groups block apply. New phones become active members directly; a no-code SMS containing the organization name, https://istebu.app/app, and same-phone login instruction is queued through Vatansms. Supported older clients may, during the compatibility window, enter a phone-only list for exactly one scope: guardians, school self-eaters, or company employees. It is compared transiently only with active relationships in that scope. Matching people receive no duplicate SMS, and whether a valid phone has an account or membership elsewhere is not disclosed. In that compatible flow, “Add only” removes nobody and “Full list” automatically ends eligible relationships missing from the confirmed list after preview while preserving roles outside the selected scope. Separately, an authorized POİEX operator may combine one direct phone number lawfully held for a current service or support relationship with the active eater, guardian, and admin audiences of one organization. The console previews deduplicated recipient/device counts and queues SMS and/or user-enabled native push only after an internal reason, explicit non-marketing confirmation, and—when a direct number is entered—confirmation that it is lawfully held for that current relationship are recorded. An unknown direct number is SMS-only. The batch audit stores message content, reason, actor, organization, audience flags, confirmations, counts, and deduplication hashes, but no direct phone or recipient list; the required SMS row holds its phone/body snapshot and provider state. Linked SMS phone/body fields are scrubbed on account erasure, and terminal push-delivery rows are deleted after 90 days. Operators are instructed not to enter child, health, allergy, dietary, or other sensitive personal data. The 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 floating landing-site CTA and the in-app school-referral card open a prefilled message to the WhatsApp Business line that the person chooses whether to send. The phone number, message, and response records are collected electronically under pre-contractual steps at the person’s request and legitimate interest in responding to inbound sales inquiries (KVKK Article 5/2-c and 5/2-f).

For an open lunch day, an authorized organization admin can independently select still-missing self-eaters and guardians, preview the message, and confirm an operational reminder. Recipients are recomputed only within that organization at send time; one account missing both its own and a child’s selection receives one combined SMS, and a guardian message contains the still-missing child’s first name. A new explicit confirmation can send another SMS even when an earlier reminder exists; only a retry with the same sender-scoped request identifier is deduplicated. The existing Vatansms processor delivers the SMS. The acting admin, organization, day, audience, recipient user/phone, rendered body, and queue/provider-error fields are retained. Processing rests on performance of the customer service and legitimate interest in reliable meal operations.

When a Seller records a food-invoice PDF, contract performance and the legal obligations tied to invoicing and collection support an in-app payment action and one operational SMS per active company admin through the existing Vatansms processor. The SMS carries a sanitized, length-bounded Seller name, the covered-settlement count, the invoice gross amount, and a prompt to review payment details in the app. The recipient user/phone, rendered SMS body, queue/send status, provider message id or last error, and invoice-scoped idempotency key are retained with the billing record; this is not a handset-delivery confirmation.

Invoice/accounting data also includes the company admin’s designated-buyer declaration; the withholding rate, code and threshold; withheld VAT; and the 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 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. This processing rests on contract performance and tax/invoicing legal obligations.

After an EFT/bank transfer, a company admin may enter the payment date and an optional PDF/image receipt. Contract performance, operational collection verification, and legal recordkeeping support processing the reporting account, automatic report timestamp, payment date, and receipt. A receipt is stored in private Cloudflare R2 object storage and opened only through a short-lived authorized link. The declaration is not bank-collection confirmation, debt discharge, or authorization of the Seller payout. If the 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.

The activity-level mapping is: website and cookie preferences rely on necessary service operation or explicit consent for Microsoft Clarity; authentication/session records rely on contract establishment/performance and account-security legitimate interest; meal operations, organization-managed student enrollment, authorized guardian actions, and feedback rely on customer-service performance and reliable-operation/service-quality legitimate interest; billing, collection, and Seller payout settlement rely on contract performance and legal obligation; media uploads rely on service performance and operation; support and privacy requests rely on pre-contractual steps, contract performance, legal obligation, and customer-support legitimate interest; backups, cron monitoring, and diagnostics rely on service continuity and security.

Mobile live-update records are used to check native compatibility, deliver signed bundles, measure adoption, diagnose delivery, and support rollback.

Data may be shared with organization admins, Sellers, hosting and security providers, object storage and backup providers, business email providers, SMS providers, cron-monitoring providers, error-monitoring providers, analytics providers, accounting, legal, and public-authority recipients when necessary. Current 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. All listed processors except Vatansms and Paraşüt operate outside Turkey, which triggers a cross-border transfer; Vatansms and Paraşüt are based in Turkey. The KVKK Article 9 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. Sellers (food-service sellers) receive only an operational subset: daily headcount, menu assignments, bulk-order line items, delivery location, and the name needed for a beneficiary to find their own meal on the delivery label. The label shows the beneficiary’s first and last name, so that boxes are not mixed up between people who share a first name 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 (e.g. by physically seeing the label); the personal data it shows is no more than what is already printed on the label (first name, that day’s meal selection, the Seller’s name, date, and delivery time), and it additionally shows the dishes’ declared food information (description, allergens, dietary tags, special warnings, and energy — product information, not personal data). The same page 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 under KVKK Article 7. 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.

Mobile live-update technical data is transferred to Capawesome Cloud (Genz IT Solutions GmbH) for the purposes above. The EU endpoint is used. Capawesome operates from Germany and uses some United States sub-processors; the KVKK Article 9 safeguard for this transfer is not yet completed.

Google LLC (Firebase Cloud Messaging) is the native push delivery processor. It receives the Firebase installation ID, target registration token, and notification payload; iOS delivery continues through APNs. An operator-confirmed service announcement expires after 24 hours.

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 it. If the visitor chooses to send it, their phone number, message, and the response conversation transit WhatsApp/Meta infrastructure outside Turkey (a cross-border transfer, with the Article 9 safeguards being put in place as above). The legal basis is pre-contractual steps at the visitor’s request and legitimate interest in responding to inbound sales inquiries (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 the person initiates the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message under Law No. 6563 / İYS. The inquiry is retained for 1 year; unrelated later marketing requires separate explicit consent.

Seller team-invitation creation and redemption requests pass through the existing Hetzner and Cloudflare infrastructure. The target phone, a sanitized and length-bounded form of the inviting Seller’s display name, and the invitation link are sent by SMS through the existing Turkey-based Vatansms processor; no new processor is used, and the platform does not persist the rendered SMS body. The existing cross-border status and the Article 9 safeguard gap described above apply to Hetzner and Cloudflare.

For a possible student match, when one name is a contiguous part of the other and the surnames match, the authorized school admin compares the current and Excel child names, class, and active guardian names with masked phones and 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 name or explicitly apply the Turkish-title-cased Excel name; an unresolved possible match is protected from full-list removal.

4. Account deletion

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. Account closure immediately removes the server-side registration token and account-installation association. 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.

Retention periods vary by processing purpose; see the Privacy Policy Retention section for details. 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, create-request ID, and phone-authentication tag 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. An unused invitation can be revoked and becomes invalid if its creator loses active admin status or membership. After lifecycle guards pass, the in-app “Delete my account” flow closes your account immediately: sessions are revoked, the account can no longer be signed into, active memberships end, in-progress (pre-deadline) meal selections are dropped, and the phone is detached so the number is freed for re-registration. Your personal data is not yet destroyed at closure; it is stored with access closed, to prove the underlying transactions were real and to establish, exercise, or protect a legal right (KVKK Article 5/2-e), and is deleted or anonymized in the periodic destruction cycle following closure (within six months at the latest). On a written KVKK Article 7 request the deletion is completed within 30 days at the latest.

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.

When the deletion is processed, your name, phone, profile image (including the image file in object storage), and the technical fields on consent records (IP, device) are erased; the eater (meal-subject) name on your meal records is also stripped. Past meal selections, bulk orders, ratings, and billing-tied records are retained with the identity link cut, for the statutory retention period required by VUK m. 253 and TBK m. 146 — they appear as “Anonymous user” in per-person historical views; aggregate billing, headcount, and quality figures are unaffected. Free-text in-app product feedback 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 on 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.

A guardian’s meal selections, ratings and review notes placed for a child are not auto-deleted over time; they are kept for the service relationship. A guardian cannot remove the child, and an active student’s last guardian relationship cannot end. The 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. Erasing the child’s identity is a separate authorized KVKK process, while billing-related past records are retained anonymized. The guardian exercises the child’s KVKK rights.

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, deletion may be refused until another admin is appointed. This is a procedural prerequisite, not a refusal of the KVKK Article 7 right.

5. Rights

KVKK Article 11 requests can be sent to privacy@istebu.app. The right of access and portability can also be exercised in-app via “Download my data”. The generated export 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.