Workspaces overview
# Workspaces overview
Every verification starts by picking a **workspace** in the [dashboard](https://dashboard.self.xyz). A workspace is the kind of question you ask about a user; the flow you configure decides the exact rules. There are five:
| Workspace | The question it answers | Cost |
| -------------------------------------------------------------------------- | --------------------------------------------------------- | ---------- |
| **[Pre-KYC](/docs/self-enterprise/workspaces/pre-kyc/)** | "Who is this user?" (identity rules, plus data reveals) | 25 credits |
| **[Age Verification](/docs/self-enterprise/workspaces/age-verification/)** | "Is this user old enough?" | 10 credits |
| **[Proof of Human](/docs/self-enterprise/workspaces/proof-of-human/)** | "Is this a unique, real person?" | 10 credits |
| **[Sovereign](/docs/self-enterprise/workspaces/sovereign/)** | "Is this user from a country I allow?" | 10 credits |
| **[Custom Config](/docs/self-enterprise/workspaces/custom-config/)** | "Give me exactly these identity fields, under my custody" | 25 credits |
## How to choose
Ask what your product decision actually depends on, and pick the narrowest workspace that answers it. Narrower workspaces disclose less about your users and cost less:
- You need **identity attributes** (name, date of birth, document details) or several rules at once → **[Pre-KYC](/docs/self-enterprise/workspaces/pre-kyc/)**. It's the only workspace with data reveals.
- You only need an **age floor** → **[Age Verification](/docs/self-enterprise/workspaces/age-verification/)**. Nothing else is asked or revealed.
- You need **one account per person** → **[Proof of Human](/docs/self-enterprise/workspaces/proof-of-human/)**. It's built around the [nullifier](/docs/self-enterprise/get-started/how-it-works/#one-account-per-person-nullifiers).
- You need to restrict access to **specific nationalities** → **[Sovereign](/docs/self-enterprise/workspaces/sovereign/)**. The allowlist is the whole workspace.
- You need the **raw identity data itself, stored by you and not by Self** → **[Custom Config](/docs/self-enterprise/workspaces/custom-config/)** (early access, Enterprise plan). Your organization takes custody of the disclosed fields; Self keeps nothing.
## What they all share
Whatever the workspace, the mechanics are identical:
- **The same integration.** One `sessions.create(...)` call, a hosted page the user opens, and a signed `verification.completed` webhook. Switching workspaces later is a config change, not a code change.
- **The same privacy model.** The user proves facts with a zero-knowledge proof; you receive pass or fail results (plus any fields you explicitly requested), never the underlying document. See [How verification works](/docs/self-enterprise/get-started/how-it-works/). Custom Config goes one step further: the disclosed data is delivered **only to you**, and Self stores none of it.
- **A security level.** Every workspace lets you choose **Standard** (the document is genuine) or **Hi-security** (the user physically scanned the document's chip, the default). See [Disclosures](/docs/self-enterprise/flows/disclosures/#security-level).
- **Both [verification modes](/docs/self-enterprise/flows/verification-modes/)**: Backend (the default) or On-chain. The exception is Custom Config, which is backend-only.
- **Test and live environments**, mock passports, and the same [per-verification pricing model](/docs/self-enterprise/billing/credits-and-usage/).
A workspace holds **one active configuration at a time**, and a deployed configuration is immutable: to change it, archive it and create a new one. The exception is Custom Config, where an organization runs **many active configs side by side**. See [Anatomy of a flow](/docs/self-enterprise/flows/anatomy/).
:::cta{title="Found your workspace?" href="https://dashboard.self.xyz" button="Create it in the dashboard"}
Deploy a configuration and test it with a mock passport before writing any code.
:::
## Related
- [Configure a workspace](/docs/self-enterprise/dashboard/configure-a-workspace/): building the flow in the dashboard.
- [Quickstart](/docs/self-enterprise/get-started/quickstart/): from sign-up to a verified user in ten minutes.
- [Credits and usage](/docs/self-enterprise/billing/credits-and-usage/): how the costs above are charged.
Read https://docs.self.xyz/docs/self-enterprise/workspaces.md so I can ask questions about this Self documentation page.
On this page
Every verification starts by picking a workspace in the dashboard. A workspace is the kind of question you ask about a user; the flow you configure decides the exact rules. There are five:
| Workspace | The question it answers | Cost |
|---|---|---|
| Pre-KYC | ”Who is this user?” (identity rules, plus data reveals) | 25 credits |
| Age Verification | ”Is this user old enough?“ | 10 credits |
| Proof of Human | ”Is this a unique, real person?“ | 10 credits |
| Sovereign | ”Is this user from a country I allow?“ | 10 credits |
| Custom Config | ”Give me exactly these identity fields, under my custody” | 25 credits |
How to choose
Ask what your product decision actually depends on, and pick the narrowest workspace that answers it. Narrower workspaces disclose less about your users and cost less:
- You need identity attributes (name, date of birth, document details) or several rules at once → Pre-KYC. It’s the only workspace with data reveals.
- You only need an age floor → Age Verification. Nothing else is asked or revealed.
- You need one account per person → Proof of Human. It’s built around the nullifier.
- You need to restrict access to specific nationalities → Sovereign. The allowlist is the whole workspace.
- You need the raw identity data itself, stored by you and not by Self → Custom Config (early access, Enterprise plan). Your organization takes custody of the disclosed fields; Self keeps nothing.
What they all share
Whatever the workspace, the mechanics are identical:
- The same integration. One
sessions.create(...)call, a hosted page the user opens, and a signedverification.completedwebhook. Switching workspaces later is a config change, not a code change. - The same privacy model. The user proves facts with a zero-knowledge proof; you receive pass or fail results (plus any fields you explicitly requested), never the underlying document. See How verification works. Custom Config goes one step further: the disclosed data is delivered only to you, and Self stores none of it.
- A security level. Every workspace lets you choose Standard (the document is genuine) or Hi-security (the user physically scanned the document’s chip, the default). See Disclosures.
- Both verification modes: Backend (the default) or On-chain. The exception is Custom Config, which is backend-only.
- Test and live environments, mock passports, and the same per-verification pricing model.
A workspace holds one active configuration at a time, and a deployed configuration is immutable: to change it, archive it and create a new one. The exception is Custom Config, where an organization runs many active configs side by side. See Anatomy of a flow.
Related
- Configure a workspace: building the flow in the dashboard.
- Quickstart: from sign-up to a verified user in ten minutes.
- Credits and usage: how the costs above are charged.
Was this page helpful?
Thanks — what went wrong?
Thanks for your feedback!