Authentication

Authenticate with Bearer API keys (dcs_live_ and dcs_test_) — create, store, rotate and revoke them — and know where they work.

Every call to the public API needs an API key in the Authorization header:

Authorization: Bearer dcs_live_9fK2mQ7xLp4Rt8Vw1Zc6Nb3Hy5Js0Ad2

A key is dcs_live_ or dcs_test_ followed by 32 letters and digits. A missing header, another scheme than Bearer, a malformed, unknown or revoked key all fail with:

401 Unauthorized
{
  "error": {
    "code": "INVALID_API_KEY",
    "message": "Missing, invalid or revoked API key.",
    "request_id": "req_Qm8vT2kLx9Pw4Rz7Nc1B"
  }
}

Create a key

  1. In the app, open API Keys and click New key.
  2. Give it a name (for example the service that will use it) and choose the environment: Live (dcs_live_…) or Test (dcs_test_…).
  3. Click Create key and copy it. The full key is shown only once.

Store it in your secrets manager or as an environment variable such as DCISION_API_KEY. Dcision keeps only a SHA-256 hash of the key, so a lost key can't be recovered — create a new one.

The key list shows each key's name, a masked form (dcs_live_9fK2…0Ad2), its environment, when it was created and when it was last used (updated at most once a minute). Members, Admins and the Owner can create, rename and revoke keys; Viewers only see the list — see Team, roles and account. A workspace can have up to 50 active keys.

Live and test keys

Both environments behave the same: they call the same deployed versions, share the workspace's rate limit and are billed the same way. The difference is organizational — keep test keys for staging, CI and local development so you can revoke them without touching production — plus one flag: destination deliveries of calls made with a test key carry livemode: false, so receivers can keep them out of production.

Scope

  • A key belongs to one workspace and can call every decision of that workspace, and read its decisions, account and executions with GET /v1/decisions, GET /v1/me and GET /v1/executions. The same key authenticates the MCP server.
  • A key from another workspace can't reach your decisions: it gets 404 DECISION_NOT_FOUND, and its /v1/executions only lists its own workspace's runs.
  • Keys only work on the public API (/v1/…). The app's endpoints refuse them with 403 FORBIDDEN — "API keys can only call the /v1 decision endpoints."

Verify a key

GET /v1/me answers 200 with the key's workspace, name, environment and plan, or 401 INVALID_API_KEY. It's a cheap check for CI and deploy scripts — it doesn't run a decision and isn't billed:

curl -sf https://api.dcision.io/v1/me -H "Authorization: Bearer $DCISION_API_KEY" > /dev/null \
  && echo "key OK" || echo "key rejected"

Rotate a key

  1. Create a new key.
  2. Deploy your application with the new key.
  3. Revoke the old key once its Last used stops moving.

Revoke a key

Revoke takes effect immediately and can't be undone: every request with the key fails with 401 INVALID_API_KEY. Revoked keys stay in the list, greyed out, for reference.

Keep keys safe

  • Call the API from your server, never from a browser, a mobile app or a client bundle.
  • Never commit keys to a repository; load them from the environment.
  • Use one key per service so you can revoke one without affecting the others.

On this page