How your book stays yours.
Last updated 11 September 2026.
The two things that matter most to a distributorship: no patient data ever enters Syntra, and no workspace can read another's. Both are enforced by the database, not by a rule we remembered to write in application code.
No protected health information
A case record is a commercial record: surgery date, surgeon, facility, vendor, rep, amounts, PO status. There is no patient field anywhere in Syntra. When a book is imported, columns that look like a patient name, MRN, date of birth or member id are identified and blocked — the import refuses them outright rather than importing and hiding them. Because no PHI is stored, Syntra does not require a Business Associate Agreement.
Workspace isolation
Every distributorship gets its own workspace. Isolation is layered:
- Row-level security, forced. The database itself refuses rows outside your workspace. It is enabled in forced mode, so it applies to the table owner too.
- A non-privileged role per request. Each request opens a transaction, drops to an unprivileged database role, and pins your workspace for the life of that transaction. Nothing is cached between requests, so one request cannot inherit another's workspace.
- The workspace is never taken from the browser. The selection is carried in a signed cookie bound to your user id, and it is treated only as a hint — re-checked against live membership on every single request.
- Extra policies narrow, they never widen. Where a second rule sits on top of workspace isolation, it is written as a restrictive policy, so it can only subtract access.
This is tested rather than asserted: the test suite builds a user who belongs to two workspaces at once — the case most likely to leak — and proves that no record from one appears in the other.
Access inside a workspace
People you invite get a role: owner, bookkeeper or sales rep. A sales rep sees their own cases and their own commission, not the whole book and not what colleagues are paid. Roles are enforced in the database, not merely hidden in the interface.
An activity log that cannot be rewritten
Every change is stamped with who made it and when, in an append-only log. It cannot be edited or deleted — by your team, or by us.
Payments
Subscriptions run through Stripe. Card details go directly to Stripe and are never seen or stored by Syntra. Payment events arrive over a signed webhook whose signature is verified before anything is acted on, with replay and out-of-order protection.
In transit and at rest
All traffic is served over HTTPS with HSTS. Data at rest is encrypted by our database provider. The application sets standard protective response headers and cannot be embedded in a frame by another site.
Providers
| Provider | Role |
|---|---|
| Vercel | Hosting for the site and the application |
| Supabase | Database, authentication, file storage, backups |
| Stripe | Subscriptions and payment |
| Anthropic | The in-app assistant |
| ElevenLabs | Voice for the assistant |
What we do not claim
We would rather be straight with you than impressive. Syntra is a small, focused product: we hold no SOC 2 report, have not commissioned a third-party penetration test, and do not offer a contractual uptime guarantee. What is written above is what is actually built and actually tested. If your IT reviewer needs something specific, ask — we will answer honestly about what exists and what does not.
Reporting a vulnerability
If you believe you have found a security problem, email hello@syntrahealthanalytics.com with enough detail to reproduce it. We will acknowledge you, keep you posted while we fix it, and credit you if you would like. Please give us a reasonable chance to fix it before publishing, and do not access or alter anyone else's data while testing.