Protecting data as it moves and while it rests
A high-level description of how RapidRoot protects data in transit and handles credentials. We deliberately do not publish internal configuration, key material or algorithm choices in detail.
Data in transit
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.
All traffic to the RapidRoot dashboard and to our APIs is served over HTTPS using TLS 1.2 or higher. Plain HTTP requests are redirected to HTTPS. Webhook deliveries from RapidRoot to customer endpoints are sent to HTTPS destinations.
Messaging and voice delivery involves third-party network and messaging providers. Those legs are governed by the providers' own transport security and terms, which we do not control.
Data at rest
Customer data is stored on managed cloud database and storage services, which provide encryption at rest at the storage layer. We rely on the provider's encryption rather than claiming a bespoke, independently reviewed cryptographic implementation of our own.
RapidRoot does not currently offer end-to-end encryption, customer-managed encryption keys, or field-level encryption of message bodies. If your procurement process requires any of these, tell us during evaluation so we can be explicit about the gap.
Credential handling
- API keys are scoped per environment so a test credential cannot act on production data.
- Keys can be rotated and revoked by workspace administrators at any time.
- Secrets used by our own services are held in managed secret storage, not in source code or client-side bundles.
- Passwords are stored as salted hashes by our managed authentication layer — never in plaintext and never recoverable by our team.