Accounts and workspaces
Dockt separates administration from day-to-day verification by using Accounts and Workspaces.
An Account is your top-level customer boundary. It owns your Workspaces, account users, and account-scoped API credentials. You normally interact with the Account when setting up access or managing environments.
A Workspace is where verification work happens. Its configuration, credentials, Documents, Assessments, Decisions, and webhooks are isolated from every other Workspace. A resource created in one Workspace cannot be read or used from another Workspace.
For example, you might use separate Workspaces for development and production. Each has its own credentials, configuration, data, and webhook endpoint, which prevents test traffic from mixing with production traffic.
Choose the right boundary
Section titled “Choose the right boundary”Use account scope to manage:
- Account profile information.
- Account users and invitations.
- Workspaces owned by the Account.
- Account-scoped API credentials.
Use workspace scope to manage:
- Features and enabled social compliance packages.
- Documents and Assessments.
- Decisions and Decision Outcomes.
- Workspace API credentials.
- Webhook endpoints.
Most verification requests require a workspace-scoped credential.
If your product only uploads documents and runs Assessments, you can treat the Account as an administrative container and perform all runtime requests with a workspace credential.
Scope resolution
Section titled “Scope resolution”A workspace API credential always operates in the Workspace assigned when the credential was created. You don’t select or override its Workspace on each request. When you call POST /v1/documents, for example, the new Document automatically belongs to that credential’s Workspace.
A browser session can select an available Account or Workspace through POST /v1/auth/scope. The selected scope applies to subsequent session requests.
Call GET /v1/auth/me to inspect the active scope and permissions for either authentication method.
Resource ownership
Section titled “Resource ownership”Dockt resource IDs have recognizable prefixes, such as acc_, wsp_, ast_, doc_, and dec_. IDs identify resources, but they don’t grant access. Dockt checks every requested resource against the authenticated scope.
Store Dockt IDs alongside your own record IDs. The Dockt ID is the value you use for later API calls; your own ID keeps the resource connected to the case or environment in your application.
Use external_id on Workspaces and Assessments when you need that correlation to appear in Dockt responses. Keep personal data out of external IDs because they may appear in logs and operational tools.
Account and workspace credentials
Section titled “Account and workspace credentials”An account credential can manage account resources and Workspaces when its permissions allow those operations. It cannot perform workspace verification operations without workspace scope.
A workspace credential cannot access another Workspace, even if both Workspaces belong to the same Account.
Create separate credentials for separate applications and environments. This gives each integration an independent permission set and lets you rotate or disable one credential without interrupting the others.