Privacy policy

1. Operator and scope of processing

Data controller name: MENYHART SZABOLCS PERSOANA FIZICA AUTORIZATA. Contact: tablego.site@gmail.com. This notice covers tableGo's own interfaces, not the notices of partner restaurants or external services you open.

Restaurants manage data relating to their requests, orders and communications in tableGo. The main administrator can also access data needed to administer the system. You can ask the restaurant about its own use of your data.

2. Guest accounts and sign-in

The guest's name, email, optional phone number, account identifier, creation and sign-in information support authentication and access to their own requests. Password sign-in uses a password hash; email verification involves a code hash, expiry and attempt information. Passwords are not stored as plain text.

Google sign-in provides an identifier, name, email and its verification status. tableGo does not request your Google password. Web sessions use cookies; Android sign-in uses an application authentication token. Expiry of a session or one-time sign-in code does not automatically delete associated operational records.

3. Partner registration and public profiles

Partner registration processes restaurant name, contact name, email, phone, address, type, password and an optional image. It is protected by robot verification and main-admin approval. Internal user and authentication details are distinct from the restaurant's public profile.

Guests can see published partner names, contact and location details, opening hours, images, descriptions and menus. Do not put personal information in public fields unless you intend to publish it. A hidden partner is excluded from ordinary guest lists; an authorized main administrator can still preview it.

4. Table requests and visit history

A request includes name, email, phone, party size, date, time, restaurant and an optional note. The system stores language, submission platform, statuses and their timestamps, and communication details. The restaurant can confirm, reject or cancel the request; the guest can also initiate cancellation.

Arrival, completion of the visit, table assignment and a no-show reported by the partner, including its timestamp and note, may form part of the history. For an incorrect no-show report or other inaccurate information, request a review from the restaurant and tableGo at the contact address.

5. Booking-based and QR orders

An order is linked to a booking or an active table visit. Data include restaurant and table identifiers, snapshots of items and prices, quantities, total, notes, status and timestamps. The restaurant sees these for fulfilment and communication.

The browser QR/WALK_IN flow can create a table visit and access credential without a guest account. This is not complete anonymity: the order, time and technical access data are linked. Ending a visit closes ordering access, not order history. tableGo's current ordering flow does not request card details for online payment.

6. Messages, reviews and moderation

Message content, sender role, time and the associated request support communication. Review ratings, titles, text, relationships and moderation status are also stored. An approved review's text, rating, time and associated guest name may appear publicly.

The relevant restaurant and authorized administrator can access messages and moderation according to their functions. Do not enter unnecessary sensitive information, another person's contact details or payment information in free-text fields.

7. Email and Android push

Email is used for account verification, sign-in and information concerning bookings, messages, reviews or partner registration, among other operational communications. Gmail SMTP receives the recipient address, message content and technical sending information.

Partner Android push handles a device token, partner/user association, language and delivery information. Expo Push receives notification content and related identifiers; an order notification can include guest name, table, item count and total. Check your lock-screen notification settings too. Disabling permission does not itself delete bookings or orders.

8. Location, address search and maps

When location permission is granted, device coordinates support nearby search and location checks in the on-site joining or arrival flows that require them. Manual search processes the entered address and selected position. Permission is controlled in your device or browser; refusing it can restrict operations requiring a location check.

The backend processes the search coordinate or area centre and radius and, when necessary, passes them to an external geocoder or places provider. Persistent nearby cache stores external place and coverage information, not a personal route log. Separately, browser, app and server technical storage may contain search positions or request information.

9. Cookies and on-device storage

A QR-code visit may also use a separate session cookie (tablego_dining_session) granting access to the visit you have joined.

WEB: sign-in uses role-specific session cookies, and language selection uses a language cookie. localStorage may hold language, selected location, search cache, active-request and notification information, and keys preventing duplicate orders. sessionStorage can also hold booking duplicate-prevention state. These are different storage mechanisms, not all cookies.

Android: SecureStore protects authentication and some return-navigation information; AsyncStorage holds language, booking drafts and duplicate-prevention state, among other settings. Parts of carts and forms exist only in memory. Clearing local data may sign you out or remove drafts but does not automatically erase server records. External captcha and map content may also use their own technical storage.

10. External services and recipients

The service uses Hostinger hosting and a MariaDB database. Google sign-in and Gmail SMTP involve identification and email flows. hCaptcha may process network, browser/device and challenge-response data; the tableGo backend sends a token and IP address for verification. Expo Push participates in delivering partner notifications.

The WEB map uses OpenStreetMap tiles; Android MapLibre rendering uses OpenFreeMap. Address resolution can use Nominatim, external place search Overpass and fallback Geoapify Places; admin area labels may also use Geoapify reverse geocoding. A directly loaded map provider may receive your IP and the displayed map area. Opening a Google Maps link passes the selected place to Google's service.

Providers and restaurants do not all act in the same legal capacity. A technical connection alone does not establish processor status. This list does not assert exclusively EEA storage or verified safeguards for international transfers.

11. Security and usage statistics

Access controls, tokens, password hashes, attempt limits, duplicate-prevention keys and blocking information support security. Rate-limit storage uses hashes derived from IP/account identifiers, counters and expiry information. These are not automatically treated as anonymous data.

Technical error logs may be generated. The application's own page-view and nearby-search statistics store aggregated daily counters; this does not exclude separate network logs of hosting or external providers. Automated security checks can reject a request; suspected incorrect restrictions can be reported at the contact address.

12. Account deletion and remaining data

Account or personal-data deletion requests can be sent to tablego.site@gmail.com. Deletion of a guest account by an authorized administrator removes the account and certain authentication relationships, but may only detach the account link from bookings and reviews.

Name, email, phone, notes and messages already recorded in bookings, and related order history, may remain. Blocking a partner account or hiding a restaurant publicly is not data deletion either. The system does not provide one uniform automatic retention deadline for every category; token or cache expiry is not a general erasure rule.

13. Data requests and complaints

Under the GDPR's conditions, you may request access, rectification, erasure and restriction. Portability applies to automated processing based on consent or contract; you may object to processing based on legitimate interests. Where processing relies on consent, you may withdraw it without affecting the lawfulness of earlier processing. These rights are not unlimited in every situation.

Write to tablego.site@gmail.com identifying your request and the relevant account or transaction. Do not send passwords or access tokens. Identity checks may be necessary to protect others' data. The GDPR's usual response deadline is one month, with notice of any justified extension permitted by law.

You may complain to Romania's ANSPDCP or another competent supervisory authority under the GDPR. This right does not depend on contacting tableGo first; judicial remedies also remain available.

14. Data sources and providing information

Data come from you, Google if chosen for sign-in, restaurant status reports and messages, and operation of your device and the service. External place information also comes from public mapping/place-search sources. Without fields marked as required, the relevant account, request or order operation cannot proceed. Phone is optional in the profile, but required for the current table-request flow.

This technical draft does not finally determine purpose-specific legal bases, exact retention rules or the legal classification of international transfers. It does not replace an approved notice completed with these elements.

15. Business details, agreements and financial records

New partner applications also request the official business name, CUI/CIF and legal representative's name to assess the application, identify the business and document cooperation. These are not automatically published on the profile. They are supplied by the applicant; format validation does not independently verify authority to represent the business or tax status.

Successful registration records the partner/user relationship, time, language, exact agreement version, full text and SHA-256 digest, with a snapshot of business and representative details. Separate price acceptance records the user, time, exact prices, version, text and hash. This is not a qualified electronic signature. The main admin accesses it to verify cooperation and settlement; partners see their own offers and acceptances.

Monthly settlements store partner ID/name, month, booking IDs, guest counts, applicable prices, corrections and closure evidence. The admin may record an externally issued invoice PDF, number, date, month, amount and payment data. PDFs may include personal business details and are stored privately with authorised downloads. tableGo does not automatically issue invoices or process card payments. The operator must separately identify the external invoicing provider, contract and processing.

Acceptance and financial records have no implemented general automatic deletion deadline; deleting an operational account does not necessarily erase evidence. Contract performance, specific legal obligations and legal claims must be distinguished. A lawyer/accountant must finalise the necessary documents, access and statutory retention; these do not justify unlimited retention of all guest history.

16. Legal bases and retention by purpose – approval framework

The following bases are review proposals, not unverified final conclusions. Code can establish purposes and flows, not a legal basis on its own. Before final publication, every purpose needs a confirmed basis considering contracting parties, necessity, legitimate-interest balancing and any consent. Reading a privacy notice is not blanket consent to all processing.

Accounts, login, bookings, orders, related messages and operational notifications: the purpose is providing the requested service. GDPR Article 6(1)(b) applies only within the contractual/precontractual relationship with the individual and to necessary data. Access may be given to the authorised operator, relevant restaurant and necessary technical providers. Accounts are needed during active use; business history has no uniform automatic purge. Closed cases, requests and inactivity require separate necessity review.

Partner contacts, contracts and pricing: Article 6(1)(b) may apply to individual contracting parties; assessed legitimate interests under Article 6(1)(f) to business representatives. Article 6(1)(c) for invoices requires an identified legal obligation. Recipients are authorised admins and necessary hosting/invoicing providers; partners access their own prices. Retention depends on cooperation, applicable document obligations and necessary evidence for specific disputes, not unlimited profile retention.

Reviews and moderation: sharing genuine guest experiences and handling unlawful content. Publication and abuse prevention require separate legal-basis approval and interest balancing where appropriate. Approved content is public; moderation is role-restricted. There is no automatic age-based deletion, which does not grant unlimited retention rights. Erasure requests, necessity and moderation are considered separately.

Security, authentication storage, rate limiting and error logs: legitimate interests in preventing unauthorised access and troubleshooting must be assessed. Expiring tokens or blocking accounts does not physically erase all associated data. Technical access is limited to authorised operators and providers. Actual log/backup periods need infrastructure verification.

Location, maps, captcha and analytics serve distinct purposes: location features, bot protection and usage statistics. OS GPS/push permission alone is not GDPR consent. Essential storage and optional external content require separate ePrivacy assessment; prior choice and withdrawal are needed where consent is required. Daily aggregate statistics in code do not prove all provider logs anonymous. Direct map/captcha loading involves external recipients; local storage can remain until deletion or its own expiry/cleanup rules apply.

Business-approved targets, not yet legally and technically finalised: 90 days for unnecessary personal data in completed bookings/orders, guest–restaurant messages and order notes; 30 days for rejected/cancelled booking personal data; inactive account review after 24 months with a planned 30-day advance notice. Internal partner–admin correspondence: 12 months after case closure, recoverable trash 30 days; routine logs and backups: conditional 30-day targets. These are neither mandatory GDPR periods nor promises of currently operating automatic deletion. Active cases, justified legal exceptions and individual requests require separate consideration.

17. Roles, transfers and further information

tableGo pursues its own platform, access and settlement purposes; restaurants decide on bookings and hospitality performance. This does not automatically establish joint control or a controller–processor relationship for every flow. Instructions, purposes and contracts require individual assessment and agreements where needed. Requests may be submitted to tableGo and, for restaurant processing, to the restaurant too.

Hostinger publishes processing terms; Google uses worldwide infrastructure and hCaptcha's notice describes processing in the United States. Expo distinguishes developer data from app end-user data. These alone do not confirm tableGo's contracting entity, region or all transfer safeguards. Specific non-EEA countries, legal mechanisms and access to copies of safeguards must be completed before final launch; mere service use is not assumed valid transfer consent.

Indirect data, including Google identity, restaurant status updates and public place information, require assessment of source and notice timing. A new purpose requires additional information and legal-basis review. Technical restrictions found in code do not establish profiling with significant legal effects under GDPR Article 22; this draft does not authorise such a purpose.