ReplyTower Privacy Policy

Some statements in this policy describe processes that ReplyTower performs manually today. Section 9 says which ones.

---

1. Who we are, and how to read this policy

1.1 ReplyTower is a multi-tenant AI customer-support platform. ReplyTower operates it from Japan. In this policy, "we", "us", and "ReplyTower" mean that operator. The operating entity's registered name and registered address are not yet published here; we will publish them in the table above when they are settled, and you may request them in writing at info@replytower.com in the meantime.

1.2 ReplyTower sells to businesses. A business customer is a Vendor. Most Vendors run an Xboard, V2board, or WHMCS panel, and most sell VPN services or proxy services. A person who uses a Vendor's own service, and who exchanges messages with the AI assistant, is an End User.

1.3 This policy has two parts, because ReplyTower has two different roles:

1.4 If you are an End User, read Part B first. Your first point of contact for any privacy request is the Vendor whose service you use, not ReplyTower. Section 9 explains why, and explains what we do when a Vendor asks us to act.

1.5 We do not sell personal data. We do not share personal data for advertising.

---

2. Definitions used in this policy

---

PART A — VENDORS: WE ARE THE CONTROLLER

3. Vendor account data and billing data

3.1 What we collect

3.2 Why we process it, and the lawful basis

3.3 Passwords

We store portal passwords as bcrypt hashes. We never store a password in readable form.

3.4 Your rights as a Vendor

You may ask us to give you access to your account data, to correct it, to delete it, to restrict its processing, to port it, or to object to processing that rests on our legitimate interests. Send the request to info@replytower.com. Section 9 states how we handle the request and how long we take.

---

PART B — END USERS: WE ARE THE PROCESSOR

4. Our role, and who you should contact

4.1 When you chat with a Vendor's AI assistant, the Vendor decides why your messages are processed and how. The Vendor is the controller. We only process your messages on the Vendor's documented instructions. We are the processor.

4.2 Contact the Vendor first. The Vendor holds the relationship with you, the Vendor knows who you are in its own system, and the Vendor must answer your privacy request. The Vendor's own privacy policy names its contact point.

4.3 If you contact us directly, we will not act on your request by ourselves. We will tell you to contact the Vendor, and, where we can identify the Vendor, we will tell the Vendor that you contacted us.

4.4 The Vendor's own agreement with you, not this policy, sets the lawful basis for processing your messages.

5. What we store about End Users

5.1 Conversation records

5.2 IP addresses

We receive your IP address when you use the chat widget, and we use it live for rate limiting and for widget admission control. We hold it in short-lived Redis keys, and we do not store it on your conversation records. No conversation or message table in ReplyTower has an IP-address column.

5.2.1 One exception, stated plainly: a Vendor may add an IP address to its own blacklist. A blacklist entry is stored, and it stays stored until that Vendor removes it. The Vendor decides to create such an entry; we do not create one automatically from your traffic.

5.3 Data that we do NOT collect

5.3.1 End-User email addresses are not a stored field. ReplyTower has no database field for an End User's email address. An email address can still reach us if you type it into a chat message; in that case it sits inside the message content, under the retention rule for message content.

5.3.2 We never collect End-User voice or audio. ReplyTower produces text-to-speech audio only for a Vendor-facing briefing that summarises support trends. That audio contains no End-User recording, and we delete it after 30 days.

6. How your messages reach an AI model

6.1 To answer you, we send your message, the recent conversation context, and the retrieved knowledge-base context to a model provider. If you upload a screenshot, we also send the screenshot to a vision model.

6.2 The model provider is OpenAI by default. A Vendor may instead supply its own key for OpenAI or for Anthropic under BYOK. In that case the Vendor's own agreement with that provider governs the processing on the provider's side.

6.3 We do not train on your data, and neither does a provider we engage. We do not train any model on Vendor data or End-User data ourselves. Where a call runs under a ReplyTower platform key, we contract on terms under which that provider does not train on the submitted data.

6.3.1 BYOK carve-out. Section 6.3 does not extend to a model provider that the Vendor engages under BYOK. That provider's terms govern its own use of submitted data, including any training use, and we make no representation about them. Clause 12.6 of the Terms of Service states the same carve-out. If you are an End User and you need to know which applies to you, ask the Vendor whose service you use: the Vendor chooses the provider.

6.4 A human is not guaranteed. Each Vendor decides whether to enable human escalation. A Vendor can switch it off. If the Vendor switches it off, no ReplyTower feature will transfer your conversation to a person.

6.5 The Vendor must tell you that you are talking to an AI assistant. That duty sits with the Vendor, because the Vendor deploys the assistant.

6.6 Which provider account serves each call

There are three distinct paths, and they do not all use the same provider account. The table states who holds the key on each path.

6.6.1 CAUTION — read path (c) with care. A Vendor sets a chat relay by configuring openai_base_url. That setting moves chat completions to the Vendor's provider account. It does not move embeddings. If the Vendor does not also configure an embedding override, ReplyTower serves every embedding call through its own platform account against the official OpenAI API, even though the Vendor uses its own key for chat.

6.6.2 Embeddings are computed over knowledge-base content and over retrieved conversation context, so path (c) is a real flow of Vendor data and End-User data, not a technical detail. A Vendor that wants full isolation from ReplyTower's platform account must configure an embedding override as well as a chat relay. The override consists of the embedding_base_url setting and the embedding_api_key setting.

6.6.3 Where the Vendor does configure that override, ReplyTower does not use the platform key for embeddings, and it refuses to send its own platform key to a Vendor-controlled endpoint. If a Vendor has no embedding override and ReplyTower has no platform key configured, the call fails with an error rather than falling back to the Vendor's relay.

---

COMMON SECTIONS

7. Sub-processors

7.1 The ReplyTower Sub-processor List names every third party that processes personal data for us. It is reproduced in full as Appendix A at the end of this policy, and it is part of this policy.

7.2 We give Vendors at least 30 days notice before we add or replace a sub-processor.

7.2.1 A Vendor's use of BYOK does not remove OpenAI as a sub-processor. Section 6.6 explains why: unless the Vendor configures an embedding override, OpenAI still receives embedding requests under ReplyTower's own platform account.

7.3 Qdrant, our vector database, is not a sub-processor. We self-host it on our own infrastructure with a local storage volume. The stored vectors never leave ReplyTower infrastructure. Note that the text used to compute a vector is sent to a model provider first, under the path that Section 6.6 describes; it is the storage of the vector, not its computation, that stays with us.

7.4 We use no third-party behavioural analytics service and no third-party tracking service anywhere in the product. There is no Google Analytics, no Mixpanel, no Segment, no Amplitude and no PostHog in the portal, in the chat widget or in the backend, and we set no analytics cookie. ReplyTower does compute its own usage and conversation statistics inside the product, for the Vendor's own dashboard; that processing stays on our infrastructure and goes to no third party.

7.5 Email. We use no third-party service to SEND bulk or transactional email. Inbound email to our contact address is a different path and does involve third parties: it is routed by Cloudflare Email Routing and delivered to a Google mailbox. Because that address is the one this policy gives you for a data-subject request, both are listed as sub-processors in Appendix A.

8. Retention

8.1 Retention table

8.2 What is manual today, stated plainly

8.2.1 ReplyTower has no automatic job that deletes conversation rows or message rows. Our cleanup worker never deletes them.

8.2.2 The 30-day deletion after termination in the table above is a commitment that we perform by hand, directly against the database. We have not built software that performs it. We state this because it is true, and we will not imply an automation that does not exist.

8.2.3 A media object whose expiry field is empty stays in storage until someone deletes it by hand.

9. Data-subject rights, and how we handle a request

9.1 The rights

Under the GDPR you may ask for access (Art. 15), correction (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), and you may object (Art. 21). Under Japan's APPI you have comparable rights of disclosure, correction, and suspension of use.

9.2 Where to send the request

9.3 The process is manual

9.3.1 ReplyTower has no self-service deletion endpoint for End-User data, and no self-service export endpoint for Vendor data. No such function exists in the product today.

9.3.2 A Vendor therefore sends the request to info@replytower.com. The operator then performs the operation directly against the database, and confirms the result to the Vendor by email.

9.3.3 Response window: 30 days from the day we receive a complete request. If a request is complex, we may extend the window by a further 60 days, and we will tell you before the first 30 days end.

9.3.4 We may ask the Vendor to confirm the identity of the End User, because we do not hold End-User identity data of our own beyond the panel user ID.

9.4 Complaints

If you believe we have handled your data unlawfully, you may complain to a supervisory authority. In the EU, complain to the authority in your country of residence. In Japan, complain to the Personal Information Protection Commission.

10. International transfers

10.1 We host production in Tokyo, Japan.

10.2 The European Commission has issued an adequacy decision for Japan. That decision is the transfer mechanism for personal data that moves from the EEA to our Japanese infrastructure. No further safeguard is needed for that leg.

10.3 Onward transfers to sub-processors in the United States, and to international sub-processors, rest on the safeguards in each sub-processor's own terms.

10.4 We will sign the EU Standard Contractual Clauses with a Vendor on request. Send the request to info@replytower.com.

11. Security

11.1 Controls that we operate

11.1.1 The controls below are ones we operate today. The table is illustrative, not a complete inventory of every control or of every system, and the entries mean exactly what they say — each names the specific thing it protects, and none of them should be read as a general assurance about anything not named.

11.2 Tenant isolation, stated accurately

11.2.1 MySQL and Redis are shared instances. We isolate tenants by scoping every row to a vendor_id, with cascade deletion. We do not run a physically separate database per Vendor, and we do not claim that we do.

11.2.2 Qdrant uses a separate collection per Vendor. That is stronger isolation than row scoping.

11.3 Limits that we state honestly

11.3.1 Logs. We do not assert that message content never appears in application logs. We have not audited every log statement, so we will not make an absolute claim.

11.3.2 No control removes all risk. We cannot guarantee absolute security.

12. Cookies and local storage

12.1 The portal is a signed-in administration application. It sets no advertising cookie and no analytics cookie. It stores two different kinds of thing, and they are worth separating:

12.1.1 A session cookie. Your portal sign-in session is held in an HttpOnly cookie set by our backend. Being HttpOnly means page scripts cannot read it.

12.1.2 Browser local storage, used for interface state rather than for identifying you. It currently holds your light/dark theme preference, a one-time flag recording that an old sign-in format was cleared from your browser, a session identifier for the support widget on our own marketing pages, and a short cooldown timestamp for the prompt-evaluation button. This list is what the portal stores today; if we add another entry we will update this section.

12.2 The chat widget uses a backend-issued widget session token so that a browser conversation can continue. It sets no advertising cookie and no analytics cookie.

13. Children

ReplyTower is a business product. It is not directed at children. We do not knowingly process the data of a child. An End User's age is a matter between the End User and the Vendor.

14. Changes to this policy

14.1 We will publish any change here and raise the version number.

14.2 If a change materially affects Vendors, we will email the Vendor account address at least 30 days before the change takes effect.

15. Contact

Send any privacy question, request, or complaint to info@replytower.com.

Operator: ReplyTower, operating from Japan. Postal address: not yet published. Request it in writing at info@replytower.com.

16. Governing law

Japanese law governs this policy. The Tokyo District Court has exclusive jurisdiction of the first instance for any dispute about it. This clause does not remove a consumer's right to complain to a supervisory authority in the consumer's own country.

---

17. Version history

---

Appendix A — Sub-processor list

This appendix reproduces the ReplyTower Sub-processor List in full. It is part of this policy, and the ReplyTower Data Processing Addendum incorporates it by reference.

---

1. Purpose of this list

1.1 This list names every third party that ReplyTower engages to process personal data on behalf of a Vendor. The ReplyTower Data Processing Addendum ("DPA") incorporates this list by reference.

1.2 In this list, "Vendor" means the business customer of ReplyTower. "End User" means a person who uses the Vendor's own service and who exchanges messages with the ReplyTower AI assistant.

1.3 A Vendor who accepts the DPA gives a general written authorisation for ReplyTower to use the sub-processors in Section 2.

---

2. Current sub-processors

2.1 Notes on the Sentry entry

2.1.1 ReplyTower ships with Sentry disabled. The sentry_dsn setting is empty and the trace sample rate is 0.0.

2.1.2 CAUTION: ReplyTower has no configuration that scrubs personal data out of error reports. If the operator enables Sentry, an error report can contain personal data that appears in a stack trace. ReplyTower will update this list before it enables Sentry in production.

2.2 Notes on the OpenAI entry, and what BYOK does not cover

2.2.1 A Vendor may supply its own provider key or OAuth account under Bring Your Own Key (BYOK). That setting moves chat completions and vision to the Vendor's own provider account.

2.2.2 CAUTION: it does not move embeddings. Unless the Vendor also configures an embedding override — the embedding_base_url setting and the embedding_api_key setting — ReplyTower serves every embedding call through its own platform account against the official OpenAI API.

2.2.3 Embeddings are computed over knowledge-base content and over retrieved conversation context. BYOK therefore does not, by itself, remove OpenAI from this list for that Vendor.

2.2.4 Where the Vendor does configure the embedding override, ReplyTower does not use the platform key for embeddings, and it refuses to send its own platform key to a Vendor-controlled endpoint.

2.3 Notes on the email entries, and why they are listed

2.3.1 ReplyTower publishes info@replytower.com as the address for support, for a Data Processing Addendum request, and — under Section 9 of the Privacy Policy — for a data-subject access, erasure or export request.

2.3.2 That makes the mail path privacy-relevant even though it sits outside the Service. A data-subject request naturally contains the personal data of the person making it. Mail to that address is routed by Cloudflare Email Routing and delivered to a Google mailbox, so both process that content. They are listed for that reason.

2.3.3 Scope limit, stated precisely. Neither company is in the path of the Service. Cloudflare does not front the ReplyTower website: the domain resolves directly to our own host, and TLS terminates at our own web server. Neither receives conversation content, knowledge-base content, End-User messages or vector data. Their access is limited to email that somebody sends us.

---

3. Components that are NOT sub-processors

3.1 Qdrant is not a sub-processor. ReplyTower self-hosts Qdrant as a Docker Compose service on its own host, with a local storage volume. The stored vectors for Vendor knowledge bases and conversation content never leave ReplyTower infrastructure. Section 2.2 states separately which provider account computes those vectors.

3.2 No third-party behavioural analytics or tracking service. There is no Google Analytics, no Mixpanel, no Segment, no Amplitude, and no PostHog in the portal, in the chat widget, or in the backend. ReplyTower does compute its own usage and conversation statistics inside the product, for the Vendor's own dashboard; that processing stays on ReplyTower infrastructure and is disclosed to no third party, so it engages no sub-processor.

3.3 No third-party email-SENDING service. ReplyTower uses no third-party service to send bulk or transactional email. There is no SMTP provider, no SendGrid, and no Mailgun in the codebase. Inbound email is a separate path and is NOT covered by this statement — rows 8 and 9 of Section 2 list the sub-processors that handle it.

---

4. Changes to this list

4.1 ReplyTower will give each Vendor at least 30 days notice before it adds a new sub-processor or replaces an existing one. ReplyTower gives the notice by email to the Vendor's account email address, and it updates this document.

4.2 A Vendor may object to a new sub-processor within the 30-day notice period, on reasonable data-protection grounds. The Vendor sends the objection to info@replytower.com.

4.3 If the Vendor objects, ReplyTower will try to offer a change that avoids the processing. If ReplyTower cannot offer such a change, the Vendor may terminate the affected part of the service. Clause 9 of the DPA governs the effect of termination.

4.4 To receive these notices by email, a Vendor sends a subscription request to info@replytower.com.

---

5. Version history