Skip to main content
Every request carries a Bearer credential in the Authorization header. The API accepts two kinds, on the same endpoints:
The server detects which one you sent. The only difference is billing: API-key calls draw a platform fee; JWT calls don’t (see Billing).
If you’re building an integration, use an API key. The session JWT is what clipping.cc itself uses after you log in. These guides assume an API key.

​
API keys

Create and revoke keys from the dashboard at clipping.cc/account:
  • Create — the full secret (ck_live_…) is shown once. The server keeps only a hash; there’s no way to recover it later. Lose it → revoke and recreate.
  • Revoke — immediate. Requests with a revoked key start returning 401.
  • Multiple keys — one per environment/integration, with descriptive names.
A key carries your account’s access and draws from your balance. Treat it like a password: never ship it in frontend code or commit it to a repository.

​
Session tokens (JWT)

For completeness — used by the app, not usually by integrations:
  • POST /v1/auth/signup / POST /v1/auth/login → returns a token (JWT).
  • Send it as Authorization: Bearer <jwt>.
  • POST /v1/auth/logout-all revokes every token; POST /v1/auth/api-keys (JWT-authenticated) is how the dashboard mints API keys.
  • The realtime WebSocket (/v1/realtime) accepts only a JWT (passed as a query param) — API keys can’t open it. Integrators poll executions instead (see Asynchronous operations).

​
Errors

All errors share the same shape:

​
Access scope

A credential inherits your account’s reach: you read and write your own items, collections and reporters, plus whatever is public via discover. There are no per-permission scopes yet — a key can do what you can do.