How your conversations are protected

Separation is enforced in the database itself, through row-level security on every table, rather than by application code that a single bad query could bypass. A request without a valid session returns no rows — not an empty page rendered by a filter, but nothing at all, decided by Postgres.

We verify this rather than assume it: an automated check confirms row-level security is enabled on every table in the schema and that an anonymous client reads zero rows from conversations, messages, contacts and stored credentials. It counts the tables rather than naming a number here — the schema has grown twice since this page was written, and a number in prose is a claim that quietly goes stale.

The in-app platform-administration role exists for billing and account health, and it was built with no database permission to read message or contact content. That much is structural, not a policy we promise to follow — the access does not exist to be misused.

The people who operate the service are a different matter, and we will not pretend otherwise. Running Unibox means holding the keys to its infrastructure. The credential our own servers use bypasses row-level security by design — that is how the application answers a request at all — and the self-hosted WhatsApp gateway keeps message payloads in a database of its own. Today that access sits with the founder.

It is used to keep the service running and to investigate a problem you have reported. It is not used to read your conversations for any other reason, we do not sell them, and we do not train models on them. If your procurement requires audited, logged break-glass access, tell us — it affects what we prioritise.

The session data that keeps your WhatsApp numbers connected is encrypted with AES-256-GCM before they are written to the database. The key is held outside the database, so a copy of the database alone does not reveal them. GCM also detects tampering, so a modified value fails to decrypt rather than returning something wrong.

The table holding them has row-level security enabled with zero policies — deny-all by construction. Only our server processes can read it, and the application never returns a credential to a browser.

Message bodies are not separately encrypted by us. They are protected by our database provider's encryption at rest and in transit, by access controls, and by the workspace separation above — but we do not add a second application-level layer today. We would rather state that plainly than imply protection we have not written.

We are not SOC 2 certified. We are too early for that to be honest. If your procurement requires it, tell us — it affects what we prioritise.

Application and database run in the United States (Northern Virginia), and the WhatsApp gateway is self-hosted on the same infrastructure. Traffic is encrypted in transit with TLS — which is not the same as end-to-end encryption, and we do not claim to be. We do not store payment card details: billing runs through Stripe and card numbers never reach our servers.

Full detail on what we store and who processes it is in the Privacy policy.

Write to [email protected]. We are a very small team, so the honest promise is within one business day, and sooner for anything live. We will not threaten you for reporting in good faith. Please give us a reasonable window to fix an issue before disclosing it.

If a breach affects your data, we notify you and the relevant authority without undue delay.