Security and data handling

Transport

All API traffic runs over HTTPS with TLS 1.2 or higher. Plain HTTP requests are rejected rather than redirected. Webhook deliveries to your endpoint are made over HTTPS only, and your endpoint must present a valid certificate.

Every webhook payload carries an x-bluereacher-signature header containing an HMAC-SHA256 of the raw request body, computed with your endpoint's signing secret. Verify it before trusting a payload, and compare using a constant-time comparison. The verification steps and a working handler are in webhooks.

Authentication

API keys are workspace-scoped bearer tokens, prefixed brk_, and are shown once at creation. A key grants full API access to its workspace, so treat it as a production credential: server-side only, never in browser or mobile client code, never in a repository, rotated on staff changes and on any suspected exposure. Details and the rotation flow are in authentication.

What data we hold

Running the service requires holding the contents of the conversations you send and receive: contact phone numbers and any contact fields you supply, message bodies and media, delivery and read status, opt-out records with their evidence, and line configuration. Request metadata, including timestamps, endpoints, status codes, and trace IDs, is retained for operations and support.

Retention and deletion

Message and contact data persists for the life of your workspace so your conversation history stays intact. You control removal at the record level: deleting a contact through the contacts API removes the contact record and its associated message history.

Opt-out records are the deliberate exception. They are retained after a contact is deleted, because a suppression list that forgets is worse than useless: re-importing a list would resurrect someone who asked you to stop. This also matches the record-keeping obligations in the compliance guide, which call for five-year retention of do-not-call requests.

On account closure, workspace data is deleted after a 30-day window during which an export can be requested. Suppression records are retained beyond that point for the same reason.

Your own retention obligations

Compliance record-keeping is yours, not ours, and it outlives your account. Export consent records, message history, and revocation evidence into your own system on a schedule rather than treating the platform as the archive of record. The five-year retention target and the specific items to keep are listed in the compliance guide.

Subprocessors

Blue Reacher runs on infrastructure providers for hosting, database, storage, and messaging delivery, and uses standard operational tooling for error monitoring and support. The current subprocessor list, with each provider's role and processing location, is available on request and is provided as an appendix to the data processing agreement. Contact support for the current version rather than relying on a page that could go stale between reviews.

Data processing agreement

A DPA is available for customers who need one, including standard contractual clauses where the transfer requires them. Request it through support.

What we do not do

We do not sell customer data. We do not use the contents of your conversations to build or train models. We do not share your contact lists between workspaces. Lines are dedicated per workspace, so your sending is not pooled with another customer's traffic, which is both a security property and the deliverability property described in Apple and iMessage.

For a security review

Reviewers usually want the same five things. Send them: this page, the authentication page for credential handling, the webhooks page for signature verification, the compliance guide for consent and retention practice, and the DPA with its subprocessor appendix from support. Anything they ask for beyond that, send it to us directly and we will answer it rather than have you guess.