Privacy

• Account

  An email address, used to sign in and to receive booking notifications. Authentication is handled by Supabase; Tugon never stores a password.

• Page

  Username, display name, bio, profile photo, links, currency and theme. All of this is public by design — it is the page strangers are meant to see.

• Training

  What the owner does, services, pricing, FAQs and tone. Supplied to the assistant so it can answer. Also effectively public: a visitor can ask for any of it.

• Availability

  Timezone, weekly hours, appointment length, buffer, daily cap, notice period and blocked dates.

• Billing

  Handled by Paddle, who act as merchant of record. Tugon stores only the customer and subscription identifiers Paddle issues, plus plan status. Card details never reach Tugon.

• Messages

  The conversation with the assistant is stored so the assistant can follow the thread and so the owner can read it. Kept against a random identifier the browser generates, not a name or an account.

• Bookings

  Name, email address, the time booked, and how many people are coming. The email is used to send a confirmation and to let the owner reply.

• Age and gender — only if asked for

  Collected onlywhere the owner has explicitly turned it on for a specific service, and stored only for those services. The assistant is required to say “Your booking details are shared only with [owner]” in the same message that asks. If the flag is off, the value is discarded server-side even if it is somehow supplied.

• Payment screenshots

  Where an owner charges a deposit, a visitor may upload one screenshot as proof. It goes to a private storage bucket that has no public read access; the owner views it through a short-lived signed link. Tugon does not process payments and never sees a card.

• Voice notes

  A recorded question is sent for transcription and the audio is never stored — only the resulting text, as an ordinary message.

• Abuse limits

  To stop one person draining an owner’s monthly allowance, Tugon counts replies per address. The address is stored only as a keyed HMAC hash, never in the clear, and the hash is salted per owner so the same visitor cannot be correlated across pages.

An owner may optionally connect a Google Calendar so the assistant stops offering times they are already busy. This is worth being exact about, because it is the permission people most reasonably worry about.

Tugon requests a single scope, calendar.freebusy. That scope returns only busy and free time ranges. It cannot return event titles, descriptions, locations, attendees or guest email addresses — not because Tugon chooses not to read them, but because the permission granted does not carry them. All Tugon learns is that a block of time is unavailable.

It is read-only and one-way. Tugon never creates, edits or deletes anything on a Google Calendar, and never writes bookings back to it. Only the account’s primary calendar is consulted.

The refresh token that permits this is encrypted (AES-256-GCM) before it is stored, and kept in a table no browser can reach — row-level security is on with no policies, so only server-side code holding the service key can read it. Busy times are cached in memory for about five minutes to avoid hammering Google, and are never written to the database.

An owner can disconnect at any time from their calendar settings, which deletes the token, or revoke access from their Google account directly. Either way Tugon falls back to its own availability with no loss of service. Tugon’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Data lives in Supabase (PostgreSQL and object storage), hosted on AWS in Singapore, and the application runs on Vercel. Access is restricted by row-level security so an owner can reach their own rows and nobody else’s.

Two things are treated as more sensitive than the rest and stored accordingly: Google refresh tokens, which are encrypted at the application layer before they are written, and payment screenshots, which sit in a private bucket with no public access and are served only through expiring signed URLs. Profile photos, by contrast, are public — they appear on a public page.

Tugon does not sell personal data, does not share it for advertising, and does not use it to train anyone’s models. It is shared only with the services needed to make the product work:

• Anthropic

  Receives the conversation and the owner’s training text to generate replies.

• OpenAI

  Receives voice-note audio for transcription, when a visitor records one.

• Resend

  Receives the name, email address and appointment time needed to send booking confirmations.

• Google

  Receives a request asking whether the owner is busy in a given window. No visitor data is sent to Google.

• Supabase, Vercel, Paddle

  Hosting, storage and billing respectively.

The other party who sees a booking is the owner it was made with — which is the point of making one.

Conversations are trimmed to the most recent messages as they grow, and older exchanges are compressed into a short summary rather than kept in full. Abuse-limit counters expire within a day. Everything else is kept while the account exists.

Deleting an owner’s account removes their page, training, availability, bookings and conversations. A visitor who wants a booking or a conversation removed should ask the owner of the page, who can delete it — or contact us and we will.

Tugon is not intended for children. Owners must be adults. Where a service collects a visitor’s age, that is the owner’s decision and the owner’s responsibility to justify.

Questions, corrections, or a request to delete something: privacy@tugon.ai.