API Keys
Create and manage API keys for authenticating with the Weavz API.
API keys are the primary way to authenticate with the Weavz API from your backend services. Each key is scoped to an organization and provides full access to that organization's resources.
Key Format
All Weavz API keys use the wvz_ prefix followed by a random string:
wvz_abc123def456...This prefix makes it easy to identify Weavz keys in your codebase and allows secret scanners to detect leaked credentials.
Creating API Keys
Open Settings
Navigate to Settings → API Keys in the Weavz dashboard.
Create a new key
Click Create API Key and enter a descriptive name (e.g., production-backend, staging-server).
Set expiration (optional)
Optionally set an expiration date for automatic key rotation.
Copy the key
Click Create and copy the key immediately — it will only be shown once.
Using API Keys
Include your API key in the Authorization header of every request:
curl https://api.weavz.io/api/v1/workspaces \
-H "Authorization: Bearer wvz_your_key"Listing Keys
curl https://api.weavz.io/api/v1/api-keys \
-H "Authorization: Bearer wvz_your_key"Deleting Keys
curl -X DELETE https://api.weavz.io/api/v1/api-keys/key_abc123 \
-H "Authorization: Bearer wvz_your_key"Key Rotation
To rotate an API key without downtime:
Create a new key
Generate a new API key via the dashboard or API.
Update your application
Deploy the new key to your environment variables.
Verify the new key
Confirm the new key works in production.
Delete the old key
Revoke the old key once the new one is verified.
// 1. Create new key
const { plainKey: newKey } = await client.apiKeys.create({
name: 'production-backend-v2',
})
// 2. Update your environment variables with the new key
// 3. Verify the new key works
// 4. Delete the old key
await client.apiKeys.delete('old_key_id')Scoping Keys to Workspaces
By default, API keys have org-wide access. For tighter security, you can scope a key to specific workspaces — the key will only be able to access resources (connections, MCP servers, triggers, actions) within those workspaces.
curl -X POST https://api.weavz.io/api/v1/api-keys \
-H "Authorization: Bearer wvz_your_existing_key" \
-H "Content-Type: application/json" \
-d '{
"name": "checkout-service",
"permissions": {
"scope": "workspace",
"workspaceIds": ["WORKSPACE_UUID_1"]
}
}'If a workspace-scoped key tries to access a resource outside its allowed workspaces, the API returns 403 with code SCOPE_DENIED. API key management requires an org-wide key.
When sending connectionExternalId/externalId for action execution or connection resolution, include the correct workspaceId (and endUserId when applicable). Explicit connection IDs are still validated against that context and are rejected on scope mismatch.
Human Gates Decisions
Human Gates decisions require an API key with approvals.decide. Enable it on the same backend key when your product should both create and resolve gated work, or keep it on a separate backend API key when you want operational separation.
const { plainKey } = await client.apiKeys.create({
name: 'approval-reviewer',
permissions: {
scope: 'workspace',
workspaceIds: ['WORKSPACE_UUID_1'],
approvals: { decide: true },
},
})The permission is still scoped. Workspace keys can only decide Human Gates requests in their allowed workspaces, while organization keys can decide organization-wide requests.
Best Practices
- Use workspace-scoped keys for least-privilege access — each service should only access the workspaces it needs
- Use environment variables — never hardcode API keys in source code
- Separate keys per environment — use different keys for development, staging, and production
- Set expiration dates — rotate keys periodically for better security
- Never expose keys in client-side code — API keys should only be used in server-side applications
- Monitor usage — check the Activity page to track API key usage
- Revoke compromised keys immediately — if a key is leaked, delete it and create a new one