Scopes

When you create an API key you can attach permission scopes. Each API operation declares its API-key policy, and centralized authorization enforces that policy after the route is matched.

Full access

An empty permissions list grants full access to every workspace API route the key can call. Prefer this for internal automation; use narrower scopes for least privilege.

Available scopes

Scope	Allows
certificates:read	GET on certificate, issue, recipient, correction, and request-form paths
certificates:write	Non-GET methods on those same paths
templates:read	GET on certificate-template and email-template paths
templates:write	Non-GET methods on certificate-template and email-template paths

Policies are operation-based:

• Template and email-template operations declare templates:read or templates:write.
• Certificate, issue, recipient, correction, and request-form operations declare certificates:read or certificates:write.
• Administrative operations such as API-key management explicitly require a full-access key.
• Authenticated operations without an API-key policy reject API-key callers by default.

Missing permission returns 403 with code missing_permission.

Examples

Call	Scope needed
GET .../certificates	certificates:read (or full access)
POST .../certificates/{id}/issues	certificates:write (or full access)
POST .../certificates/{id}/send	certificates:write (or full access)
GET .../requests	certificates:read (or full access)
POST .../requests/{id}/approve	certificates:write (or full access)
GET .../corrections	certificates:read (or full access)
POST .../corrections/{id}/approve	certificates:write (or full access)
GET .../recipients	certificates:read (or full access)
Template draft / publish / fork	templates:read / templates:write (not in this v1 reference)