Skip to content
Data protection

What we hold, and why we hold it

RapidRoot processes conversation data on behalf of the businesses that use the platform. This page explains the categories of data involved, the reason each category exists, and the controls customers have over it.

Categories of data

How to read this page

This page is maintained by RapidRoot to answer common security and privacy questions about our platform. It describes practices that are in place today and clearly labels anything that is planned. It is not a certification, an audit result, or independent verification.

We group data into four categories so it is clear which controls apply to what.

CategoryExamplesWhy it exists
Account dataWorkspace name, user names, email addresses, rolesTo create accounts, authenticate users and apply permissions
Configuration dataChannel settings, templates, automation rules, API key metadataTo run the workspace the way the customer configured it
Conversation dataMessages, call metadata and transcripts a customer routes through the platformTo deliver, display and automate the customer's conversations
Operational dataApplication logs, error traces, delivery eventsTo diagnose failures, investigate incidents and improve reliability

Handling principles

Purpose limitation

Customer conversation data is used to operate the service for that customer. It is not sold, and it is not used for unrelated commercial profiling.

Separation by workspace

Data is scoped to the workspace it belongs to. Application authorisation checks the workspace on every request rather than trusting the client.

Minimum necessary access

Access to production data by our team is limited to what is needed to operate and support the service, and is intended to be requested rather than standing.

Customer ownership

The customer owns the content of their conversations. We act as a processor for that content on their instructions.

Retention philosophy

Our retention philosophy is to keep data for as long as it is useful to the customer's operation of the product, and no longer than that. Rather than publishing a fixed schedule we cannot yet guarantee across every subsystem, we describe the intent:

  • Account and configuration data is retained while the workspace is active.
  • Conversation history is retained so customers can review and audit their own conversations, and is removed when a workspace is deleted.
  • Operational logs are kept for a limited diagnostic window and are not intended as a long-term record of conversation content.
  • Deletion requests are handled on request through our support channel.

Workspace deletion on request

In place today

Customers can request deletion of a workspace and its data through support.

Self-serve data export

Planned

A self-service export of conversation history from the dashboard is planned.

Configurable retention windows

Planned

Per-workspace retention settings are on the roadmap and are not available today.

Customer control

  • Choose what data is routed into the platform in the first place — the strongest control available.
  • Manage who can access the workspace and at what role level.
  • Rotate or revoke API credentials at any time.
  • Request an export or deletion of workspace data through support.
Send less data

If a use case does not require personal or sensitive fields, do not send them. Redacting at the source is more reliable than any downstream control.