Concepts · Core concepts
Workspaces and sites
How data is scoped, and who can see what.
Dashboard data is scoped by workspace. Understanding the cut is understanding why a visit that really happened is not in front of you.
Three layers#
Site: one website or app. It has a public key, a secret, an origin allowlist and an environment. Every visit carries the siteId of the site that collected it.
Workspace: a group of sites plus the people allowed to see them. A site belongs to at most one workspace.
Account: a person. One person can be a member of several workspaces.
Scope is applied at read time#
A workspace sees the visits of the sites assigned to it. The visit itself carries no workspaceId, the scope is derived from siteId on every read.
The practical consequence: reassigning a site to another workspace takes its whole history with it. There is no data migration step, because there is nothing to migrate.
The most common integration mistake: the data-site-key in the page and the x-api-key on the server belong to two different sites. Both halves work, nothing reports an error, but visits land under one site and payment attempts under the other, and the matching screen stays empty.
Sites come from two places#
- Sites created on the API keys page: held in the database, managed by you.
- Sites configured on the server: set by the operations team, not editable from the dashboard.
A site of the second kind may belong to no workspace at all. Its data then exists but no workspace can see it.
How accounts are created#
There is no sign-up page. Accounts come from invitations: a workspace owner creates a single-use link valid for 7 days. See Members and invitations.