ChatRail security and data handling

Encryption in transit

Every public connection to ChatRail uses HTTPS: the API, the dashboard and the MCP endpoint. In production the API refuses to start with a database connection that is not TLS, and it only accepts webhook destinations that use HTTPS.

The WhatsApp transport runs on the same private network as the API and has no public address. Messages between your linked number and the people it talks to carry WhatsApp’s own end-to-end encryption, as on any linked device; the transport is that linked device. What the transport reports back to ChatRail is signed with a key that belongs to that one connection, so a forged callback is refused.

Encryption at rest

Anything that is a secret is stored encrypted with AES-256-GCM under a key that exists only in the server environment: AI provider keys, proxy logins and the keys that sign transport callbacks. API keys are never stored at all. ChatRail keeps a hash and shows the key once.

Messages, delivery records and contexts live in a managed PostgreSQL database on Railway (see Subprocessors). Attachments are not copied into ChatRail’s own storage: while a message is retained, its file is fetched from the transport and served through the API, always as a download, never rendered on a ChatRail page.

API access

API keys are 256-bit, scoped to one workspace and to the actions they may take (for example messages:write or webhooks:read), and can be revoked at any time. Use them only from a server you control; keep them out of source control, logs and browsers.

Dashboard sign-in is a one-time code sent to your email, or Google or GitHub. A code is tied to the address, works once, expires after ten minutes and locks after five wrong tries. Sessions last 30 days. Team roles (owner, admin, developer, viewer) limit what each person can change.

MCP clients connect with OAuth. The consent screen names the client, the host it will send the code to and the scopes it asks for; redirect addresses must use HTTPS or be on your own machine. Every change made through MCP is recorded.

Webhooks

Every webhook is signed with the endpoint’s own secret, shown once when the endpoint is created. Destinations must use HTTPS and resolve to a public address; private, loopback and cloud-metadata ranges are refused, in their IPv6 spellings too. An endpoint that fails 50 deliveries in a row is paused and its owner is emailed; events are kept until it is re-enabled. Verify the signature, reject stale events and process each event once.

Connections and numbers

Each WhatsApp number has its own transport session. A pairing QR code is single-use, tied to your workspace and expires in 45 seconds. Deleting a connection ends its WhatsApp session and clears its credentials. On the Team plan a number can link through its own proxy; the proxy must be a public IP address, and its login is encrypted as above and never shown again.

Numbers are protected from being reported: per-recipient and daily sending limits, a cap on number lookups and on group member adds, and anomaly alerts to the operator. Someone who replies with a stop word is added to your workspace’s opt-out list, further sends to them are refused and the AI does not reply. There is no switch for that.

Data minimisation and retention

Attach only the context a reply needs. Retention is set per workspace: 7 days on Sandbox, 90 days on paid plans, adjustable from 1 day to 10 years. Context attached to a message has its own window, 30 days by default, and never outlives the message it belongs to.

If you use automations, a short record of each run (its steps, what they found and the customer’s number) is kept for the same window and then deleted. Details a rule keeps about a customer have their own window: six months after they were last updated. The business facts page stays until you change or delete it.

Deletion

When data passes its window, or you delete it, ChatRail runs a tracked deletion job rather than a silent cascade: the deletion is recorded and a tombstone stays, so the removal can be audited while the content is gone. Expired attachments, login codes and idempotency records are swept the same way.

AI processing

AI replies are off by default and enabled per connection. There are two ways to run them:

• Your own key. Stored encrypted as above, never returned, and used only with the provider you configured. ChatRail refuses to store one of its own API keys in that field.
• Managed AI (Core + AI and Team). Replies run on ChatRail’s key through OpenRouter, on a model ChatRail chooses. The conversation and context for those replies go to OpenRouter and on to the model’s vendor.

In both cases only the conversation and the context you attached are sent, and context marked restricted is never sent. Customer messages are given to the model as data, not as instructions, and an automatic reply that names a link or phone number found nowhere in your instruction, your context or the conversation is held as a draft for a person instead of being sent. If AI is off, no message content leaves ChatRail for a model provider.

Automations

Automations are rules a workspace sets up: when a customer writes, a form is sent or a set time comes, ChatRail checks the message, runs the steps the owner chose and replies. Nothing runs until a rule is switched on.

• Replies use the normal send path. Opt-outs, sending limits and plan limits apply exactly as they do to any other message.
• Google apps. Sheets, Drive and Calendar are connected by the owner through Google’s own sign-in, handled by Composio. ChatRail never sees the Google password. A rule can only do what its steps say, such as add a row, save a file or book a time, and disconnecting the app stops it.
• Website forms and Shopify. Each source gets a private address that only it knows. Passwords, card numbers and one-time codes sent to it are dropped on arrival, and an entry is kept only while its run is working: it is removed when the run finishes.
• Business facts. The page an owner writes about their business is stored with the workspace. Automations that answer questions use only that page.
• Customer memory. A rule can keep a few short details about a customer, such as a name or a last order number, for their next message. The rule decides what is kept. A value that is not one short line, or that has a link in it, is not kept. Each detail is deleted six months after it was last updated. The owner can see everything that is kept in the dashboard, delete one customer’s details, or forget a phone number on request. Nothing is kept for forms, schedules or group chats.
• Run history. Each run records its steps and what they found. The customer’s number is hidden in the middle wherever it is shown, and the record is deleted when the workspace’s retention window ends.
• AI in rules. A rule uses AI only if its owner added an AI step. The message text and any details the rule passes on are sent to the AI model provider. See AI processing above for how AI is run.

What customers and forms send is treated as data, never as instructions. A message that looks like an attempt to steer the AI gets no AI step, and text an AI step writes is checked for links and numbers the owner never gave before it is sent.

Logs and analytics

ChatRail’s logs never contain message text, phone numbers, keys or codes. Redaction is applied by the logger itself rather than left to each developer, and the transport’s own log level is set so it records neither. This was checked against the live service, not only the code.

This marketing site uses PostHog and DataFast to measure visits, and PostHog to replay how visitors use the public pages. The dashboard sends PostHog usage events and error reports but is not recorded: nothing you or your customers write is captured.

Subprocessors

These are the third-party services ChatRail uses to run the product, and the data each one handles:

Google is not a subprocessor. Google Sheets, Drive and Calendar are the owner’s own accounts. A rule writes there only what the owner told it to.

WAHA is not a subprocessor. It is the WhatsApp transport, and it is ChatRail’s own infrastructure, deployed and operated by us with its own lifecycle and storage. It is reached only over a private network and is not exposed publicly.

Current status

ChatRail is live and paid plans are available. Some things are not in place, and we would rather say so than imply otherwise: ChatRail does not hold SOC 2 or ISO 27001 certification, does not offer a contractual uptime SLA, and has not published a Data Processing Agreement (DPA). Platform status is at /status. If a compliance requirement depends on any of these, contact us before you rely on it.

Reporting a vulnerability

If you believe you have found a security issue in ChatRail, email security@chatrail.dev (also listed at /.well-known/security.txt). Include what you found, the steps to reproduce it, and the impact you believe it has. This address is the right route for the API, the dashboard, the marketing site and the linked-device transport.

Please do not access, modify or delete data that is not yours, and do not run tests that degrade the service for other customers. We aim to acknowledge reports within three business days and will keep you updated as we investigate.

We will not pursue or support legal action against researchers who act in good faith: who stay within the scope above, avoid privacy violations and service disruption, and give us a reasonable opportunity to fix an issue before disclosing it publicly.