Restaurant Operator Privacy Notice

Last updated: October 21, 2026

TADE TECHNOLOGIES INC. (“Tade,” “we,” or “us”) provides restaurant reservation, waitlist, and management software. This notice explains how we handle personal information relating to restaurant operators, authorized users, and restaurant administration. We are based in Vancouver, British Columbia, Canada. Contact us at support@thetade.com about privacy or your information.

This notice covers the administrator websites, restaurant app, sign-up and account-management flows, and related support. The services available through tade.ca and thetade.com use the same platform. Guest-facing information is explained separately in the Guest Privacy Notice and Guest Terms of Service. Operators should also read the Restaurant Operator Terms of Service.

For guest reservations, waitlists, and restaurant customer records, we provide processing services that support the restaurant's operations. The restaurant decides what information its staff enter and how it uses those records to serve guests. We handle operator accounts, authentication, service administration, support, and platform security for our own corresponding purposes. A restaurant remains responsible for its own privacy notices, appropriate permissions, staff practices, and copies of information held outside Tade.

1. Information we handle

Account and sign-in information

Depending on how you sign up and use your account, we handle your name, email address, phone number, country, account identifiers, and account or verification status. Email-and-password accounts involve a password hash and information needed for email verification and password recovery. Social sign-in involves the identifiers and profile information returned by Google or Apple, such as your name and email address; Apple may supply a private relay address. Tade does not receive your Google or Apple password.

We also handle session and authentication information needed to keep you signed in, distinguish access through the administrator website and app, revoke sessions, and investigate failed or suspicious access. When the sign-up flow records legal acceptance, the record can include the document and disclosure versions, acceptance time, account or sign-up context, and related request evidence. A saved record of an earlier acceptance is not a statement that you accepted every later version.

If you start social sign-up before completing account creation, we may temporarily keep a short-lived account-signup intent containing your provider identifier, name, and email address, linked to a hashed one-time ticket. An expired intent cannot complete sign-up and is removed by cleanup; it is not an active restaurant account or proof that you accepted these Terms. Cleanup timing is described below.

Restaurant setup, content, and account administration

We handle the restaurant's name, address, phone number, location and country, public description, hours, policies, booking settings, menus, uploaded images, and other information you provide. We also store operational setup such as tables and floor layouts, account plan and trial status, and changes made through the administrator tools. Business information may be personal information when it identifies an individual, such as a sole proprietor or a person shown in an uploaded image.

Information selected for the public restaurant page, including its contact details, location, menus, and photos, is visible to visitors and may be copied or indexed outside Tade. Publish only information and images that you are entitled to make public. Customer profiles and internal operational notes are not content for the public restaurant page.

Paid subscription collection is not currently enabled. The current subscription flow does not collect payment-card details. If that changes, we will identify the payment processor and explain the relevant processing before asking you to supply payment information.

Guest records processed for a restaurant

A reservation or waitlist entry can create or match a customer profile within that restaurant. Depending on the information supplied and features used, the record may contain a guest's name, other names used for bookings, email address, phone number, reservation date and time, party size, waitlist status, staff notes, preferences, visit history, no-show history, and a booking-block status. Guest-provided visit notes may contain allergy, dietary, accessibility, or other potentially sensitive information.

The profile can remain after the current reservation or waitlist visit ends. Authorized restaurant users can find and reuse it for future reservations, including bookings entered manually after a phone call or in-person request. This is a restaurant-scoped operational profile, not a guest account or a shared contact directory for unrelated restaurants. The restaurant should explain this reuse when collecting information outside the online forms and should not enter more information than it reasonably needs.

Technical, communications, and support records

Service requests can produce IP addresses, browser or device information, request times, account or record identifiers, errors, and operational or security events. Our website infrastructure may use a country inferred from the request to choose an appropriate public or administrator domain. That country routing is not a promise about where information is stored.

When messages are sent or received, we handle the recipient details and message content needed for delivery, together with delivery outcomes, failure information, provider identifiers, and relevant replies. SMS consent and opt-out records can include the number or a masked or derived representation of it, the purpose and method of consent, the relevant staff or guest action, and disclosure evidence. If you contact us, we also handle your message and the information reasonably needed to address it.

2. Why we use information

• To create and administer restaurant accounts, verify identity, manage sessions, and apply the account's available features.
• To publish restaurant content you choose to make public and run reservation, waitlist, table, customer-history, and reporting functions.
• To maintain restaurant-specific customer profiles and support later reservations and staff-entered bookings using those records.
• To send operational account emails and guest communications, manage delivery failures, record messaging consent, and respect opt-outs.
• To answer support and privacy requests, correct problems, protect the service from abuse, and investigate security issues.
• To maintain appropriate evidence of account actions and agreements, resolve disputes, and meet applicable legal requirements.

We do not treat acceptance of operator terms as blanket permission to collect unrelated personal information or to market to a restaurant's guests. We seek any additional notice or consent required for a materially different purpose. The restaurant must do the same for its own use of guest information.

3. Booking changes, email, and SMS

Where notifications are enabled and the required authorization applies, creating, changing, or cancelling a reservation can cause an operational email to be sent to the address authorized for that booking. Emails may include booking confirmations, reminders, cancellations, and updates to the date, time, or number of guests. An email address already saved in the restaurant's customer profile may be used when staff create a later manual booking, but the saved address alone does not authorize emails for that booking. Staff should check the booking details and intended recipient, obtain the required authorization, and follow the email choice shown in the form before saving. Not every edit creates a message, and delivery is not guaranteed.

Self-service online reservations support email, rather than SMS, for reservation notifications under those conditions. Supported staff-created reservations and waitlist activity may use transactional SMS where enabled and the required consent has been obtained and recorded. SMS consent is separate from keeping contact details in a customer profile. A previous visit or the existence of a phone number does not itself authorize a new text program or marketing.

Guests can reply STOP to opt out of texts or HELP for help. Opt-outs and delivery suppression can prevent a message even when staff have saved a booking or waitlist action. Minimal suppression and consent evidence may be retained to honour those choices and show why a message was or was not sent. These records are not a marketing list. We do not sell guest contact details or share mobile opt-in information for third-party marketing.

4. Who receives information

Current operator-service providers include Google Cloud Run and Cloud SQL for application processing and database storage, Vercel for website hosting, Resend for email, and Twilio for SMS. Google Identity and Apple Sign in provide optional authentication. When both providers are configured, the administrator login page loads both the Google Identity Services library and the Sign in with Apple JavaScript SDK before you choose a sign-in button. If only one provider is configured, only its library is loaded. Those SDK requests can disclose your IP address, device or browser information, and referrer information to Google or Apple before an operator chooses a provider. The provider the operator selects additionally returns the identity information described above to Tade. Account-deletion reauthentication loads only the library for the provider linked to that account. Google Places address search also sends the text entered for suggestions; these are provider requests, not just local form validation.

Mobile build and update delivery (Expo/EAS) receives technical information needed to build, distribute, or check for app updates, including application and runtime versions, platform, network information, and a randomized update-download token. This is separate from push messaging: the current app does not register a push token with Expo. Support and privacy-request email (Google Workspace) processes the messages and attachments you send to our support address. Only send information needed for the request.

Restaurant users with account access can view the guest and operational information made available to that account. Tade personnel may access information when needed for support, administration, security, or a privacy request. Public restaurant content is available to visitors as described above.

We use providers for the functions below. The information involved depends on which features are used; signing in, sending a message, uploading an image, or using a map does not send every category of restaurant information to every provider.

If a guest chooses Add to Calendar in a reservation email, their browser opens Google Calendar with the booking name, party size, restaurant name and location, and reservation date and time. If the guest imports the attached calendar file into another calendar service, that service receives the event details they choose to import. Calendar providers handle and retain this information under their own privacy and retention policies. Deleting information from Tade does not delete the calendar copy.

Google, Apple, and other providers may also handle information under their own privacy notices when you interact directly with their services. We may disclose information where required or authorized by law, to protect people or the service, or in connection with a business transfer subject to applicable privacy requirements. We do not sell personal information or share it for cross-context behavioural advertising.

5. International processing

Tade is based in Canada, but our infrastructure and providers may process or store information outside Canada, including in the United States. The same is true when you use tade.ca or its administrator website: a Canadian domain does not guarantee Canadian-only storage, delivery, or access. Information handled in another country may be subject to that country's laws and lawful access by its authorities.

Contact us if you need more information about the processing relevant to your account. Do not assume that selecting a country for your restaurant establishes a particular data-residency arrangement.

Non-production test websites and apps use separate test services. Operators must use synthetic information there, not real account, restaurant staff, or guest personal information. A test environment is not an alternative place to manage actual reservations.

6. Security and storage on your device

The current app does not request device GPS or precise location, camera, photo-library or external-media access, and does not deliver push notifications or use a system-overlay feature. A device permission declared by an older installed binary is not proof that a feature is used; current app configuration blocks unused notification, external-storage, overlay, and biometric permissions.

Address suggestions and details use Google Places. Tade stores the selected place identifier, which Google permits to be stored indefinitely. The server can temporarily process provider coordinates to resolve a missing neighbourhood; these coordinates are not returned to the operator browser, and are not stored in the application database. Tade sets the restaurant's time zone from its address: the time zone Google Places reports for that address or, when Google cannot provide one, the time zone of its province or state. We do not derive the time zone from stored coordinates.

Browser local storage and tab-scoped session storage can contain session or workflow state. App session credentials use secure device storage; on iOS, Keychain entries may survive uninstall and reinstall with the same bundle identifier. A stored token copy may remain after server expiry or invalidation even though it no longer grants access. Clearing local storage is not a server-side deletion request. Google or Apple libraries may use provider cookies or similar browser storage under their own policies; Tade does not use that provider state for advertising. See Google Privacy Policy and Apple Privacy Policy.

We use safeguards such as encrypted connections, password hashing where passwords are used, authentication controls, and limits on public responses. These measures reduce risk but cannot guarantee complete security. Restaurant users must also protect their accounts, shared devices, and any information they copy out of the service.

The administrator websites and app use browser or device storage for sign-in sessions and necessary preferences or workflow state. Removing that storage can sign you out or reset local settings; it does not delete the restaurant account or server-side guest records. Information visible on a shared device may remain accessible to another person who uses an active session. Sign out when appropriate and restrict device access.

7. Retention and account deletion

Legal acceptance is recorded separately from the document text. The append-only record identifies the internal actor and restaurant where applicable, document versions, disclosure version and digest, acceptance method, client type, country context, and acceptance time. This ledger does not store the legal document body, operator name or email, IP address, or user-agent string. Deleting an account detaches identifying foreign keys but can retain internal grouping references; these are not by themselves a claim that retained evidence is legally anonymous. No automated deletion schedule is currently enforced for this ledger. Updating our published documents does not rewrite an earlier acceptance or require existing administrators to accept again merely to sign in.

We keep account and restaurant information while it is needed to provide and administer the service. Guest profiles and history can remain available for the restaurant's ongoing operations and later bookings; they are not automatically erased when a visit finishes. We consider the purpose of the record, account status, privacy requests, security needs, and applicable legal obligations when deleting or anonymizing information.

Where enabled, an automated routine is designed to anonymize restaurant guest profiles after more than three years of inactivity. Activity and active requests affect eligibility. This is not a promise that every guest record is erased on a fixed anniversary. Each stored restriction fingerprint has an expiry of up to five years from that record's creation, with physical removal subject to cleanup. Replacement records and a restaurant's continuing restriction can last beyond the original record, so this is not a maximum duration for every restaurant restriction. Text-message suppression records can remain longer to respect opt-outs.

Pending reservation-email delivery payloads have a maximum active lifetime of 24 hours, with earlier expiry or removal possible. That delivery limit does not erase the booking, consent evidence, or an email already delivered. Certain temporary request and duplicate-submission records become eligible for cleanup after 24 hours. Expired sign-up intents and one-time verification or recovery records are also removed by cleanup. With a normally running daily cleanup, physical retention can approach 48 hours for those 24-hour records. Shorter-lived records follow their own expiry and cleanup eligibility. Disabled jobs, failures, processing limits, or records still in use can delay physical removal; no universal 48-hour deletion guarantee applies.

Closing an account, resetting restaurant information, and deleting an individual guest's information are different actions with different effects. Use the relevant administrator-web controls and review the confirmation shown. Account deletion may require fresh identity verification. Guest deletion may cancel active reservations or waitlist entries and anonymize identifying details while retaining non-identifying operational history.

Some information may remain when reasonably needed to comply with law, document agreements or consent, honour suppression and abuse-prevention measures, investigate security incidents, or resolve disputes. Retained records may use masked, anonymized, or derived identifiers instead of the original contact details where appropriate. A derived identifier can still be personal information when it can be linked to a person.

Reservation-email authorization has its own append-only ledger containing the authorization method and version, a masked address, a keyed matching digest and key version, contact version, internal references, and timestamps. It does not store a readable full email address, and it has no automated deletion schedule. Historical evidence is labelled as historical; it is not proof that a guest accepted a later disclosure. SMS consent and suppression evidence may also remain after the visit or the delivery record is removed.

Eligible completed email-delivery metadata is cleaned up after 90 days from creation; eligible SMS-delivery metadata uses 90 days from its last update. Unresolved failures are retained until acknowledged and otherwise eligible. Consumed SMS provider-status records use 90 days from consumption. These are cleanup eligibility rules, not a promise that all messages, consent evidence, provider copies, or backups are deleted after 90 days.

Deletion from active systems does not mean that every backup, recovery copy, provider record, or legally required record disappears at the same instant. Any information retained remains subject to its applicable purpose and protections. We do not promise a fixed deletion period for every record or provider copy. Contact us about the scope and status of a particular request.

8. Access, correction, choices, and complaints

Depending on applicable law, you may request access to your personal information, information about its use and disclosure, correction of inaccurate information, deletion where available, or withdrawal of consent. Some information is necessary to authenticate an account, provide a requested service, or meet legal obligations; withdrawing permission for that use may affect the available service. We will explain relevant limitations rather than treating a request as a waiver of your other rights.

For operator-account information, use the available account controls or email support@thetade.com. We may ask for information reasonably needed to verify your identity and authority before disclosing or changing records. Do not send a password or unnecessary identity documents in an initial email.

For guest information managed by a restaurant, the restaurant should help with the request and involve Tade where platform assistance is needed. Guests can also contact us directly; we may need to coordinate with the restaurant and verify the relevant record. The online guest deletion flow is described in the Guest Privacy Notice. Restaurant users should not disclose another guest's information while answering a request.

We will respond in accordance with applicable law and explain any lawful reason that limits a request. You may also contact a competent privacy regulator, including the Office of the Information and Privacy Commissioner for British Columbia or the Office of the Privacy Commissioner of Canada, as applicable. We do not penalize people for exercising applicable privacy rights.

9. Updates and privacy contact

We will update the date above when this notice changes and provide additional notice of material changes where appropriate. A new notice does not retroactively establish consent to a new purpose. Where additional consent is required, we will obtain it.

Privacy Officer
TADE TECHNOLOGIES INC.
Vancouver, British Columbia, Canada
support@thetade.com