Guest Privacy Notice

Effective: August 23, 2026 · Last updated: September 15, 2026

This Guest Privacy Notice explains how personal information is handled when you visit a restaurant page powered by Tade, make or manage a reservation, join or manage a waitlist, receive a related email or text, or request deletion. It does not cover restaurant operator accounts, the admin website, or the Tade Restaurant Manager app; see the Restaurant Operator Privacy Notice for those services.

Tade is operated by Taehyung Kim, a sole proprietorship operating as Tade, based in Vancouver, British Columbia, Canada. Tade has designated a Privacy Officer who can be reached at admin@thetade.com.

1. Who Is Responsible for Guest Information

The restaurant decides why it needs guest information and how its staff use it to manage reservations, waitlists, visits, and guest relationships. For that activity, the restaurant is the organization primarily responsible for the information and Tade processes it to provide the restaurant's software. Tade also handles limited information for its own security, service delivery, opt-out compliance, fraud prevention, legal compliance, and support purposes.

A restaurant may have its own privacy notice and practices. Requests about a restaurant's internal notes, decisions, or use of your information may need to be handled by that restaurant; Tade will help route or complete a request where appropriate.

2. Information We Handle

Information you or a restaurant provides

• Identity and contact details: name, email address, and phone number. Online reservations require a name and email; a phone number is optional. Online waitlist entry requires a name and phone number.
• Reservation and waitlist details: restaurant, date, time, party size, request status, arrival and seating events, cancellation or no-show status, and the names previously used with the same restaurant.
• Notes and preferences: visit notes you submit and notes a restaurant records. These may include allergies, dietary needs, accessibility requests, seating preferences, or other information you choose to provide. Please do not include sensitive information that is not needed for the visit.
• Restaurant relationship history: visit and no-show counts, reservation and waitlist history, internal notes, and whether the restaurant has blocked future requests.
• Communication choices and evidence: whether and how SMS consent or reservation-email authorization was recorded; the authorization status and version, method, disclosure version, address contact version, masked address, keyed matching digest and key version, staff actor and time where applicable; STOP/START status; and delivery status or provider error information.
• Deletion requests: the restaurant slug, email address, single-use confirmation token, completion status, and a limited audit record of the request and affected records.
• Support and privacy correspondence: the sender and recipient addresses, subject, message body, attachments, normal email-delivery metadata, and the records reasonably needed to investigate and answer a support, deletion, privacy, or complaint request.

Information handled automatically

• Request and security data: hosting and network systems may process an IP address, request time, host, route, browser or device information, and security signals to deliver pages, limit abuse, and troubleshoot failures. Tade's structured application logs are designed not to record raw URLs, query strings, email addresses, phone numbers, message bodies, bearer tokens, IP addresses, or browser user-agent strings.
• Approximate country for domain routing: on the canonical public website hosts, the website host derives a two-letter country code from the request IP and provides it to the routing layer. General public pages opened on the wrong market host direct Canada to tade.ca and the United States to thetade.com; other or unknown countries remain on the address opened. Market-specific operator documents and the short reservation or waitlist management links sent by SMS stay on the market host already contained in their URL. The neutral legacy host book.thetade.com is not country-routed. Tade uses the country value for that request and does not store it in the guest application database.
• Browser storage: a waitlist status token may be stored in your browser's local storage under the restaurant slug so you can reopen the status page. It has no fixed browser-side expiry. The website removes it after that browser next observes that the entry has ended, was cancelled, or is invalid—for example during an open status session or a later revisit—or when a later action replaces or clears it. If the page is closed before that observation, the token may remain until a later visit, overwrite, or manual clearing. A promotion dismissal date controls the promotion for the recorded calendar day, but the stored value may remain until it is overwritten or you clear browser storage. These are essential preference/status storage, not advertising cookies.
• Public management links: reservation and waitlist links contain hard-to-guess bearer tokens. The server stores those tokens so the link can retrieve and manage the request. These tokens do not currently have a fixed token-expiry time, although available actions may end because of request status or a restaurant deadline; tokens are replaced when guest information is anonymized. When you open a link, the website and API hosting providers necessarily process the token as part of the request path even though Tade's structured application logs are designed not to record raw URLs. Anyone who obtains a valid link may be able to access the associated request, so do not forward it to unauthorized people.
• Duplicate-request protection: the current public reservation website normally sends a random UUID idempotency key with each submission. Tade stores the key, a normalized request hash, status, and the resulting reservation reference so a network retry can recover the same outcome instead of creating another reservation. While the row remains, anyone who obtains that UUID may retrieve the limited result used by the booking page—such as booked name, party size, status, restaurant, and time—so treat it as private. A row becomes eligible for deletion after 24 hours and the cleanup normally runs once per day, so physical retention can approach 48 hours; a delayed or failed cleanup may retain it longer until the next successful run.

Tade does not request your device's GPS or precise location on guest pages. We do not use advertising pixels, third-party behavioral analytics, or cross-site tracking cookies, and we do not build advertising profiles.

3. Why We Use Information

• to create, display, confirm, change, cancel, and administer reservations and waitlist entries;
• to let the restaurant recognize a returning guest and manage visit, no-show, note, and block history;
• to send transactional email and, where the required consent exists, transactional SMS;
• to provide maps, directions, support, deletion, and privacy-request functions;
• to secure the Service, prevent abuse, diagnose failures, enforce opt-outs, and preserve service integrity; and
• to comply with law, establish or defend legal claims, and enforce the Guest Terms of Use.

We limit collection, use, disclosure, and retention to purposes a reasonable person would consider appropriate in the circumstances. If we need information for a materially different purpose, we will provide notice and obtain consent where required.

4. Email

Online self-service reservations use transactional email rather than reservation SMS. The booking form requires a checkbox agreeing to the restaurant storing the contact details provided to manage the reservation and to receiving confirmation, change, cancellation, reminder, and management messages at that address—never marketing. For a staff-created or staff-managed reservation, staff may record an address supplied for the booking, but Tade sends transactional booking email to that exact address only after the guest asks or explicitly authorizes those messages and staff records the current authorization checkbox shown by Tade.

Reservation-email authorization is specific to the reservation, exact address, address contact version, and disclosure version. Tade stores versioned evidence of the grant or withdrawal and checks the current authorization again before dispatch. An address change, withdrawal, guest-record relink, or anonymization invalidates the authorization and cancels or prevents delivery where the message has not already been sent.

Historical online reservations created before this control was introduced may retain legacy transactional-email eligibility explicitly labelled legacy_guest_booking. That label records migration provenance and does not claim that the guest accepted the current disclosure. Historical staff-created reservations remain unauthorized unless a current authorization grant is recorded.

Emails may contain your name, restaurant, date, time, party size, address, restaurant rules and images, a calendar attachment, and bearer links to confirm, modify, cancel, or view the booking. Tade uses Resend to deliver these messages and does not use reservation email for marketing.

An HTML email may load shared Tade-hosted wordmarks, icons, or a restaurant image after your email application or its privacy proxy permits remote images. That request can disclose the request time and technical network or client information—such as an IP address or proxy address and user-agent information—to Tade's application, hosting, and network providers. The shared asset URLs are functional and are not unique per recipient; blocking remote images does not prevent the reservation or deletion link from working.

Confirmation and change emails may offer an “Add to Google Calendar” link. If you select it, your browser sends Google Calendar the restaurant name, reservation start and end time, party size, booked name, and restaurant address needed to prefill the event. Google handles that interaction under its own terms and privacy policy.

Before delivery, an email payload is encrypted in Tade's outbox and has a maximum active lifetime of 24 hours. Recipient, message, and attachment payloads are scrubbed when the item reaches a terminal sent, cancelled, dead, or expired state. Tade also sends Resend a per-operation idempotency identifier so a retry does not submit the same provider request twice. Resend separately processes the delivered message, provider request identifier, and submission or delivery metadata under its own service terms and retention practices.

5. Text Messages (SMS)

Tade sends transactional SMS text messages on the restaurant's behalf, and messages identify the restaurant. SMS is limited to online or staff-created waitlist activity, plus confirmations, changes, and cancellations for bookings created by restaurant staff where the guest's consent was recorded. Guests who book online themselves receive reservation email, not reservation SMS.

• Online waitlist: a phone number is required and joining is the opt-in. The form describes the program before submission. Tade sends an immediate join confirmation and may send a table-ready or cancellation message.
• Staff-created waitlist or booking: the guest must personally read and check the complete electronic SMS disclosure on the operator's screen. Restaurant staff must not check it for the guest. Tade records the disclosure version, staff actor or account identifier, time, method, and masked number as consent evidence. If the guest cannot personally review and check the current disclosure, the entry or booking may still be saved where the screen allows, but the corresponding text is not authorized or sent.
• Phone-number changes: SMS permission is tied to the exact number and the specific reservation or waitlist entry. Changing the stored number invalidates the affected permission and pending unsent texts. Each entry needs a new guest-completed handoff before texts to the new number are authorized. If a notified waitlist entry is returned to waiting after a number correction, it keeps its existing place in line so the restaurant can notify it again.
• Opt-out: STOP and equivalent carrier-supported keywords apply to that phone number across participating Tade restaurants until START or UNSTOP restores Toll-Free messaging. A reply of YES does not unblock Toll-Free delivery. Opting out does not cancel an entry; use the status page or contact the restaurant.

Message frequency varies, typically one to three messages per waitlist visit or staff-created booking. Message and data rates may apply. Consent is not a condition of purchase. Reply STOP to opt out at any time, or HELP for help. We do not send marketing or promotional text messages. Wireless carriers are not liable for delayed or undelivered messages.

A table-ready message tells you when to arrive and lets you reply 9 to cancel, without a confirmation reply. Twilio sends Tade the replying phone number and reply body; Tade uses them to locate and cancel the matching active entry. Reply STOP turns off text messages without cancelling the visit. HELP is intended to request help, but an automated HELP response depends on the carrier and Twilio messaging-service configuration. If no automated response arrives, contact the restaurant or admin@thetade.com.

Twilio receives the destination phone number, message, link, and delivery metadata to send the text and report status. Tade's SMS delivery log stores a masked number, Twilio message identifier, event, status, segment count, error and timestamps; nullable internal restaurant, reservation and waitlist references; after account deletion, a detached internal restaurant grouping reference copied from the former numeric restaurant ID, which is not a public identifier and is not by itself a claim of legal anonymization; a deduplication key derived from the destination and rendered message or event cycle; and, for durable-outbox delivery, the outbox reference while it exists and the positive attempt number. The attempt number can remain after its outbox parent is deleted. The delivery log does not store the full rendered message body. The opt-out register is different: it retains the full phone number without a scheduled deletion date so that a STOP request remains enforceable even if a guest profile is later anonymized. Consent records retain a masked number and evidence of the consent or withdrawal.

Tade does not sell mobile information, text-message opt-in data, or consent evidence, or share it with third parties or affiliates for their own marketing or promotional purposes. The relevant restaurant, messaging aggregators and providers (including Twilio and participating carriers), and Tade's hosting and storage providers may process only what is reasonably necessary to operate transactional messaging, enforce opt-outs, secure or support the Service, demonstrate compliance, or respond to lawful requests. Tade normally keeps the detailed consent ledger in its systems; Twilio receives the destination number, message, link, and delivery metadata, and Twilio or a carrier may request relevant consent proof for a compliance review. These limited operational, compliance, and legal disclosures do not authorize third-party marketing or promotional use.

6. Maps, Directions, and Location

A public restaurant page may embed a Google map of the restaurant and offer a Google Maps directions link. When the map loads or you open the link, your browser contacts Google directly. Google may receive your IP address, browser or device information, the restaurant location, and the referring page, and may use cookies or similar technology under Google's own privacy policy. This is a display of the restaurant's business location; Tade does not request or store your device's precise location.

7. Who Receives Information

We do not sell personal information or share it for cross-context behavioral advertising. Information is disclosed only as reasonably needed for the purposes above:

The table below describes the current production Service. The separate non-production test environment uses Google Cloud Run and Cloud SQL with Vercel staging websites, may be powered down when not in use, and is reserved for authorized testing with synthetic information; it must not be used to submit information about a real guest.

We may also disclose information to professional advisers, courts, regulators, law enforcement, or other parties where required by law or reasonably necessary to protect rights, safety, and the Service. If Tade is reorganized, sold, financed, or transferred, information may be reviewed or transferred subject to appropriate confidentiality and continued protection.

8. Processing Outside Canada

Tade is based in Canada, but providers including Google Cloud, Vercel, Twilio, Resend, Google Workspace, Google Maps, and managed storage infrastructure may process information outside Canada, including in the United States. Public domains do not define storage location: using tade.ca does not mean information stays in Canada. Information processed in another country can be subject to that country's laws and lawful access by its authorities.

9. Retention and Deletion

• Active reservation, waitlist, and guest history is kept while the restaurant reasonably needs it to provide service, manage relationships, resolve issues, and meet legal obligations.
• A guest profile with no qualifying activity for more than three years is normally anonymized, unless an active waitlist or another permitted retention reason applies. Identity, contact details, names, notes, and bearer tokens are removed from or replaced in the active guest profile and reservation or waitlist operational fields; de-identified reservation timing, party size, status, visit/no-show, and block statistics may remain.
• A blocked contact may be represented by a keyed, non-reversible contact fingerprint. It is used for block matching for up to five years, ending at its recorded expiry. After expiry, it is ignored for block matching and becomes eligible for scheduled cleanup; physical deletion of the row may occur later if that cleanup is delayed or fails and must run again.
• SMS outbox, consent, and delivery ledgers may remain as limited operational, compliance, and dispute evidence and currently have no automated deletion schedule. A reservation SMS outbox row can retain internal restaurant and reservation references, lifecycle event and contact versions, state, attempt and lease timing, expiry, cancellation or error reason, provider status, delivery-log reference, and timestamps; it does not retain a rendered message body or full destination number. The global full-number opt-out record also has no scheduled deletion date because deleting it could cause texts to resume contrary to a STOP request.
• An append-only reservation-email authorization ledger may remain after guest-profile anonymization or account deletion as limited compliance and dispute evidence. It may contain internal reservation, restaurant, and customer references; authorization status, version, method, and disclosure; a masked address; a keyed matching digest and key version; address contact version; staff actor; and time. The masked address and keyed digest are not a readable full email address. No automated deletion schedule is currently enforced for this ledger; contact the Privacy Officer with questions about a specific record.
• Encrypted email outbox content has the 24-hour maximum active lifetime described above. An outbox row whose creation time is more than 90 days old is normally eligible for cleanup if it is sent or cancelled, or if it is dead or expired and an operator has acknowledged it. The 90 days runs from row creation, not from acknowledgement, so an old dead or expired row may become eligible immediately when it is later acknowledged. An unacknowledged delivery failure may remain longer while it awaits operational review.
• Security, deletion-audit, and legal records may be kept longer where reasonably necessary for compliance, disputes, fraud prevention, or the establishment or defence of claims.

The self-service deletion flow is available from a restaurant page and at /delete-info/request. It matches an email address to a guest at a specific restaurant and sends a one-hour confirmation link. Waitlist-only guests without an email can instead contact the restaurant or admin@thetade.com. A confirmed request cancels all reservations still marked upcoming or seated and all waitlist entries still marked waiting, notified, or confirmed, and anonymizes the guest information described above, subject to the limited records that must or may remain.

10. Security

We use administrative and technical safeguards appropriate to the information, including encrypted transport, access controls, hashed or encrypted security tokens where the relevant flow supports them, encrypted pending email payloads, restricted structured logging, request limits, and provider webhook verification. No internet or storage system is completely secure. Protect bearer links and contact us promptly if you believe information or an account has been compromised.

If Tade becomes aware of a suspected privacy or security incident, it will take reasonable steps to contain and assess it, preserve the incident record required by applicable law, and work with the relevant restaurant and service providers. Tade will notify affected individuals and applicable privacy regulators when and in the manner required by law; not every security event legally requires individual notification.

11. Your Choices and Rights

Depending on where you live, you may ask to access personal information, understand its use and disclosure, correct inaccurate information, withdraw consent, object to or restrict certain processing, receive a portable copy where applicable, delete information, or challenge compliance. Withdrawing consent does not affect processing already lawfully completed and may prevent a requested feature from working.

Start with the restaurant for guest records under its control or contact admin@thetade.com. The Privacy Officer may verify identity, identify the relevant restaurant or provider, investigate the concern, correct or explain the handling at issue, and provide a written response or available escalation route.

To make an access or correction request under British Columbia's Personal Information Protection Act (BC PIPA) for information under Tade's control, send a written request with enough detail for Tade to identify you and the information or correction sought. When BC PIPA applies, Tade will respond within 30 days unless the statutory period is lawfully suspended; an access-request period may also be extended as BC PIPA permits. If Tade extends an access-request period, it will state the reason, expected response date, and available complaint rights. If Tade refuses access to all or part of requested information, it will give the reasons and BC PIPA provision relied on, contact information for a person who can answer questions, and notice of the right to seek review by the Office of the Information and Privacy Commissioner for British Columbia within 30 days. Where BC PIPA permits an access fee, Tade will provide a written estimate before charging it; no access fee will be charged for employee personal information.

If Tade accepts a BC PIPA correction request, it will correct the information as soon as reasonably possible and send the corrected information to each organization to which Tade disclosed it during the previous year. If Tade does not make the correction, it will annotate the information under its control with the correction that was requested but not made, as BC PIPA requires. For other requests, Tade will respond within the period required by applicable law and explain any permitted refusal. You may complain to the Office of the Privacy Commissioner of Canada at priv.gc.ca, the Office of the Information and Privacy Commissioner for British Columbia at oipc.bc.ca, or the regulator in your jurisdiction.

When Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) applies, make the access or correction request in writing. Tade will assist a person who says they need help preparing it and will respond with due diligence, no later than 30 days after receipt. If Tade uses a permitted extension, it will send notice by the original deadline stating the new deadline, the reason, and the right to complain to the Privacy Commissioner of Canada. A refusal will be provided in writing with the reasons and available recourse. Before charging any permitted response cost, Tade will disclose the approximate cost and confirm that the request is not withdrawn. Information that is the subject of the request will be retained as long as necessary for the individual to exhaust available PIPEDA recourse.

California residents

If the California Consumer Privacy Act applies to Tade's handling of your information, you may have rights to know, access, delete, and correct personal information, to opt out of sale or sharing, to limit certain uses of sensitive personal information, and not to receive discriminatory treatment for exercising a right. Tade does not sell personal information or share it for cross-context behavioral advertising. Submit a request using the contact above.

12. Children

Guest pages are not directed to children. We do not knowingly use them to collect children's information for advertising. A parent, guardian, or authorized adult should make a request involving a child and provide only information reasonably needed for the restaurant visit. Contact us if you believe a child submitted information without appropriate authority.

13. Changes and Contact

We may update this Notice when the Service, providers, or law changes. We will revise the effective date above. Material changes will be announced on the affected guest page before or when they take effect and, where we have a suitable contact address and law requires, by email or another direct channel. For questions, rights requests, or complaints, contact:

Tade — Privacy Officer
Email: admin@thetade.com (including privacy questions or accessibility issues with a Tade page)
Location: Vancouver, British Columbia, Canada