Autenticación y API keys

La External API pública se autentica con una API key, emitida
por el hotel desde su cuenta de Axis Pro.

Una key se ve como axis_live_ seguido de 64 caracteres hexadecimales — 74 en
total. Solo se guarda su hash, más los últimos cuatro caracteres para mostrarlos,
así que una key perdida no se puede recuperar y hay que volver a emitirla.

Mandar la key

Se aceptan dos transportes, y son equivalentes:

X-API-Key: axis_live_…

Authorization: Bearer axis_live_…

Una key en la query string no se acepta nunca. Terminaría en logs de acceso,
historial del navegador y headers de referrer.

La key es la cuenta

Uno nunca nombra una cuenta. La key la resuelve, y toda llamada queda acotada a
esa cuenta durante toda su vida.

La key carga tres cosas que le dan forma a cada llamada:

Toda falla de credencial se responde igual

Una key desconocida, una expirada, una revocada y una desactivada devuelven todas
el mismo 401:

{ "message": "Invalid, expired or revoked API key.", "error_code": "APIKEY_INVALID" }

Esto es deliberado. Distinguirlas le diría a un atacante qué intentos están
cerca.

Una key ausente sí tiene su propio código, porque eso es un error de cableado y
no un intento a ciegas:

{ "message": "API key required. Provide the X-API-Key header.", "error_code": "APIKEY_MISSING" }

Y hay una falla de credencial que sí tiene código propio — una cuenta
desactivada:

{ "message": "…", "error_code": "TENANT_INACTIVE" }

Responde 403 y no 401 porque es un estado de cuenta que el propio merchant de
quien integra puede arreglar, así que distinguirlo es útil y no una filtración.

Revisar la key antes de cablear nada

GET /health devuelve 200 para cualquier key válida y
no necesita alcance alguno. Es la forma más barata de confirmar que la credencial
funciona y que llega al ambiente que uno cree.

curl https://api.sandbox.axispro.travel/api/external/v1/health \
  -H "X-API-Key: axis_live_…"

Ambientes

Hay dos, y la API Reference deja cambiar entre ellos:

Una key pertenece a exactamente un ambiente. A una key de sandbox producción
la rechaza, y a una de producción la rechaza el sandbox — las dos respondiendo el
mismo 401 APIKEY_INVALID, porque esa respuesta deliberadamente no se explica.

Así que una key que "dejó de funcionar" es muy seguido una key apuntada al host
equivocado. Conviene revisar la URL base antes de dar por mala la credencial.

Producción no es un ensayo. Una reserva creada ahí ocupa una habitación
real y aparece en una recepción real. Hay que construir contra el sandbox y
cambiar al terminar.

Relacionado

• Alcances y el header X-Property — qué tiene permitido hacer una key, y dónde.
• Errores — la forma completa de una falla.
• Límites de uso — qué tiene permitido hacer una key por minuto.