Generating a key
Go to Settings → API Keys in your Knouds account (or the Developer Dashboard) and create a new key. The full key value is shown exactly once at creation time — copy it immediately. If you lose it, you must revoke the key and generate a new one. When you create a key, you pick a preset (or Custom for granular grants):| Preset | Capabilities granted |
|---|---|
| Read-only | workflow:read |
| Workflow Deploy | workflow:run, workflow:read |
| Webhook receiver | webhook:receive |
| Full deploy | workflow:run, workflow:read, workflow:write |
| Custom | Any subset capped by your tier ceiling (see below) |
Passing your key
Include the key in thex-api-key header on every request:
Capability vocabulary
| Capability | Reaches | Tier minimum to grant |
|---|---|---|
workflow:run | POST /api/workflows/:slug/run (any flow you own) | Pro |
workflow:read | GET /api/workflows, :slug, :slug/schema | Pro |
workflow:write | POST/PUT/DELETE /api/workflows (ownership-checked) | Pro |
workflow:<slug>:run | POST /api/workflows/<slug>/run (specific flow only — useful for least-privilege CI keys) | Pro |
model:run | POST /api/models/:internalName/run (any registry model) | Business |
model:<internalName>:run | POST /api/models/<internalName>/run (specific model only) | Business |
webhook:receive | Receive outbound webhook deliveries (the ?async=true flow). Per-key URL + signing-secret config is session-only at /api/api-keys/:id/webhook. | Pro |
execution:read | GET /api/executions/:id — poll your own async executions | every tier |
execution:cancel | POST /api/executions/:id/cancel — cancel your own in-flight executions | every tier |
agent:invoke | Reserved for SSE / streaming (not yet shipped) | Business |
model:run does NOT automatically get workflow:write. Grant exactly what your integration needs.
Match logic
requireCapability(cap) resolves with a 4-step check:
- Key has
*(admin override) → pass - Key has
capexactly → pass - Key has
<resource>:*matchingcap(resource-level wildcard) → pass - Required cap is
<resource>:<id>:<action>AND key has<resource>:<action>(general implies specific) OR<resource>:*:<action>(pattern admission) → pass
403 CAPABILITY_DENIED.
A key with workflow:run passes POST /api/workflows/anything/run (general implies specific). A key with workflow:my-flow:run only passes that specific slug.
Tier ceiling
A user can only grant capabilities up to their tier’s ceiling. The server rejects above-ceiling grants with403 CAPABILITY_ABOVE_CEILING.
| Tier | Can grant on API keys |
|---|---|
| Free | (nothing — no external API access) |
| Pro | workflow:run, workflow:read, workflow:write, workflow:<slug>:run, webhook:receive |
| Business | + model:run, model:<internalName>:run, agent:invoke |
| Enterprise | (same as Business) |
Error responses
Missing or invalid key — 401
x-api-key header is present and that the key has not been deleted from the dashboard.
Pre-Phase-11 key retired — 401
Capability denied — 403 CAPABILITY_DENIED
If your key’s capability set does not cover the endpoint, you receive a403:
required field to know which capability would have passed. Either regenerate your key with broader capabilities (capped by your tier) or upgrade your tier.