Every /v1 operation except the public catalogue requires authentication. The documented method for integrations is the API key, sent in the Authorization header with the Bearer scheme:
Authorization: Bearer veriko_a1b2c3d4e5f6...The key identifies the account and determines both the applicable permissions and the quota consumed. It does not expire: it stays valid until it is regenerated.
Obtaining and rotating
The key is available from the dashboard or through GET /v1/users/me/api-key, and is replaced with POST /v1/users/me/api-key/regenerate. Regeneration invalidates the previous one immediately: any integration still using it starts receiving 401 on its next request.
Reads expose only the last characters of the key. The full value is shown once, at generation time.
Failed authentication responses
| code | situation |
|---|---|
unauthorized | The Authorization header is missing, or the key matches no account |
invalid_api_key | The key has the right format but is not valid |
account_suspended | The account exists but is suspended |
account_deleted | The account has been deleted |
All of them answer 401 in the usual error document shape.
A valid key on an operation the account lacks permission for answers 403 with forbidden, not 401: the difference between the two is identity versus authorisation.
Console-only operations
The web console authenticates on its own, with a method that is not the API key. Dashboard and public API also do not expose the same set of operations. Administration operations accept only the console's method, so a valid API key receives 403 with auth_method_denied when calling them.
Each operation declares the methods it accepts on its reference page. The /v1 operations aimed at integrations accept both.