Authentication - Client ID & API Key
Learn how to authenticate with the Deepvue Workflows API using your client ID and API key headers. Includes code examples and failure handling.
{
"error": "missing credentials: send client-id + x-api-key headers"
}
{
"error": "invalid Deepvue credentials"
}
{
"error": "account_disabled"
}
{
"error": "Deepvue account not authorized for this surface"
}
{
"error": "deepvue authorize failed: …"
}
{
"error": "auto-provisioning disabled - log in once via /auth/login first"
}
Overview
Every request to the Workflows API carries two credentials, sent as headers. There is no token exchange step: the pair authenticates each call directly.
Your Deepvue client identifier.
Your Deepvue API key.
x-api-key is a secret.
Keep it server-side.
It must never be exposed in a browser or a mobile client.
Getting your credentials
Log in to the Dashboard
Visit the Deepvue Dashboard and sign in to your account.
Open the credentials tab
Find your client ID and API key.
Send both on every request
Store them as server-side environment variables and attach them to each call.
Making an authenticated request
curl 'https://api.deepvue.link/v1/workflows' \
-H 'client-id: YOUR_CLIENT_ID' \
-H 'x-api-key: YOUR_API_KEY'
import os
import requests
BASE = "https://api.deepvue.link"
HEADERS = {
"client-id": os.environ["DEEPVUE_CLIENT_ID"],
"x-api-key": os.environ["DEEPVUE_API_KEY"],
}
response = requests.get(f"{BASE}/v1/workflows", headers=HEADERS, timeout=30)
response.raise_for_status()
print(response.json())
const BASE = "https://api.deepvue.link";
const headers = {
"client-id": process.env.DEEPVUE_CLIENT_ID,
"x-api-key": process.env.DEEPVUE_API_KEY,
};
const response = await fetch(`${BASE}/v1/workflows`, { headers });
if (!response.ok) throw new Error(`${response.status} ${await response.text()}`);
console.log(await response.json());
Authentication failures
| Status Code | Meaning | Description |
|---|---|---|
401 | Missing credentials | No usable credential was supplied |
401 | Invalid credentials | The credential pair was rejected |
403 | Account disabled | The account exists but is not yet approved |
403 | Not authorized | The account is not authorized for this API |
502 | Authorize failed | Authorization service temporarily unreachable, retry |
503 | Auto-provisioning disabled | First-time setup not yet completed |
Retry 502 responses with backoff.
Treat 401 and 403 as configuration problems rather than transient faults, and do not retry them in a loop.
Bearer tokens
One route also accepts a dashboard Bearer token instead of the header pair: POST /v1/signals/{run_id}/{signal_name}, used to record a review verdict.
Every other route requires client-id and x-api-key.