HelloChat
Privacy Policy
Effective 12 October 2026. This page describes the personal data HelloChat actually stores and who processes it.
Who we are
HelloChat is an AI customer-service desk. The public site is https://www.hellochatapp.com. This policy covers that site, the signed-in merchant desk, the website chat widget, and the Meta WhatsApp app “HelloChat” (App ID 1515132483761351).
Merchants create a workspace and one agent, add knowledge, and put the agent on their own website. HelloChat is the data user for merchant account data. For chat and knowledge about a merchant’s own customers, the merchant decides what is collected and HelloChat processes it to run the agent.
Merchant account data
When a workspace is created we store the workspace name, the login email, a bcrypt password hash (not the password itself), the role (merchant or admin), and whether the account is disabled. Sign-in sets an httpOnly cookie named hellochat_session. The cookie is SameSite=Lax, scoped to the site path, and expires after 14 days. It holds a signed token with the user id, workspace id, and email. There is no single sign-on and no separate analytics account.
Knowledge-base and album content
Merchants upload files (PDF, text, Markdown, and Word), question-and-answer pairs, and persona fields (display name, company, role, tone, language, time zone, greeting, and rules). We extract text, split it into chunks, and store the text with a vector embedding so the agent can cite it. Album images are stored as files with a filename, type, and size. Images are not embedded and are not used as chat knowledge. The desk serves album files only to a signed-in member of that workspace. The public widget can show the oldest album image as an avatar through a token tied to the embed key.
The embed key itself is shown to the merchant once. The database stores only a SHA-256 hash of that key.
When Cloudflare R2 is configured, new knowledge files and album images are stored in that R2 bucket. Otherwise they are stored on local disk (on Vercel, an ephemeral /tmp directory). Knowledge text and embeddings live in the database either way.
Website crawl content
A merchant can ask HelloChat to fetch public pages from one site. The crawl stays on that site, honours robots.txt Disallow for User-agent: *, and does not log in or follow a cart, checkout, or account path. We store the seed URL, page URL, title, and extracted text so the merchant can preview it. Nothing from the crawl is added to the agent until the merchant confirms it. Confirmed pages are kept as knowledge documents. A crawl can include personal data if that data is already published on the page the merchant chose.
Website chat (embed widget)
Visitors who use the chat bubble on a merchant’s site do not create a HelloChat account. We store the message text, role (visitor, assistant, or human staff), agent id, and a conversation id. The conversation id is kept in memory in the browser for that page view. The widget does not set a cookie and does not use local storage.
To limit abuse, the public chat route allows 30 messages per 60 seconds for each agent and client IP. The IP is taken from the first X-Forwarded-For address, or X-Real-IP. It is used only as part of the short-lived rate-limit key described under Upstash. Polling for a staff reply is not counted.
Handoff and notification email
If the merchant turns on handoff, a visitor can be passed to a person (for example when they ask for a human, or when retrieval is too weak to answer). We store the thread status, channel (website or the merchant’s private sandbox), trigger, and timestamps. Staff replies are stored as messages on that conversation.
On handoff we email the address the merchant saved for that agent, or the workspace owner’s login email if the agent field is blank. Delivery uses Resend when an API key is configured. The email contains the agent name and id, channel, trigger, conversation id, and up to 500 characters of the latest guest message. We do not send marketing email.
WhatsApp messages
HelloChat receives WhatsApp messages through the Meta WhatsApp Cloud API for app 1515132483761351. A verified callback is stored in the database table whatsapp_webhook_events. Each row keeps a SHA-256 dedupe key of the raw body (so Meta retries collapse to one row), the object type, the phone number id, message ids, the time received, and the webhook JSON payload. That payload is what Meta sends. It can include message text, phone numbers, and profile names.
Application logs for these callbacks record the phone number id and message ids only, not the message text. The product does not yet route these events to an agent and does not send WhatsApp replies. Instagram and Facebook Messenger are not connected.
Booking links
A merchant may store service names, duration, hours, policies, and a Google Calendar appointment URL on the agent. When a visitor asks to book, the chat shows that service and links to the URL the merchant pasted. HelloChat does not use Google Calendar OAuth, does not read a calendar, and does not receive the form the visitor submits on Google’s page.
Model and embedding providers
Answers and embeddings are produced through SiliconFlow’s OpenAI-compatible API when SILICONFLOW_API_KEY is set. The request can include the merchant’s persona and rules, retrieved knowledge chunks (from uploads, Q&A, or a confirmed crawl), and the conversation so far. Sandbox tests by the merchant follow the same path and are stored separately from website visitor chats. If the key is unset, embeddings fall back to a local hash on the server and are not sent to SiliconFlow.
Why we use this data
- Create and secure the merchant workspace and keep the merchant signed in.
- Index knowledge the merchant supplies and answer questions from that knowledge.
- Store website chats and, when handoff is on, let staff reply and receive an email notice.
- Receive and retain WhatsApp webhook events for the connected Meta app.
- Rate-limit the public widget and record security outcomes (denied embed keys, rate limits, handoff, booking offers) without the message text.
- Show a booking link the merchant configured.
Legal basis
The Personal Data (Privacy) Ordinance (Cap. 486) (PDPO) applies to personal data we control. We collect data that is necessary for the purposes above, or directly related to them, and not more than is required for those purposes (Data Protection Principle 1).
Merchant account data is collected so we can provide the desk the merchant asked for. Website chat, crawl text, and WhatsApp payloads are processed so the merchant’s agent and inbox can work. Merchants are responsible for having a proper basis to upload their customers’ data and to embed the widget or connect WhatsApp. Rate-limit data is used to keep the public endpoint available.
Retention
Account data, knowledge, album files, crawl text, sandbox messages, website chats, handoff threads, and WhatsApp webhook rows are kept while the workspace or integration is in use. The product does not run an automatic purge. We delete them when the merchant removes the item in the desk, or when we complete a deletion request (see Data deletion).
- The session cookie expires after 14 days of its own lifetime.
- Embed rate-limit keys expire after about 60 seconds.
- Security audit lines stay in host logs for the host’s log retention period.
- A handoff email sent through Resend is also subject to Resend’s retention. We do not keep a separate copy of the sent email beyond the conversation already stored.
- Deleting a user in the admin desk removes that user row. A full workspace deletion, including files and conversations, is done when we process a deletion request.
International transfers
The providers above may store or process personal data on their own infrastructure, which can be in more than one place. Vercel, Neon, Resend, Upstash, and Meta are hosted services and are not confined to a single location. Cloudflare R2 and Upstash use the region configured for that bucket or database. SiliconFlow receives prompts and embedding text at its API, outside the HelloChat application. The product does not add a separate transfer addendum in the app itself.
Security
Passwords are stored as bcrypt hashes. The session cookie is httpOnly so browser scripts cannot read it. Embed secrets are stored only as a SHA-256 hash. When the Meta app secret is configured, WhatsApp callbacks are rejected unless the X-Hub-Signature-256 header matches an HMAC-SHA256 of the raw body. Desk album and knowledge file reads require a signed-in session. The public avatar route returns only the oldest album image and only with an embed-scoped token. Traffic to the hosted app uses HTTPS. These controls reduce risk; they do not guarantee that unauthorised access cannot occur.
Your rights
Under the PDPO you can ask whether we hold your personal data, ask for a copy, and ask us to correct data that is inaccurate. We do not use personal data for direct marketing. You may also ask us to delete data as described on the data-deletion page. We may need to confirm that the request comes from you, or from someone acting for you, before we act. We aim to answer access and correction requests within 40 days.
You can complain to the Office of the Privacy Commissioner for Personal Data (https://www.pcpd.org.hk/).
Children
HelloChat is a tool for businesses. It is not directed at children. We do not knowingly collect personal data from children. If you believe a child has provided personal data through a merchant’s chat or a WhatsApp thread stored by this app, contact us and we will delete it.
Changes
This policy is effective 12 October 2026. When we change it, we will post the new version on /privacy and update the effective date. The page at /privacy-policy redirects here.
Contact
Email privacy@hellochatapp.com for privacy questions, access, correction, or deletion. Deletion steps are on /data-deletion.