Authentication

Every v1 request is authenticated with a workspace API key. There are no user tokens and no OAuth: a key is scoped to one workspace and acts only on that workspace's data.

Issue a key

In the dashboard, open Settings → API keys and create one (workspace owner or admin only). Give it a name to track where it is used, and pick its scopes — the subset of the API it may call.

Keys look like this:

blm_<random token>

A key's scopes are fixed at creation and immutable — to change scopes, revoke the key and issue a new one with the right set. See Scopes for the registry.

Issuing a key is recorded in your audit log, with the public prefix only — never the key itself.

Send it

Two headers are accepted; use either.

curl https://app.evoriqa.com/api/v1/chatbots \
  -H "Authorization: Bearer $EVORIQA_API_KEY"

# or
curl https://app.evoriqa.com/api/v1/chatbots \
  -H "x-api-key: $EVORIQA_API_KEY"

const res = await fetch("https://app.evoriqa.com/api/v1/chatbots", {
  headers: { Authorization: `Bearer ${process.env.EVORIQA_API_KEY}` },
});
const { data } = await res.json();
console.log(data.data);

import os, requests

res = requests.get(
    "https://app.evoriqa.com/api/v1/chatbots",
    headers={"Authorization": f"Bearer {os.environ['EVORIQA_API_KEY']}"},
    timeout=30,
)
print(res.json()["data"]["data"])

The 401s

A request with no key at all:

{
  "success": false,
  "error": { "code": "UNAUTHORIZED", "message": "Missing API key." }
}

A key that does not exist, is malformed, or has been revoked is also 401, with "Invalid API key.". A key you have disabled is 401 with "API key is disabled." — a distinct message, because it is your own reversible state, not a platform action.

API access has to be enabled for your workspace

A valid key is not enough: the API is off until it is enabled for your workspace. Until then every request — and every attempt to issue a key — returns:

{
  "success": false,
  "error": {
    "code": "FORBIDDEN",
    "message": "API access is not enabled for this workspace."
  }
}

This is the most common reason a first call fails, and retrying will not change it. What to do depends on who you buy from:

• Direct customers — check that your plan includes API access, then contact Evoriqa support to have it enabled.
• Clients of an agency or reseller — your provider controls it. Ask them; see Per-client API access.

The message is deliberately the same whatever the underlying reason, so treat it as one condition: "not enabled yet".

Enabling takes effect immediately on keys that already exist — access is checked live on every request, so you do not need to reissue anything once it is switched on.

Key lifecycle: disable, revoke, rotate

Settings → API keys manages the whole lifecycle:

• Disable — a reversible pause. The key rejects requests with API key is disabled. until you re-enable it. Use it to stop an integration without destroying its key.
• Revoke — permanent. Revocation is immediate; the next request with that key is 401 Invalid API key., forever. Revoking an unknown or already-revoked key returns 404 rather than reporting a false success.
• Rotate — issue the new key, deploy it, then revoke the old one. There is no in-place rotation, because scopes and the secret are fixed at creation.

The same page shows each key's request log — every v1 call made with it, including the ones that fail auth or hit a limit (401, 403, 429). Each row records the method, path, status, latency, and a SHA-256 hash of the caller IP (never the raw address). Rows are kept for up to 90 days — and sooner if your workspace's data-retention window is shorter. Use it to confirm what an integration actually did before revoking its key.

Where to go next

• Scopes
• Response envelope
• Errors