Isolation that isn't a WHERE clause.

Row-level security, at the connection

Most multi-tenant SaaS isolates tenants by remembering to add WHERE tenant_id = ? to every query. That works until someone forgets. SendAvata sets the tenant on the database session and lets Postgres enforce the policy on every read and write. The application role cannot bypass it.

Isolation is tested the same way it's enforced: our test suite runs against the restricted role, not the owner pool, so a passing test means the policy held — not that the code happened to filter correctly.

What's isolated

• Agents, lines, calls, recordings, wallets and ledgers
• Brand assets, domains and email identity
• Disputes, credits and tier purchases
• CRM data, when enabled

Money and identity

Agent top-ups run through hosted checkout; we never see or store card numbers. Webhooks are verified and reconciled against the vendor by reference, so a dropped delivery can't leave a top-up unrecorded. Sessions are server-side; password reset and email verification are single-use and time-boxed.

Recordings and PII

Recordings are stored per workspace and served through short-lived URLs. Caller numbers are shown to agents as state plus last four; the full number is available to operators. Data export and deletion are available on request.