Skip to content

Privacy

What we process, and why.

suppy.chat carries other people’s customer conversations, so the honest version of a privacy page is a list: what is collected, who it is shared with, how long it stays and who to ask about it.

Two different relationships

When a business installs the widget on its website, that business decides what it asks its visitors and why. For those conversations the business is the data controller and suppy.chat is its processor: we handle the messages on its instructions. If you are a visitor who chatted on someone else’s site and want your data removed, ask that site’s operator first - they can delete the conversation from their dashboard, and we act on their instruction.

For the account of the business itself - the person who signs in, the team seats, the invoices - suppy.chat is the controller. Those two roles are separate on purpose, and the retention and deletion rules below say which one applies.

What is processed

  • Conversation content: the messages sent by a visitor, an operator or the AI assistant, including any files attached to them, and the timestamps that order them.
  • Contact details a visitor supplies: a name, an email address if they give one, and the language they chose for the conversation.
  • Technical context of a visit: IP address, a coarse location derived from it (country and city), the page a conversation started from, a randomly generated visitor key used to recognise the same browser session, and the platform tag a host app passes in.
  • Voice messages, when the module is enabled: the recording is transcribed and the transcript is stored as the message text; the audio is kept in the same private storage as other attachments.
  • Live voice calls, when a project enables them: calls started from the widget are recorded. The audio of both sides and a full transcript are stored with the conversation in private storage, available to the business’s operators only, and kept for as long as the conversation itself. What the visitor asks during the call is also stored as conversation messages.
  • Feedback: chat ratings and NPS survey answers, with any comment written alongside them.
  • Account and billing data for the business: sign-in identity, team membership and role, subscription, seats and module purchases, and the invoices Stripe issues.
  • Operational logs: request and error logs kept by our hosting provider for running and debugging the service.

The widget stores a small amount of data in the visitor’s own browser rather than on our servers: a conversation resume token so the thread survives a reload, the visitor key, the chosen translation language, and interface preferences such as the theme. Clearing site data for the widget removes them.

Emails from a business you talked to

A business that uses the email campaigns module may send news and offers by email to people who left their address in its chat widget, gave it in its NPS survey or wrote to its support inbox, as well as to contacts it imports itself. The business decides who is on that list and what it sends; it is the controller for it, as for the conversations. Every campaign email carries a link to unsubscribe in one click. After that the business never emails the address again, even if it imports it again later.

Who else sees it

Running a hosted chat product means other companies process parts of the data. These are the ones in the path:

  • Supabase - the PostgreSQL database and the private object storage holding conversations, accounts and uploaded files.
  • Vercel - application hosting, request routing, operational logs and aggregate page-view analytics.
  • OpenAI - assistant replies, message translation, speech-to-text for voice messages, text-to-speech playback and live voice calls (the call audio is streamed to OpenAI in real time), for the projects that enable those modules. Conversation text is sent to generate the answer.
  • Resend - transactional and conversation email, for projects that use the email features.
  • Stripe - payment processing and invoicing for paid seats and modules. Card details go directly to Stripe; suppy.chat does not receive or store card numbers.
  • Fish Audio, reached through Vercel’s AI Gateway - backup text-to-speech when the OpenAI voice is unavailable; the text of the message being read aloud is sent.
  • Telegram - notification delivery, only for projects that connect a Telegram channel.
  • DeBounce - mailbox verification, only when a project runs a mailbox check on its contact list; the email address alone is sent.
  • Microsoft Clarity - usage analytics (heatmaps and session replays) on suppy.chat’s own public pages only. It is not loaded in the chat widget, the dashboard or any conversation.
  • Any external service a project configures itself, such as an order-lookup endpoint or an MCP server. What is sent there is defined by the project’s own configuration.

We do not sell personal data, and we do not use conversation content to train models of our own.

How long it is kept

Conversations stay available to the business that owns them until that business deletes them or closes its project; closing a chat keeps its history, it does not erase it. Inactive conversations are closed automatically by a scheduled job, and conversations that never received a message are removed. Account and billing records are kept while the account exists and afterwards for as long as tax and accounting rules require. Operational logs are short-lived and kept by the hosting provider.

How it is protected

Traffic is encrypted in transit. Database access is constrained by row-level security so one project cannot read another’s conversations, uploaded files live in private storage buckets reached through short-lived signed URLs, and a conversation resumed from a link is authorised by a per-conversation token rather than by knowing its identifier. Operator access requires a signed-in account with a role on the project.

Asking about your data

Write to support@suppy.chat to ask what is held about you, to correct it, to receive a copy or to have it deleted. If your request concerns a conversation on another company’s website, tell us which site it was: we will point you at its operator, who decides on that data, and we will support them in carrying the request out.

This page describes how the service handles data today and is kept current with the product. It is a description of practice rather than a contract; for a data processing agreement or for details specific to your deployment, contact us and we will send the relevant document.