Watari Docs
Getting Started

Security and compliance

Token encryption, multi-tenant isolation, SOC 2 status, data residency, and the sub-processor list.

TL;DR

Token encryption, multi-tenant isolation, SOC 2 status, data residency, and the sub-processor list.

Security and compliance

A factual summary of Watari's security posture for customers and procurement teams evaluating the product.

For contractual security commitments, see Exhibit C of the Data Processing Agreement.

Integration token encryption

Every OAuth access token and refresh token Watari holds on your behalf — for Zendesk, Intercom, GitHub, Slack, Jira, and Linear — is encrypted with AES-256-GCM before being written to the database. The encryption key is held in a Vercel Sensitive Environment Variable and is never logged, never included in error messages, and never transmitted outside the encryption/decryption code path.

Decryption happens only inside server-only code that runs on Watari's servers, at the moment the token is needed to call a provider API. Tokens are never returned to the browser. If an attacker gained read access to the database rows without the key, the ciphertext would be unreadable.

Inbound webhook signing secrets (used to verify that payloads from Zendesk, Intercom, GitHub, and Razorpay are authentic) are encrypted the same way.

Multi-tenant isolation

Every customer-data table in Watari's database carries an organization_id column and a Postgres Row Level Security (RLS) policy that restricts SELECT, INSERT, UPDATE, and DELETE to rows owned by the authenticated organization. Isolation is enforced at the database layer — it does not rely on application-level filtering alone.

Every new migration that adds a customer-data table is required to ship with a paired RLS policy. A missing policy is treated as a release-blocking issue.

There is a narrow set of server-side operations that intentionally bypass RLS using a service-role client: OAuth callbacks (which run before a user session exists), background pipeline jobs, and a small number of administrative RPCs that have already validated the caller's organization membership. Each use of the service-role client is justified inline in the source code and reviewable in the repository.

Cross-tenant data access is structurally prevented, not just a convention. A bug in application-level filtering cannot expose one organization's data to another, because the database itself enforces the boundary.

Data residency

Watari's primary database runs on Supabase managed Postgres hosted on AWS in the United States (us-east-1). Disk-level AES-256 encryption is provided by the underlying AWS infrastructure. Automated daily backups with a 30-day retention window are stored encrypted in the same region.

If your contract requires data to be hosted in a specific region, contact sales before subscribing — region migrations after subscription creation require coordination.

Sub-processors

The full list of third-party services Watari relies on to operate — including AI providers, infrastructure, email, and payment processors — is published at /legal/subprocessors. The list is kept current and Watari provides 30 days' advance notice of new or replaced sub-processors by email.

SOC 2 status

SOC 2 Type II is in progress. The observation window is underway with a Vanta-supported audit programme. The certification target date will be published here once it is locked. Contact security@watari.ai for the current attestation status or to request a copy of the controls summary.

Webhook signature verification

Every inbound webhook from Zendesk, Intercom, GitHub, and Razorpay is HMAC-verified before any processing occurs. Watari reads the raw request body and checks the provider-supplied signature header before parsing the payload. Payloads that fail signature verification are rejected immediately. Duplicate events are deduplicated by event ID so replayed webhooks do not trigger double-processing.

What Watari never stores

A few categories of data that Watari explicitly does not retain:

  • Internal admin notes from your support tool. Watari's webhook scope reads public ticket content and conversation threads. Private internal notes written by your support agents — Zendesk internal notes, Intercom private notes — are outside the webhook scope and are not read or stored.
  • Production secrets from your codebase. During repository indexing and PR generation, Watari reads your source files. Files matching .env*, secret-named patterns, and common credential formats are excluded from the index. Watari does not store the contents of secret or credential files.
  • Customer payment-card data. Payment is processed entirely by Razorpay. Watari never receives or stores card numbers, CVVs, or bank details. The billing session flow redirects to Razorpay's hosted checkout, and only the subscription status is returned to Watari after completion.

Next: Review the sub-processor list or read about disconnecting integrations — token revocation and data retention windows.

On this page