Privacy Policy

Sacio is a trade name operated by Devansh Vadgama (“Sacio”, “we”, “us”). This policy applies to the Sacio public website, restaurant workspace, staff order receiver, QR ordering pages and related support (together, the “Service”).

In this policy, a “Restaurant” is a business using the Service; an “Owner” is a person authorised to manage its Sacio workspace; “Staff” is a person given a Restaurant-scoped staff account; and a “Guest” is a person using a table QR or order link. A Restaurant’s own website, payment app, bank, point-of-sale system and dining service are outside the Service and may have separate privacy notices.

For Guest orders and most Staff records, the participating Restaurant decides why the information is used. The Restaurant is generally the data fiduciary or controller, and Sacio processes the information to provide the Service on the Restaurant’s instructions. A Guest should normally contact the Restaurant first about a dining order.

Sacio acts for its own purposes when managing Owner access, providing support, measuring Service reliability, securing the Service, enforcing agreements and complying with law. Sacio is responsible for that processing as applicable.

• Guest, order and table-session records: Restaurant and table references; item names, quantities, prices and optional notes; totals, timestamps and status; bill requests; payment method and payment status; an internal payment reference; and opaque order or session access tokens.
• Owner records: name, email address, Supabase authentication identifier, Restaurant association, account status and workspace actions.
• Staff records: username, display name, salted password hash, login attempts, lockout and session records, account status and order actions. Staff do not use email addresses to sign in.
• Legacy Staff push records: the repository retains Web Push infrastructure for compatibility with subscriptions made through an earlier enrolment interface. A retained subscription contains an endpoint hash, encrypted push endpoint and keys, device label, user agent, delivery status and the associated Staff account and session. Fresh devices cannot enrol through the current Staff interface, so background alerts are not a current supported feature.
• Restaurant content and settings: business and menu details, item images, availability, optional GSTIN and GST rates, and optional merchant UPI ID and payee name.
• Device, usage and security records: cookies, local browser storage, requested routes, browser and device details, performance measurements, request metadata, security events and diagnostic logs. Infrastructure logs may include an IP address.
• Communications: sender contact details and the contents of support, sales, privacy or legal messages.

Do not place passwords, UPI PINs, card details, bank credentials or unnecessary sensitive information in order notes or messages. An allergy note may reveal health information; provide only what the Restaurant needs to prepare the order safely.

An active table session is intentionally shared. Guests using the same active table link may see item names, quantities, prices, order statuses and the combined table total for the current session. Private order notes, payment references, Staff information, internal database identifiers and previous table sessions are not returned in that shared view.

Table QR URLs and table-session URLs function like access links. A Guest must not share, forward or photograph them for later or off-table use. A Restaurant can deactivate a table or rotate its table token; rotation invalidates the old table QR URL immediately. When Staff close or verify payment for a session, a later order starts a separate session and the table QR no longer surfaces the previous session.

Information is received:

• directly from Owners, Staff and Guests using the Service;
• from a Restaurant when it creates accounts, menus, table links or settings;
• automatically from browsers, devices and infrastructure when the Service is used; and
• from providers where needed for authentication, hosting, storage, analytics, legacy push delivery or support.

Information is used only for lawful purposes, including to:

• show the correct Restaurant menu and table;
• submit orders and bill requests to authorised Staff;
• show shared order, bill and payment-status information;
• operate Owner and Staff accounts and manage retained legacy push subscriptions;
• configure menus, taxes, tables and optional UPI details;
• authenticate users, prevent misuse, investigate incidents and keep audit records;
• provide support and administer Restaurant agreements;
• measure aggregated usage and performance; and
• meet legal, tax, accounting and regulatory obligations.

Depending on the context and applicable law, processing is based on a request to provide the Service, consent, performance of an agreement, a use permitted by law, compliance with a legal obligation, or the need to establish, exercise or defend legal claims.

If enabled by the Restaurant, Sacio constructs a UPI payment intent or QR using the Restaurant’s merchant UPI ID, payee name, table label and bill amount. Sacio does not receive, hold or settle funds and does not receive a UPI PIN, card number, CVV or bank-account login.

Sacio records whether a Guest reports completing payment and whether authorised Staff mark receipt as verified. Staff verification is a Restaurant action based on its bank app, soundbox or other records; it is not independent bank confirmation and Sacio has no payment-provider integration that confirms settlement.

Supabase Auth manages Owner authentication cookies. Staff sign-in uses an HTTP-only, SameSite=Lax session cookie that is Secure in production and a Restaurant-reminder cookie. Staff sessions expire after 30 days, but expired database rows are not currently deleted automatically.

A Guest’s browser uses local storage for the current cart and a pending retry-safe submission. A legacy recent-order feature can keep up to 20 order links on that device. Clearing browser storage removes device-local data but does not delete submitted orders held by a Restaurant or Sacio.

The application includes Vercel Web Analytics and Vercel Speed Insights. If enabled for the deployment, they collect aggregated page, device and real-world performance measurements without third-party advertising cookies. Sacio does not request browser geolocation—the site’s permissions policy disables it—but Vercel may derive an approximate country, region or city from a request for aggregated analytics. Sacio does not use precise GPS location.

Information may be disclosed only as reasonably needed to:

• the relevant Restaurant and its authorised Owners and Staff;
• Vercel: application hosting, Functions, content delivery, deployment logs, Web Analytics and Speed Insights;
• Supabase: PostgreSQL database, Owner authentication and public menu-image storage;
• browser push services: only for a retained legacy Staff subscription when server configuration remains enabled; the endpoint determines the browser or operating-system push provider;
• professional advisers, insurers or authorities where necessary to comply with law, protect rights or address fraud and security; and
• a genuine buyer or successor, subject to confidentiality and applicable law.

No separate transactional email or monitoring provider is verified in this repository. Supabase Auth handles Owner authentication email flows; its underlying email-delivery configuration must be confirmed before publication. Sacio does not sell or rent personal data to data brokers or advertisers.

The repository does not currently contain a production retention or deletion job for database records. The placeholders below must be decided, implemented and tested before this policy is published. Until then, affected database rows remain unless they are manually deleted through an authorised operational process.

A record may need to be kept longer where required for tax, legal, fraud-prevention, security or dispute purposes. Backups and logs may take additional time to age out after deletion from a live system once a verified schedule is implemented.

Safeguards in the current Service include Restaurant separation, server-derived access scope, opaque 192-bit public access tokens, table-token rotation, password hashing with scrypt and unique salts, hashed Staff session tokens, AES-256-GCM encryption for push endpoints and keys, restricted public response shapes, upload validation, audit records and no-store headers on sensitive responses.

No internet service can guarantee absolute security. Owners and Staff must protect their credentials and devices and report suspected compromise promptly. If applicable law requires notice of a personal-data breach, Sacio will assist the Restaurant and make any notice for which Sacio is responsible in the required form and time.

Subject to applicable law, commencement dates and exemptions, a person may request information about personal data being processed, correction or updating, erasure, withdrawal of consent where relevant, nomination where available, or grievance redressal.

A Guest should normally contact the Restaurant first about an order. A request may also be sent to Sacio. Enough information may be needed to verify the requester, identify the Restaurant and protect other people’s data. Withdrawal does not affect processing already lawfully completed and may prevent a dependent feature from operating.

The Service is not directed to children for independent use. A person under 18 may use the Guest ordering flow only under the supervision of a parent or lawful guardian. Where legally required, the participating Restaurant is responsible for obtaining verifiable consent from the parent or lawful guardian.

Vercel Functions are configured in the repository for the Mumbai region, but Vercel content delivery, analytics, logs and related operations may occur elsewhere. The Supabase project region is [SUPABASE PROJECT REGION TO BE VERIFIED]. Browser push providers may process delivery data for a retained legacy subscription according to the Staff member’s browser and device. Sacio does not guarantee that every processing operation occurs in India. Any applicable cross-border restriction must be assessed before production use.

Sacio may update this policy when the Service, providers or legal requirements change. The revised version will be posted here with a new effective date and “Last updated” date. Material changes may also be communicated through the Service or to Owners before taking effect where appropriate.

Sacio’s privacy and grievance contact is Devansh Vadgama, the operator.

• Email: [email protected] — [EXTERNAL EMAIL DELIVERY VERIFICATION PENDING]
• Address: [BUSINESS CORRESPONDENCE ADDRESS]
• Phone: [CONTACT PHONE NUMBER]

Include the relevant Restaurant, your relationship to the record and enough detail to understand the request. Do not send passwords, UPI PINs or card information. Sacio will address grievances within the period required by applicable law after receiving enough information to investigate.