Tenant scoping enforced at the server, not the UI: the user list, the approval routes, the roster, the permission and lead-visibility tables, and the integration credential routes all resolve the caller's organisation and filter or refuse on it.
Also called: data isolation · multi company security · my competitor uses the same software
- 1getAuthedUser / requireAdmin resolve the caller's organisation honouring subdomain, custom domain and owner impersonation.
- 2The user list returns only the recorded owner plus users whose metadata names the caller's organisation.
- 3Approval and role routes compare the target's organisation to the caller's and 403 on mismatch.
- 4Admin-only, org-scoped tables (permission presets, lead visibility) are registered as such in the database proxy, which stamps the organisation id server-side so the browser never supplies it.
The user-list route records the original defect: 'Previously this endpoint returned ALL Clerk users platform-wide, which meant an admin in Tenant A could enumerate Tenant B's users — and the Settings → Team Members tab couldn't tell who actually belonged to its tenant.' The approval route carries a matching note about cross-tenant promotion.
- A tenant-wide endpoint enumerated every user on the platform.
- Admin actions could target users in other companies.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →