Security by design.
Encryption in transit and at rest, strict access controls, and compliance enforced in code - consent, quiet hours, and opt-outs handled automatically, not left to a checklist.
The unsexy details that actually matter.
No marketing fluff. Real engineering controls - the kind that pass an enterprise security review.
Encrypted in transit + at rest
TLS 1.2+ in transit. Encrypted at rest. Industry-standard, no exceptions.
Role-based access controls
Granular permissions. Admin, agent, viewer - minimum-privilege by default.
Recording controls
Optional call recording with disclosure defaults on, retention you set, and handling designed to keep sensitive details like payment info out of stored records.
Retention enforced by design
A built-in retention engine enforces the window we agree with you in writing — deletion is a system behavior, not a support ticket.
US-based infrastructure
Your data lives in US-based cloud infrastructure, end to end.
Compliance enforced in code
Consent checks, quiet hours, instant opt-outs, and AI self-disclosure - built into how the agents run, not a policy PDF.
Compliance enforced in code.
The rules that keep outreach legal aren't a policy document - they're wired into how the agents run. Consent is checked before contact. Calls happen only within quiet hours for the contact's own timezone. Opt-outs take effect instantly. The AI discloses that it's AI, and recording disclosure is handled automatically. Sensitive data is redacted, and access is logged and audited.
Poll for truth. Webhook for speed.
How Zonara stays in step with the field-service or practice system you already run — and why a bad delivery can't corrupt anything.
15-minute incremental sync
Zonara re-reads what changed using the vendor's own "modified since" cursor, on a fixed cadence. The poll is the authoritative path: if everything else fails, the next poll still produces correct state.
Webhooks are a doorbell
Where a platform can push, the push only tells Zonara to re-poll now. The payload is verified, then hashed to absorb replays — and never parsed as data. Nothing a caller puts in a request body can become a record.
Per-tenant credentials
Each location's vendor credentials are stored server-side, isolated to that location, never exposed to a browser and never written to a log. You can revoke Zonara's access from inside your own system at any time.
Zonara requests only the access its shipped features exercise, and the read/write list published on each integration page is exhaustive. Payroll, pricebook cost data, employee compensation, and accounting ledgers are never read.
A write that fails goes to a durable retry queue rather than being dropped; entries that keep failing escalate to a person instead of retrying forever, and a failure writing to your system never voids a customer's booking. See the per-platform detail →
Three fail-closed layers between your data and anyone else's.
One isolation mechanism is a single point of failure. Zonara runs three independent ones, each of which denies by default, so a mistake in any one layer is caught by the next.
- 1Row-level security in the database
Postgres row-level security is FORCED on every tenant table, so the database itself refuses to return another tenant's rows — regardless of what the application asks for.
- 2A guard in the data layer
The ORM auto-scopes every query to the current tenant and raises rather than running a query it cannot prove is scoped.
- 3Access checks on every route
Each API route independently verifies that the caller has access to the location being requested, before the request reaches any data at all.
Row-level security coverage is enforced in continuous integration.
A conformance test walks every tenant table and fails the build if one is missing its row-level security policy. That means the protection can't quietly erode as the product grows: adding a new tenant table without isolation doesn't ship, because it doesn't build.
What happens to the data in between.
Encrypted in transit and at rest
Every connection — to your platform, to our sub-processors, to the dashboard — runs over TLS. Data at rest sits in managed, encrypted database and object storage.
Logs carry IDs, never contents
Application logs record entity identifiers only — never names, phone numbers, or message bodies. This is enforced by a shared logging helper used across the codebase, not by convention.
Sessions, not URLs
Authentication runs through WorkOS AuthKit, and sessions live in encrypted, httpOnly cookies. A session token is never placed in a link, so a pasted URL lands a stranger on the sign-in page.
Compliance is code, not a checklist
One queue is the sole enforcer for outbound contact: consent, quiet hours in the contact's own timezone, opt-outs, and frequency limits are checked there before anything is sent. Scheduling logic cannot bypass it.
Zonara does not hold a SOC 2 or ISO 27001 certification today. We would rather tell you that than let you find out during a review. What we can put in front of your security team is the architecture above: three fail-closed isolation layers with coverage locked by the build, least-privilege access stated exhaustively per platform, and logging that structurally cannot contain customer contact details.
Retention windows and any other contractual commitments are agreed in writing rather than advertised here — ask, and we'll answer with a number we can sign.
Who else touches the data.
Zonara runs on US-based cloud infrastructure. These are the services involved in delivering the product, and what each one is used for.
Need this as a formal list for a data-processing agreement? Ask us and we'll send it. Technical readers: the integration architecture is written up in more detail on the developer notes.
Need to satisfy your security team?
We'll send our security overview, a DPA, or any specific document your team needs.