Toda operación de /v1 salvo el catálogo público exige autenticación. El método documentado para integraciones es la API key, enviada en la cabecera Authorization con el esquema Bearer:
Authorization: Bearer veriko_a1b2c3d4e5f6...La clave identifica a la cuenta y determina tanto los permisos aplicables como la cuota consumida. No lleva caducidad: permanece válida hasta que se regenera.
Obtención y rotación
La clave se consulta desde el panel o con GET /v1/users/me/api-key, y se sustituye con POST /v1/users/me/api-key/regenerate. La regeneración invalida la anterior de forma inmediata: cualquier integración que siga usándola empieza a recibir 401 en la petición siguiente.
Las lecturas exponen únicamente los últimos caracteres de la clave. El valor completo se muestra una sola vez, en el momento de generarla.
Respuestas de autenticación fallida
| código | situación |
|---|---|
unauthorized | Falta la cabecera Authorization o la clave no corresponde a ninguna cuenta |
invalid_api_key | La clave tiene el formato correcto pero no es válida |
account_suspended | La cuenta existe pero está suspendida |
account_deleted | La cuenta fue eliminada |
Todas responden 401 con la forma habitual del documento de error.
Una clave válida sobre una operación para la que la cuenta no tiene permiso responde 403 con forbidden, no 401: la diferencia entre ambos es identidad frente a autorización.
Operaciones exclusivas de la consola
La consola web se autentica por su cuenta, con un método propio que no es la API key. Panel y API pública además no exponen el mismo conjunto de operaciones. Las operaciones de administración solo aceptan el método de la consola, de modo que una API key válida recibe 403 con auth_method_denied al invocarlas.
Cada operación declara los métodos que admite en su página de referencia. Las de /v1 orientadas a integración aceptan ambos.