Empezar · 01
Autenticación y llaves
Cada petición se autentica con la llave de socio en el encabezado Authorization, esquema Bearer. La llave identifica a tu cuenta (tenant): no existe ningún parámetro de tenant en las rutas, y cada llave solo ve sus propias verificaciones.
Authorization: Bearer <tu llave de socio>Buenas prácticas con la llave
- Guárdala en un gestor de secretos o en variables de ambiente del servidor. Nunca en el código, en el navegador ni en una app móvil.
- Llama a la API solo desde tu backend. La llave no debe viajar al dispositivo del solicitante.
- No la registres en bitácoras. Si tu proxy registra encabezados, enmascara
Authorization. - Si sospechas que se filtró, pide la rotación a Revísame de inmediato; la llave anterior deja de funcionar.
- Usa llaves distintas para pruebas y producción. Cada respuesta indica el entorno en
environment(sandboxoproduction).
Errores de autenticación
| HTTP | Código | Causa |
|---|---|---|
| 401 | llave_ausente | No llegó Authorization: Bearer …. |
| 401 | llave_invalida | La llave no corresponde a ningún socio activo. |
| 404 | verificacion_no_encontrada | El identificador no existe en el alcance de tu llave. La API nunca responde 403 para no confirmar que existe en otra cuenta. |
Rutas públicas
Solo GET /_salud responde sin llave.
Canal MCP
El canal MCP usa la misma llave, en el mismo encabezado. El servidor MCP la reenvía a la API en cada llamada y no la guarda ni la registra.