Skip to main content
La API acepta dos esquemas de credenciales. La semántica es OR: basta con satisfacer uno de los dos. La excepción es administrar API tokens, que exige sesión de usuario — ver la aclaración debajo de la tabla.

​
API token (recomendado para integraciones)

Un token de larga duración con prefijo atk_, en el header Authorization:
Es el esquema para scripts, backends e integraciones: no expira con la sesión del usuario y no depende de un navegador. Se administran con: Las tres requieren el permiso access_api_keys.
Administrar API tokens exige una sesión de usuario: estos tres endpoints rechazan un bearer atk_ con 403 y código SESSION_REQUIRED. Es deliberado — un API token no puede crear ni revocar otros tokens. Para emitir o revocar el tuyo, iniciá sesión en la plataforma.

​
Sesión

El mismo header Authorization: Bearer <token> acepta un token de sesión, y la API también acepta la cookie de sesión (better-auth.session_token, con prefijo __Secure- en producción) que emite el login del frontend web. Es el mecanismo de la aplicación web, donde la cookie viaja automáticamente.
Los JWT legacy (eyJ...) ya no son válidos. Si tu integración los usaba, migrá a un API token atk_.

​
Endpoints públicos

Estas son las únicas operaciones que no requieren credenciales: Todo el resto requiere credencial. En la referencia de la API cada operación indica su esquema de autenticación.

​
Qué pasa si la credencial falla

El 503 es deliberado: significa “reintentá”, no “tu credencial es inválida”. No cierres la sesión ni pidas credenciales nuevas cuando lo recibas.
Todas las respuestas de error siguen el mismo contrato, con un campo code estable para hacer branching.