Skip to main content
Pre-release — contact your Fortary account team for access.
Authentication proves which credential is making a request. Authorization decides what that credential is allowed to see. This page explains how the API makes that decision and what the resulting status codes mean.

​
Access is an intersection

Every request is authorized against three things at once, and the result is their intersection:
  1. The key’s scopes — what kinds of operation the key may perform (for v1, read access via vault:read). See Scopes.
  2. The owner’s live roles — the roles the key’s owning user currently holds on your vaults. For v1 reads this is the Developer role.
  3. The key’s vault allowlist — the specific vaults the key was created to access.
A request succeeds only where all three agree. A key can never see more than its owner is currently allowed to see: if the owner’s roles shrink, the key’s access shrinks with them. Scopes and the vault allowlist can only narrow access further, never widen it beyond the owner’s authority.

​
What the status codes mean

These distinctions matter when you handle responses:
StatusMeaning
401The credential is missing, malformed, expired, or revoked. Re-check the Authorization header and the key’s validity.
403The credential is valid but lacks the required scope or access for this operation. This is a capability failure, not a statement about any particular resource.
404The resource doesn’t exist or isn’t visible to this credential. A vault outside the key’s allowlist — or one the owner can no longer see — returns 404, never 403.
The API deliberately returns 404 rather than 403 for a vault the credential can’t access, so that responses never reveal whether a vault you can’t see exists. A 404 means “nothing here for you,” not necessarily “nothing here.”
See Errors for the full response shape these codes carry.