Autenticación

El token de tenant

Todo request lleva tu token en el header Authorization:

curl https://api.tikin.is/v1/accounts/lookup?alias=%24bottico \
  -H "Authorization: Bearer tk_live_51Hx…"

Los tokens de producción llevan el prefijo tk_live_… y mueven dinero real. El entorno sandbox llega pronto: los tokens tk_test_ quedarán reservados para él, y un token de prueba jamás tocará producción — mandar un tk_test_ a api.tikin.is será 401, no un modo degradado. Esto es a propósito: el error más caro de una integración de pagos es confundir entornos, y aquí será imposible confundirse en silencio.

Scopes

Los tokens tienen scopes, y la regla es usar el mínimo que tu integración necesita:

Un servicio que solo pinta saldos no necesita poder sacar dinero. Si te roban un token read, perdiste privacidad; si te roban uno payouts, perdiste dinero.

Ver qué puede tu token antes de intentarlo

GET /v1/tenant lista los scopes de la credencial con la que preguntas:

{ "code": "acme", "name": "Acme S.A.S.", "scopes": ["read", "transfers"], "api_version": { "effective": "2026-09-08", "requested": null, "latest": "2026-09-08" } }

Una ruta fuera de scope responde 403 insufficient_scope, y el message dice cuál faltó y cuáles tiene el token. GET /v1/tenant nunca exige scope: saber qué se puede hacer es justamente lo que se consulta antes de hacerlo.

Los scopes se eligen al acuñar la credencial (desde el backoffice de Tikin, y pronto desde tu portal); una credencial no cambia de scopes: se acuña otra y se revoca la vieja.

Si algo falla

Token ausente, inválido o revocado → 401 con error.code que lo dice. Un 403 es de dos clases: insufficient_scope (al token le falta el scope de esa ruta) o authority_insufficient (el rol del miembro en esa cuenta no puede hacer eso). Errores →