API keys and authentication

Create keys in the dashboard under API keys. A key is shown in full once, at creation. After that only its first characters are visible, so store it wherever you keep secrets before closing the dialog.

Test keys are prefixed tbx_test_ and live keys tbx_live_. Both bill the same way; the prefix is there so you can tell at a glance which environment a leaked key belongs to.

curl https://api.tubeextract.dev/v1 \
  -H "X-API-Key: tbx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"videos": ["..."], "multiple": true, "schema": [...]}'

A missing or unknown key returns 401. Never put a key in browser code; every call should go through your own backend.

Keys are scoped to the workspace that created them. Reading a job that belongs to another workspace returns 404, not 403, so a wrong key cannot be used to discover which job IDs exist.

Create the replacement first, deploy it, then revoke the old one. Revoking takes effect immediately and cannot be undone. Jobs already queued under a revoked key still finish; you can still read their results with any live key in the same workspace.

An AI agent can get a key without anyone copying one. It registers with the email address of the person it works for and shows them a six-digit code; the person opens a link, signs in as that address, and types the code. The agent then collects a new key for their workspace. No account is created for them, and nothing is sent by email. The key appears under API keys labelled as an agent’s, and you can revoke it there like any other.

The steps, endpoints and error codes are written for agents to read at /auth.md, with the discovery documents at /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. The same key works for the /mcp MCP server and the /a2a endpoint.