Authentication

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 or until every session of the account is closed (password change or reset, "sign out everywhere", or a forced sign-out); from then on it answers 401 with session_invalidated and must be regenerated.

Obtaining and rotating

The key is read and replaced from the dashboard (GET /v1/users/me/api-key and POST /v1/users/me/api-key/regenerate only accept the console session, not the API key). Regeneration invalidates the previous one immediately: any integration still using it starts receiving 401 on its next request.

Reads expose only the prefix and the last characters of the key. The full value is shown at generation time, and the console can show it again afterwards by requiring the account password.

Failed authentication responses

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 permission_denied, 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.