Security

Readoutreads your ERP and never writes to it, keeps each workspace’s data in its own store, and holds your API key in a form that is useless without a key we keep somewhere else. Here is what each of those means in practice.

The connection is read-only, and that is enforced in code

The Odoo connector will dispatch only a fixed set of read methods — search, search_read, read, search_count, read_group, fields_get. Anything else raises before it reaches the network, so a write cannot be issued by mistake, by a future change, or by anything you have not authorised.

You give Readout an Odoo API key, not a password. A key can be revoked from Odoo at any time without changing the account’s password, and it does not unlock the Odoo web interface. Point it at a dedicated read-only reporting user and the blast radius is exactly what that user can see.

Each workspace has its own warehouse

Your synced data is not a row in a shared table with a tenant column on it. Every object lives under a per-workspace prefix, and every read is scoped to that prefix before it is issued — there is no query shape that reaches another workspace’s data, because the key it would have to name is never constructed.

That is not left to review. A separate suite of isolation tests runs as its own required check on every change, so anything that weakens the boundary fails the build rather than the audit.

Your API key is encrypted at rest

Keys are stored with envelope encryption: each record gets its own data key, that key is wrapped by a master key held outside the database, and the workspace’s identity is bound into the ciphertext as authenticated data — so a record cannot be decrypted in the context of a different workspace even if it were moved there.

The API never returns a stored key. Once saved it is not shown again, in the product or in a log; the connection form leaves the field blank and re-enters only to replace.

Access inside your workspace

Sign-in and workspace membership are handled by Clerk. Within a workspace, every action is gated on a role — owners manage billing and the connection, admins manage data and mappings, viewers read. Permissions are checked on the server for every request, not hidden in the interface.

Cookies and tracking

Readout sets one kind of cookie: the session cookie that keeps you signed in, issued by Clerk. It is strictly necessary — without it there is no way to know who is asking for a report — so there is no consent banner to click, because there is nothing to consent to.

There is no analytics, no advertising, no session recording, no tracking pixel, and no third-party script that follows you between sites. We do not know which reports you opened. Our authentication provider’s anonymous SDK telemetry is switched off, and the site’s content-security policy no longer permits the request at all.

Payment happens on Stripe’s own hosted checkout, not here, so card details never reach our servers. Stripe sets its own cookies on its own pages under its own policy.

What we do not claim

We do not hold SOC 2, ISO 27001 or any other certification today, and we would rather say so here than let a page like this imply otherwise. If your procurement process needs one, tell us where you are in the process and we will tell you honestly whether we can meet it.

Questions, or a security report

Write to support@salesreadout.com. We answer within one business day. If you believe you have found a vulnerability, say so in the subject line and we will prioritise it over everything else in the inbox.

More detail on the day-to-day: Connect your Odoo and the FAQ.