Sending the key
Send the key in the Authorization header with the Bearer scheme. If your tool cannot set that header, x-api-key works too. Both are accepted on every endpoint.
curl https://corecited.com/api/v1/brands \
-H "Authorization: Bearer $CORECITED_API_KEY"curl https://corecited.com/api/v1/brands \
-H "x-api-key: $CORECITED_API_KEY"Keys look like vis_ followed by 48 hexadecimal characters. Do not put the key in the URL or query string. The API does not read it from there, and URLs end up in logs.
What a key can see
- A key belongs to one workspace and can read every brand in that workspace. There are no per-brand keys.
- If you belong to several workspaces, create a key in each one. A key never reads across workspaces. Asking for another workspace’s brand returns
404 not_found, exactly as if the brand did not exist. - Keys are read-only. No endpoint changes data.
- All keys in a workspace share one rate limit. See Rate limits.
Creating and revoking keys
Keys are managed in the app under Team → API keys, by workspace Owners and Admins.
| Action | What happens |
|---|---|
| Create | The full key is shown once. We store only a SHA-256 hash and the first 12 characters, so it cannot be shown again, by us or anyone else. |
| Lose a key | It cannot be recovered. Revoke it and create a new one. |
| Revoke | Takes effect on the next request. Keys are checked against the database on every call, with no caching. |
| Last used | Shown next to each key. Updated on every request made with the key, including refused ones. |
| Plan change | The plan is checked on every request. After a downgrade below Agency, existing keys return 402 plan_required. After upgrading again they work with no change. |
Keeping keys safe
- Call the API from a server or a scheduled job. The API sends no CORS headers, so browsers block calls to it from other sites. This is deliberate: a key in a web page is a key anyone can read.
- Keep keys in environment variables or a secrets manager, never in source control. The examples here read
CORECITED_API_KEY. - Create one key per integration, so you can revoke one without breaking the others.
- If a key may have leaked, revoke it immediately. Revocation is instant.
Authentication failures
| Status | Code | Cause |
|---|---|---|
| 401 | missing_key | No key in Authorization or x-api-key. |
| 401 | invalid_key | The key is malformed, unknown or revoked. |
| 402 | plan_required | The workspace's plan does not include API access. |
A
401 or 402 is decided before the rate limiter runs, so it never uses up your per-minute allowance.