Skip to main content
Pre-release — contact your Fortary account team for access.
The API authenticates each request with an API key sent as a bearer token. This guide covers creating a key, sending it, managing its expiry and IP allowlist, and revoking or rotating it. For how access is decided once a request is authenticated, see Authorization and Scopes.

​
Create a key

API keys are created from the Fortary portal by a signed-in user who holds the Developer role on the relevant vaults. Creating a key requires re-confirming multi-factor authentication. When you create a key you choose:
  • Scopes — what the key can do. For v1 the only scope is vault:read. See Scopes.
  • Vault allowlist — which of your vaults the key can see.
  • IP allowlist — optional; see below.
  • Expiry — optional; defaults to 365 days. See below.
  • Label — a name to recognize the key later.
The secret is shown once, at creation, and looks like: 
fkc_...
Copy the secret when it is shown and store it somewhere secure — Fortary keeps only a hash of it and cannot show it again. If you lose it, create a new key and revoke the old one.

​
Send the token

Send the key as a bearer token in the Authorization header on every request: 
curl https://customer-api.fortary.io/v1/vaults \
  -H "Authorization: Bearer fkc_..."
There is no X-API-Key header and no separate API-secret field — the credential is always the bearer token.

​
Key expiry

A new key is given a 365-day expiry by default. You can extend it, shorten it, or clear it to no expiry when you create the key or later. A request made with an expired key is rejected with 401.
A finite expiry limits the damage if a key is ever leaked. Keep the default unless you have a specific reason to change it, and rotate long-lived keys periodically.

​
Restrict a key to your IP ranges

A key can carry an optional IP allowlist — a list of CIDR ranges (your servers’ egress addresses). When set, requests from any other address are rejected, even with a valid key. When left empty there is no IP restriction. The allowlist is enforced on every request, so a leaked secret is useless from outside your network.

​
Revoke and rotate

  • Revoke — revoking a key takes effect immediately across the API; the key stops working at once.
  • Rotate the secret — secrets can’t be changed in place. To rotate, create a new key and revoke the old one once your integration is using the new secret.
  • Edit a key — its scopes, vault allowlist, and IP allowlist can be edited in place (for example, to remove a vault from a key’s reach). The secret itself is never editable.

​
Operational behavior to plan for

A key is bound to the user who created it and inherits that user’s live roles:
  • If the owner loses the Developer role, the key’s access is withdrawn — but not instantly. Role changes may take up to 5 minutes to fully propagate. For immediate access changes, revoke the API key directly.
  • If the owning user is deactivated, their keys are revoked automatically.
For an unattended integration, have a long-tenure user own the key so it isn’t broken by routine staff changes.