Cerby · Authentication Profile
Cerby Authentication
Authentication
Cerby secures its APIs with apiKey and http across 3 declared security schemes, as derived from its OpenAPI definitions.
IdentityAccess ManagementSecurityPassword ManagementProvisioningSCIMIdentity GovernanceNonfederated ApplicationsAutomationWebhooks
Methods: apiKey, http
Schemes: 3
OAuth flows:
API key in: header
Security Schemes
CerbyApiKey apiKey
· in: header ()
CerbyBearerToken http
scheme: bearer
CerbyScimToken apiKey
· in: header ()
Source
Authentication Profile
generated: '2026-08-09'
method: searched
source: https://developer.cerby.com/#authentication
docs: https://help.cerby.com/developer-tools/cerby-api/explore-api-keys-and-bearer-tokens
note: >-
Cerby publishes no OpenAPI document, so this profile is read from the published
developer portal and help-center articles rather than derived from
securitySchemes. Nothing here is inferred.
summary:
types:
- apiKey
- http
api_key_in:
- header
oauth2_flows: []
oauth2: false
openid_connect: false
mutual_tls: false
schemes:
- name: CerbyApiKey
type: apiKey
in: header
parameter_name: X-API-Key
applies_to: Cerby API (https://{my-workspace}.cerby.com/api/v1/)
description: >-
Every request to the Cerby API must carry the X-API-Key header. Keys are
generated and retrieved only from the Cerby web app after authenticating
through the corporate identity provider (Okta, Entra ID, OneLogin) that
fronts the workspace. Keys are scoped — see scopes/cerby-scopes.yml — and
the scopes selected at generation time determine which endpoints and data
the key can reach.
authorization_model: >-
Cerby layers role-based access control on top of the key. A key resolves to
the user who created it, so it can only reach items that user holds the
required workspace and item role on. All-Access Mode, which lets workspace
Owners and Super Admins see every item in the web app, is explicitly NOT
honored by the API — API requests return only items the key's user has the
Owner role on, regardless of the All-Access Mode setting.
failure_modes:
- condition: expired key, or key lacking the scopes for the endpoint
status: 401
- condition: key valid but without permission for the requested operation
status: 403
docs: https://help.cerby.com/developer-tools/cerby-api/generate-an-api-key
source: https://developer.cerby.com/#authentication
- name: CerbyBearerToken
type: http
scheme: bearer
applies_to: Cerby CLI
description: >-
The Cerby CLI authenticates with a bearer token retrieved from the Cerby web
app rather than with an X-API-Key. The CLI additionally requires the machine
to be registered as a trusted device before it can sync and decrypt vault
material locally.
docs: https://help.cerby.com/developer-tools/cerby-api/retrieve-a-bearer-token
source: https://help.cerby.com/developer-tools/cerby-api/explore-api-keys-and-bearer-tokens
- name: CerbyScimToken
type: apiKey
in: header
parameter_name: Authorization
applies_to: Cerby SCIM 2.0 (https://api.cerby.com/v1/scim/v2)
description: >-
SCIM provisioning from an identity provider uses a separate SCIM API
authentication token, generated and regenerable from the Cerby web app. It
is distinct from the Cerby API key and does not carry API-key scopes.
docs: https://help.cerby.com/setup-and-admin/workspace-identity-federation/retrieve-the-scim-api-authentication-token-from-cerby
source: https://help.cerby.com/llms.txt
key_management:
generated_in: Cerby web app (My Profile > Dev Tools)
scopes_selectable_at_creation: true
scopes_updatable: true
viewable: true
revocable: true
expiring: true
docs:
- https://help.cerby.com/developer-tools/cerby-api/generate-an-api-key
- https://help.cerby.com/developer-tools/cerby-api/update-the-scopes-of-an-api-key
- https://help.cerby.com/developer-tools/cerby-api/view-the-details-of-an-api-key
- https://help.cerby.com/developer-tools/cerby-api/delete-an-api-key
guidance_published:
- Do not share API keys in public repositories or client-side code.
- Keys grant access to workspace data and are treated as sensitive resources.
webhook_authentication:
direction: inbound-to-customer
mechanism: request signing, not an API key
see: asyncapi/cerby-webhooks.yml
x-evidence:
- url: https://developer.cerby.com/
http_status: 200
fetched: '2026-08-09'
- url: https://help.cerby.com/developer-tools/cerby-api/explore-api-keys-and-bearer-tokens.md
http_status: 200
fetched: '2026-08-09'
- url: https://help.cerby.com/developer-tools/cerby-api/generate-an-api-key.md
http_status: 200
fetched: '2026-08-09'