Security overview · Version 2026-08-14
If you run a group, the question that matters is whether one store can ever see another. Access is resolved on the server from your own account record and scoped by group and rooftop — an out-of-scope request is refused rather than quietly returning an empty page. Below: how that is enforced, how credentials and reporting access are handled, and what Zumbay deliberately does not do.
Every dashboard request resolves scope on the server from the caller’s account record. A dealership user’s group and rooftops come from their membership, never from a link, query parameter or header. An agency sees only the dealerships explicitly assigned to it. Requesting a rooftop or a client outside your grant returns a refusal, not an empty page.
Server-side authorization is the primary control. Row-level security in the database is a second, independent layer, and no client role has any write permission on a membership, role, assignment, subscription, invoice or agreement record.
Provider credentials are encrypted and are never returned to a browser, rendered in the interface, or included in an error message. Privileged keys exist only in server-side configuration.
Reporting data is read through a dedicated, read-only database role that can select from a fixed set of reporting views and nothing else. That role has no write permission anywhere, and proprietary internal fields are not present in any view, so they cannot be exposed by a software fault.
Checkout is hosted by the payment provider. No card details are entered on or transmitted through a Zumbay page. Subscription state is written only from a cryptographically verified provider event, never from a browser redirect.
No demo or sample data is ever shown in production. No number is displayed without its source and the time it last updated. Where a source is not connected, the interface says so rather than showing a zero.
Zumbay records the version you accepted at checkout, together with the time of acceptance.
