Privacy Policy

Who we are

RestoMama and ChowDesk are the same platform under two names: restaurant billing, kitchen, payments, delivery and display software, operated from Kochi, Kerala, India.

The organisation responsible for the personal data described here — the Data Fiduciary under India’s Digital Personal Data Protection Act, 2023, and the controller under the EU and UK GDPR where those apply — is [PLACEHOLDER — COUNSEL TO COMPLETE: registered legal entity name], company registration number [PLACEHOLDER — COUNSEL TO COMPLETE: CIN or company registration number], registered at [PLACEHOLDER — COUNSEL TO COMPLETE: registered office address].

This policy applies to the websites restomama.com and chowdesk.com, the web applications served from them, our APIs at api.restomama.com and api.chowdesk.com, and the ChowDesk Displays Android TV application (package com.chowdesk.display).

What this policy covers

One document for four different kinds of person, because the same platform touches all of them and they deserve to see the whole picture rather than the part that flatters us:

• Restaurants and their staff. The businesses that subscribe to RestoMama, and the people who sign in to run the counter, the kitchen, the reports and the console.
• Guests of those restaurants. People who order, join a queue, collect points or receive a receipt. Their data belongs to the restaurant; we process it on the restaurant’s instructions.
• Delivery partners. Where a restaurant runs the delivery product, the riders who apply, are approved, take assigned trips and are paid for them.
• Screens, not viewers. The TV app’s subject is the display device itself. It collects nothing about the people standing in front of it — see below.

Our two roles

We are the Data Fiduciary (controller) for the data a business gives us directly: registration and account details, the people who administer the account, subscription and billing records, support conversations, enquiries sent through this website, delivery-partner applications, and the device telemetry described below. We decide why and how that data is processed.

We are a Data Processor for the personal data a restaurant collects from its own guests through the platform — names, phone numbers, addresses, order history, loyalty balances, messaging consent. The restaurant is the Data Fiduciary for that data. We process it only to run the service the restaurant asked for, on its documented instructions, and we hand the restaurant the tools to answer its guests’ requests.

One exception, stated so it is not buried. The anonymous product analytics and session replay in the guest ordering app are ours, not the restaurant’s — we decide to run them and we decide what they measure. For that narrow processing we are the Data Fiduciary, not the restaurant’s processor, and the request goes to us. It is described in full under the websites and web apps.

If you are a guest of a restaurant and want your data corrected or erased, the fastest route is the restaurant itself. If you cannot reach them, write to us and we will route the request and support them in answering it.

The ChowDesk Displays TV app

The app turns an Android TV device into a menu board showing the restaurant’s own menu, prices and media. It is installed by the restaurant on the restaurant’s own hardware. It has no public sign-in, no user profiles, and it does not see, hear, photograph, count or identify anyone in front of the screen.

What the app sends us, and what we actually keep

The heartbeat endpoint validates every request against a strict field whitelist and refuses the whole request if it carries a field that is not on it. So this list is short, and it is the list of what the server accepts and stores — not the longer list of what a device is capable of assembling.

• Liveness, and the name of the board on screen. A heartbeat about every thirty seconds while a board is playing. Against the paired screen we store the time of the last beat and whether it is online or offline, which is what the restaurant’s console shows. The board name is written only into the operations feed entry recorded when a screen comes back online after being marked offline.
• The app’s version string. The heartbeat accepts one. It helps a support engineer reading a live request tell an old app from a broken screen. It is not written to any record.
• A browser user-agent string, once, at pairing. Truncated to 200 characters and kept against the paired screen, so an unusual device can be identified when a restaurant reports a problem with it.
• An install identifier — which the app sends and the server throws away. The Android app generates a random UUID the first time it runs and keeps it on the device. It is deliberately not the Android ID, the advertising ID, the hardware serial, the IMEI or a MAC address, and it is cleared when the app is uninstalled or the device is factory reset. Its background heartbeat transmits that UUID together with the device manufacturer and model, the Android API level, whether the build is staging or production, and the reason Android reported for the app’s last exit — and the server rejects that request in full, because none of those fields are on the whitelist above. We disclose it because the app does send it over the network to us, even though we neither accept nor retain it.

A correction. An earlier version of this page also listed connectivity and free-storage status as telemetry the app reports. That was wrong, and wrong in our favour. The app reads both only on the device itself — connectivity for the on-screen setup checklist an installer sees, free space to decide how much cached media to delete — and neither has ever been transmitted to us.

The device credential, and where it is really stored

When a screen is paired, the server issues a device token. The app tries to store it in Android’s EncryptedSharedPreferences, backed by the device keystore. On many of the cheap HDMI sticks this product is designed to run on, that fails — the keystore is missing, broken, or the stored key can no longer be decrypted after a system update. When it fails, the app falls back to an ordinary private preferences file and the token is stored unencrypted on the device. We chose that over a screen that refuses to start, and we would rather say so here than let you assume an encryption guarantee we cannot make on that hardware.

What is true on both paths: the token is private to the app, readable by no other app on an unmodified device, never displayed, never written to a log, and never sent anywhere except our own API. It authorises read access to exactly one screen’s board content for exactly one restaurant — it cannot be used to sign in, to reach any other screen, or to read anything else. Unpairing, revoking the screen from the console, an unauthorised response from our API, and uninstalling all destroy it — and the wipe clears both the encrypted file and the fallback file, so a token cannot survive in whichever one was in use.

What the app does not collect

No names, phone numbers, email addresses or payment details of any guest. No location. No contacts, calendar, call logs or SMS. No camera or microphone access. No advertising identifier. No browsing history. The app ships with no advertising SDK, no analytics SDK, and no Firebase or Crashlytics.

The hosts the screen connects to

The board itself is drawn by a web player bundled inside the app, so the screen behaves like a browser and reaches more than one host. In the interest of being exact rather than flattering, the destinations are:

• Our own API, for pairing, the heartbeat, and the board content itself.
• Our media CDN, for the restaurant’s board images and video.
• Google Fonts (fonts.googleapis.com and fonts.gstatic.com). The bundled player’s page requests its typefaces from Google on load. That request reaches Google directly from the device, so Google receives the device’s IP address and the request metadata any web request carries, under Google’s own privacy policy. It carries no identifier of ours, no restaurant identity and no board content, and it is not something we can see. We intend to bundle these fonts with the app so the request stops being made at all.
• Two hosts the bundle can reach on other screens of the same player: images.unsplash.com, for a stock placeholder image where a menu item has no photo of its own, and OpenStreetMap tile servers, for the delivery tracking map. The bundled player shares its code with our guest ordering app, so these paths ship inside the APK. They are not part of drawing a menu board, but the honest statement is that they are present in the bundle rather than absent from the device.

The app allows no plaintext HTTP anywhere, and the player’s own window refuses to navigate away from the bundled content — a menu board cannot be steered into a browser. Neither of those mechanisms filters the sub-resource requests listed above, which is why they are listed.

Because the app is distributed through Google Play, Google’s own Android vitals service collects crash and ANR reports from Play-installed apps under Google’s privacy policy. We see those only as aggregate stability reports in the Play Console; they are not part of the data we collect, and we cannot tie them to a restaurant.

The websites and web apps

• This marketing site. If you send an enquiry, we receive what you type into the form: your name, phone number, email address, city, restaurant name, branch count, what you want to launch first, and your message. These pages also measure which of them people find useful, using Google Analytics — but only if you accept the cookie banner, and never for advertising. What is measured, what is stored, and what happens if you decline are all set out under cookies, analytics and local storage below.
• Registration and onboarding. Business details, the contact person’s name, phone and email, the plan you choose, and the verification documents you upload for approval.
• The restaurant console. Staff accounts, roles and permissions, and the operational data your team enters or generates: menus, orders, payments, inventory, attendance, reports and the audit trail of who changed what.
• Guest data your restaurant collects. Name, phone number, order and loyalty history, delivery address where delivery is used, and the messaging consent recorded against each guest. Processed as your processor, never for our own purposes.
• Delivery partners. Identity and vehicle documents, application and approval status, assigned trips, cash-on-delivery reconciliation and payout records.
• Delivery-partner location. This deserves its own paragraph, because it is the most sensitive thing the platform holds about a person and because we previously described it too narrowly.
  • Last known position. While a rider is marked online in the delivery agent app, the app reports their coordinates to us about every fifteen seconds — whether or not they are on a trip. We keep the most recent pair on the rider’s own record together with the time it arrived. The server places no trip condition on that report, and it does not clear the stored position when a trip ends or when the rider goes offline. Each report overwrites the last, so what is held is a single current point rather than a track, but that point persists until the next report replaces it or we delete it. It is used to show the guest and the restaurant where an in-progress order is, and to offer a new order to the nearest available rider.
  • Trip milestones. When a delivery moves between states — accepted, picked up, delivered and so on — we record the coordinates at that moment against that order. Those entries are a history, they are retained with the order record, and they are what lets a disputed delivery be reconstructed.
  • A service area, if the rider sets one. A rider can define the centre and radius of the area they want orders from. The app offers to fill the centre in from the device’s current position; the rider can type it instead. It is stored on their record and used only to decide which orders they are offered.
  • What limits it. Location is reported by the delivery agent app only, only for riders who are signed in and have marked themselves online, and only from a device where the rider has granted the browser’s location permission — which the rider can withdraw at any time in the device’s own settings, and which going offline in the app also stops. We do not collect location from guests, from restaurant staff, or from the TV app. A rider who wants their stored position cleared can ask us and we will clear it.
• Server and security logs. Our hosting providers record IP addresses, user-agent strings, request paths and timestamps. They exist to keep the platform up and to detect abuse, and they are not used to profile anyone.

Product analytics in the guest ordering app

The guest ordering app — the one a diner uses to browse a restaurant’s menu and place an order — is built to support PostHog, a product analytics tool. It only runs where a deployment has been given both a PostHog project key and a region to send to; with either missing, every call in the app is a no-op and nothing is collected or stored. Where it does run, this is what it does and does not do:

• Product events. Named events for what happened, not who did it — a menu was opened, an order was placed — with the route path, and the identifiers of the restaurant and branch. The code refuses to attach any property whose name looks like a name, phone number, email address or postal address, and the identity attached to these events is a random one PostHog generates in your browser: we never send it your account details, your phone number or your name.
• Session replay, and the correction this paragraph is. An earlier version of this page said PostHog’s session recording was enabled, so that how you moved through the app could be replayed. That was true when it was written. It is not true now: session recording is switched off in our code, and has been since we concluded that replaying an authenticated checkout — where the fields being filled are a name, a phone number and a delivery address — is not something masking makes acceptable without asking first. Nothing is recorded, and there is nothing to replay. If replay is ever switched back on it will be behind its own explicit choice, disclosed here before it collects anything, and not folded into a cookie banner about analytics.

Where it runs, PostHog stores its anonymous identifier and its own state in your browser’s local storage for that app, and that storage is cleared whenever the app switches between one restaurant and another. Being straight about the remaining gap: where it runs, it still starts when the app loads rather than after you have been asked. Putting it behind the same explicit choice the marketing site now uses is work in progress; until it lands, this paragraph is the disclosure.

This does not apply to the restaurant console, to the delivery agent app, or to the TV display app: none of those carry PostHog or any other analytics tool. The marketing site you are reading now does not carry PostHog either — its measurement is Google Analytics, it is a separate decision, and it is described under cookies, analytics and local storage.

Why we process it, and on what basis

We process personal data to provide, secure, support and improve the service — running orders and payments, sending the notifications your settings and consents allow, producing your reports, keeping screens playing, dispatching deliveries, reading the documents you upload so you do not have to type them in, triaging the problems you report, measuring anonymously how the guest ordering app is used so we can fix what breaks, preventing fraud and abuse, and meeting our tax and accounting obligations. We do not use your data to build advertising profiles, and we do not do behavioural advertising at all.

Under the DPDP Act, 2023

Personal data is processed for the lawful purposes stated in this notice, either on the consent of the Data Principal — given to the restaurant that collects it, or to us at the point we collect it — or under the certain legitimate uses the Act permits, such as data voluntarily provided for a purpose you asked us to fulfil, and compliance with a legal obligation. Consent can be withdrawn at any time; withdrawing it stops future processing that depended on it and does not make past processing unlawful.

Under the GDPR, where it applies

For visitors, customers and partners in the EEA or the UK, our lawful bases are: the performance of a contract, for everything needed to deliver the subscription you bought; our legitimate interests, for platform security, fraud prevention, screen reliability telemetry, delivery dispatch, and the anonymous product analytics and session replay described above, each balanced against your rights; your consent, for marketing messages and anything else where we ask for it; and legal obligation, for records we are required to keep. Where the GDPR applies, session replay in the guest ordering app is the case we consider closest to the line, and we will move it to consent rather than argue it.

What we never do

We never sell your data

We do not sell personal data, we do not rent or trade it, and we never share it with a third party for that party’s own purposes or marketing. There is no advertising network and no data broker anywhere in this platform, no advertising profile is built about anyone, and we do not permit any personal data we hold to be used to train anyone’s models. The only outside parties that ever process the data are the service providers listed below, acting on our instructions and only to the extent needed to run the service for you. We may disclose data where the law compels it, and we will tell you when we are permitted to.

How that survives this site having Google Analytics. It survives because of a specific, deliberate configuration rather than a promise. Under Consent Mode v2 a site declares each signal separately, and on this one the three advertising signals — ad_storage, ad_user_data and ad_personalization — are set to denied before the Google tag loads and are never granted, whatever you choose in the cookie banner. Accepting grants one thing: analytics_storage. The property is not linked to Google Ads and Google Signals is switched off, so there is no mechanism by which an advertising or cross-device profile could be built from it.

One honest qualification. An earlier version of this page said there was “no behavioural profiling anywhere in this platform”. That was too absolute to be defended. Two things measure behaviour. This marketing site counts page views through Google Analytics, after you accept, described under cookies, analytics and local storage. And the guest ordering app runs anonymous product analytics where it is switched on, described under the websites and web apps. Neither is joined to marketing, neither builds an advertising profile, and the ordering app’s session replay is off — but both are behavioural measurement, and this page should not have implied otherwise.

Who else processes it

These are our sub-processors. Each is bound by contract to process data only on our instructions, to keep it confidential, and to apply appropriate security measures.

• Amazon Web Services. Object storage and CDN delivery for menu images, board media and video, and for the files uploaded during onboarding.
• Neon. Managed PostgreSQL hosting for the platform databases.
• Railway. Application hosting and runtime for our backend services.
• Vercel. Hosting and CDN delivery for this website.
• MSG91. Delivery of SMS, WhatsApp and email messages — one-time passwords, order updates and the notifications a restaurant sends its guests.
• PhonePe, Paytm and RazorpayX. Payment collection and payouts, depending on what a restaurant has configured. Card and bank credentials are entered on the gateway’s own surface and are never stored by us.
• Anthropic. Reads documents you upload so we can turn them into structured records, and helps triage support tickets. Two specific flows, and nothing else:
  • Inventory and purchase documents. When a restaurant uploads a photographed or scanned stock list or supplier invoice for automatic entry, we send that document to Anthropic’s API to be transcribed into rows, along with the item, supplier, category and location names already in that restaurant’s inventory so the spellings come back matching. A supplier invoice can name individuals, so we say plainly that a document you upload is read by a third party’s model.
  • Support triage. When a bug or support report is raised, its title, description, the page it was raised from, the technical diagnostics snapshot captured with it, and any screenshot attached to it are sent to the same API to be summarised, classified and checked against recent reports for duplicates. A screenshot of a live screen can contain whatever was on that screen, which is the reason this is spelled out rather than summarised as “support tooling”.
  Nothing else is routed there — not guest records, not order history, not menus, not board content, and not delivery-partner data. Anthropic processes this as our sub-processor, bound to our instructions, and we do not permit this data to be used to train models. The feature only operates where it is switched on for a restaurant; one that uploads no documents and files no reports sends nothing to Anthropic.
• PostHog. Product analytics for the guest ordering app, where it is switched on for a deployment: anonymous event data only. Session recording is off, so no recordings are created or sent. No guest names, phone numbers, emails or addresses are sent to it.
• Google (Google Play, Google Fonts, and Google Analytics). Distribution and updates of the Android TV app, and the Play Console crash and ANR reporting that comes with it. Separately, the TV app’s bundled player requests its typefaces from Google Fonts, which means Google receives the screen’s IP address on load — see the TV section above. And on this marketing site, Google Analytics 4 measures page views once you accept the cookie banner — Google Ireland Limited, with Google LLC, acting as our processor under Google’s data processing terms. What it sets and what it receives is itemised under cookies, analytics and local storage.

We also disclose data to professional advisers, and to a successor entity in the event of a merger or acquisition, under the same confidentiality terms. Where the law requires it — a valid order from a court or an authority with jurisdiction — we comply, and we tell the affected party unless we are legally barred from doing so.

Where data is stored, and transfers out of India

Our primary hosting region is [PLACEHOLDER — COUNSEL TO COMPLETE: primary hosting region, e.g. AWS ap-south-1 (Mumbai)]. Several of the providers above operate globally, so personal data may be stored or processed outside India — for backups, CDN edge delivery, or the provider’s own support operations.

The DPDP Act permits transfers outside India except to territories the Central Government restricts by notification; we will stop transferring to any such territory if one is notified. Where personal data protected by the EU or UK GDPR is transferred out of the EEA or the UK, we rely on an adequacy decision where one exists, and otherwise on the European Commission’s Standard Contractual Clauses (with the UK Addendum where relevant) together with the provider’s own safeguards.

One transfer is worth naming specifically, because you can decline it. If you accept analytics cookies on this marketing site, Google Analytics processes your IP address and the pages you viewed on Google’s infrastructure, which includes servers in the United States. That transfer relies on Google’s participation in the EU–US Data Privacy Framework and on the Standard Contractual Clauses. Declining the banner means it does not happen at all.

How long we keep it

• Screen liveness data. The last-seen time, the online/offline state and the pairing user-agent live on the paired-screen record and are deleted when the screen is unpaired or removed. The online/offline entries in the operations feed are swept by a scheduled job on a configured retention window — 30 days in the shipped default. The window in force on our production deployment is [PLACEHOLDER — COUNSEL TO COMPLETE: confirmed production operations-feed retention window].
• Account and operational data. Kept for as long as your account is active. After it closes you can export it for [PLACEHOLDER — COUNSEL TO COMPLETE: post-termination export window, e.g. 30 days], after which it is deleted or irreversibly anonymised within [PLACEHOLDER — COUNSEL TO COMPLETE: deletion window after the export period, e.g. 90 days].
• Records the law requires. Invoices, tax and GST records, and payment records are retained for the statutory period under Indian law even after the rest is deleted.
• Enquiries and support conversations. Kept while we are in contact with you and for a reasonable period afterwards, so a returning enquiry is not answered from nothing.
• Delivery-partner location. The current position on a rider’s record is overwritten by each new report and is not cleared automatically when a trip or a shift ends; it is deleted when the rider’s record is deleted, or sooner on request. The coordinates recorded at each delivery milestone are retained with that order.
• Website analytics. Where you have accepted them, the analytics events from this marketing site and the identifier attached to them are retained in our Google Analytics property for [PLACEHOLDER — COUNSEL TO COMPLETE: GA4 data retention window, e.g. 14 months], after which Google deletes them. Withdrawing consent deletes the cookies from your browser immediately and stops anything further being sent.
• Backups. Deleted data persists in our providers’ backups until those age out on the provider’s normal rotation, and is not restored into service.

How we protect it

• Encrypted in transit. Every connection between a browser, a TV screen and our API is over TLS, and HSTS is enforced on our sites.
• Device credentials, with a caveat we state rather than hide. The TV app’s device token is written to Android’s EncryptedSharedPreferences where the device’s keystore works, and to a plain app-private file where it does not — which happens on some of the low-cost TV sticks this product runs on. The token is scoped to one screen and one restaurant and grants no account access. See the TV section for the full description.
• Tenant isolation. Every record is scoped to one organisation, and a device token authorises exactly one screen belonging to exactly one restaurant.
• Role-based access and an audit trail. Permissions are granted per person, and changes to an organisation are logged with who made them.
• No secrets or personal data in logs. Phone numbers, one-time passwords and tokens are masked before anything is written.
• Every guest message passes one gate, but not the same check. All sends — order updates, one-time passwords, campaigns, receipts — go through a single authorisation point before they leave. What that point checks depends on the message. Promotional messages require an explicit, recorded marketing consent for that person on that channel, and are also stopped by an unsubscribe. Transactional messages — the order update, the login code — are not gated on a consent record; they are checked against that person’s notification preferences, the per-restaurant switches for that kind of message, and the email suppression list. It is a real distinction, and this page previously blurred it by claiming every message was checked against recorded consent.
• Backups. Our database and object-storage providers operate their own managed backup and point-in-time recovery. We do not state a recovery point objective here, because we would rather publish nothing than publish a number we cannot stand behind — ask us and we will tell you the current arrangement.

No system is perfectly secure, and we do not claim certifications we do not hold. If a personal data breach occurs we will notify the Data Protection Board of India and the affected Data Principals as the DPDP Act requires, and — where the GDPR applies — the relevant supervisory authority without undue delay and within 72 hours of becoming aware.

Your rights

If you are in India

Under the DPDP Act, 2023 you may ask us for a summary of the personal data we hold about you and how it is being processed; ask us to correct, complete or update inaccurate data; ask us to erase data we no longer need; nominate another person to exercise these rights on your behalf in the event of your death or incapacity; and raise a grievance with us before approaching the Data Protection Board of India.

If you are in the EEA or the UK

You have the rights of access, rectification, erasure, restriction of processing, data portability, and objection to processing based on our legitimate interests, and you may withdraw consent at any time where consent is the basis. You may also lodge a complaint with your local supervisory authority.

How to exercise them

Write to the contact below with enough detail for us to find your records. We will verify who you are before we act — that verification is itself a protection — and we answer as quickly as we can, within the period the applicable law allows. There is no charge for a reasonable request. If the data reached us through a restaurant that uses RestoMama, that restaurant is the Data Fiduciary and we will pass your request to them and help them answer it.

Children’s data

RestoMama is business software, sold to restaurants and used by their staff. It is not directed at children, and the TV display app collects nothing at all about the people who see a screen. We do not knowingly collect personal data from a child, and we serve no advertising of any kind — behavioural or otherwise — so the DPDP Act’s prohibition on advertising targeted at children is met by the platform having no such capability.

On the Act’s separate prohibition on tracking or behavioural monitoring of children, we will not claim more than we can defend. Two things measure behaviour: this marketing site’s analytics, which is business software marketing and runs only after an adult accepts it; and the guest ordering app’s anonymous product analytics, where it is switched on. Neither is directed at children, neither builds a profile of anyone, and the ordering app’s session replay is off — but both are behavioural measurement, and neither identifies the age of the person using it. That is the honest position, and it is one of the reasons the marketing site’s measurement now sits behind an explicit choice and the ordering app’s is being moved behind one. If you believe a child’s personal data has reached us, tell us and we will delete it.

Cookies, analytics and local storage

This website sets no advertising cookies, and nothing here follows you to any other site. It sets analytics cookies only if you accept them — one third-party service, Google Analytics, and no other — and it writes a small amount of strictly necessary and functional data to your browser’s local storage either way. Here is the complete list rather than a summary of it.

Storage this site writes whatever you choose

• rm.theme — your light-or-dark choice.
• rm.plans.catalog — a cached copy of our public pricing catalogue, so the pricing page still renders if the API is slow or down.
• rm.features.delivery — whether the delivery pages should be shown, cached from the same public configuration.
• cd_merchant_access and cd_merchant_refresh — on the restaurant registration and account pages only, the sign-in tokens that keep you signed in to your application.
• cd_driver_access and cd_driver_refresh — the same thing on the delivery-partner registration and account pages.
• rm.consent — your answer to the cookie banner and the time you gave it, so you are not asked again on every page. It is written whichever way you answer, including when you decline.

The first three describe our own content, not you, and identify nobody. The next four are strictly necessary sign-in tokens: they exist only after you sign in, they are removed when you sign out, and without them you could not stay signed in. The last records your own choice. None of them is used to track you across sites, and none is shared with anyone.

Analytics cookies — only if you accept

If you accept, Google Analytics 4 sets two first-party cookies on restomama.com, with SameSite=Lax and Secure:

• _ga — a random identifier that tells one browser from another so a returning visit is not counted as a new person. It expires after 13 months. It contains no name, no email address and no phone number.
• _ga_ followed by our property’s id — the state of your current session, so a visit to three pages is counted as one visit. Same lifetime.

What Google receives with them is the page address, the page title, the page you came from, your browser and device type, and the approximate location Google derives from your IP address. Because these cookies are set on the whole of restomama.com, your browser also attaches them to requests this site makes to our own API on that domain; we do not read them there.

Before you choose, and if you decline

Before you choose, the Google tag loads but every storage type is set to denied: it sends a single measurement without any identifier, and writes nothing to your device. If you decline, we go further than that — the tag is switched off for this site entirely, any _ga cookies already present are deleted, and nothing further is sent at all. If you accept, only analytics_storage is granted; the advertising signals stay denied permanently, as described under what we never do.

You can change your mind at any time, and it takes effect immediately — from the “Cookie choices” link at the bottom of any page, or from the button below. You can also install Google’s own browser opt-out add-on, or block cookies in your browser’s settings, which this site is built to survive.

Elsewhere on the platform

The signed-in restaurant, delivery and platform applications use the same kind of strictly necessary sign-in storage, and carry no analytics. The guest ordering app stores PostHog’s anonymous analytics identifier and state where PostHog is switched on, described under the websites and web apps; that storage is cleared when the app switches between restaurants. The TV app’s WebView stores the device token and the last good board snapshot locally so a screen keeps playing when the network drops; both are cleared on unpair or uninstall.

Changes to this policy

We update this policy when the platform changes what it collects or who processes it. The “last updated” date at the top changes with it, and material changes are notified to account holders. The version published at this address is always the current one — which is why the Google Play listing points here rather than to a copy.

Contact and grievance redressal

For any question about this policy, or to make a request about your data, write to [PLACEHOLDER — COUNSEL TO COMPLETE: privacy contact email address], or get in touch through the site.

Grievance Officer (as required by section 13 of the DPDP Act, 2023): [PLACEHOLDER — COUNSEL TO COMPLETE: Grievance Officer name], [PLACEHOLDER — COUNSEL TO COMPLETE: Grievance Officer email address], at the registered office given at the top of this page. If you are not satisfied with our answer, you may complain to the Data Protection Board of India.

For the EEA and the UK: [PLACEHOLDER — COUNSEL TO COMPLETE: EU/UK representative or Data Protection Officer contact, if one is appointed].

The terms governing use of the platform are on the terms of service page.