API access for your clients

Whether a client can use the v1 API is your control, set per client. A resold client's API is off by default — it stays off until you enable it. (A platform admin can still override it from the Organizations page, but the normal control is yours.)

The switch

On a client's limit overrides (the same editor as its chatbot, seat, and source caps), the API access control has three states:

Over the reseller API, the same control is the apiAccess field on the client-limits endpoint — true / false / null for On / Off / Default:

curl -X POST "https://app.evoriqa.com/api/v1/reseller/clients/$CLIENT_WORKSPACE_ID/limits" \
  -H "x-api-key: $EVORIQA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "apiAccess": true }'

apiAccess is nullable to inherit (null clears to the default) and optional to leave unchanged. The change is audited on the client. The endpoint needs the reseller:write scope, and the key must live on your organisation owner's own primary workspace.

What the client sees when it is off

Both key issuance and every /api/v1 call return 403. In the API:

API access is not enabled for this workspace.

In their dashboard, the API keys screen shows "API access is not enabled" and names the reason — that their provider has not turned it on. That wording sends them to you.

The switch is live

Access is resolved on every request, so a change takes effect immediately — including on keys already issued. Turning access off stops existing keys on the very next call; turning it back on restores them with nothing to reissue.

A client's rate limit

Once enabled, the client's own per-minute rate limit follows its own client plan's tier (Free 10 · Starter 30 · Pro 60 · Business 300 requests per minute).

Where to go next

• API authentication
• Client workspaces