Una vez tienes la clave, autentica cada petición añadiendo la cabecera `X-API-Key` con el valor completo de la clave. No hace falta ningún otro dato de sesión — ni cookie, ni token Bearer. Ejemplo real, listando tus propias claves: ``` curl -X GET "https://TU_DOMINIO/api/v1/auth/api-keys" \ -H "X-API-Key: aa_TU_CLAVE_COMPLETA_AQUI" ``` Respuesta (200, ejemplo real acortado): ``` [ { "id": "985d256e-9809-...", "name": "Mi integración", "prefix": "aa_1b2e1ebd", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T05:36:27Z", "is_active": true, "owner_type": "user", "allowed_origins": [], "created_by": "admin@tu-negocio.com" } ] ``` Una **clave de empresa** (apartado 5) autentica exactamente igual, sin sesión ni credenciales de persona — la cuenta de servicio del tenant responde con sus propias claves (ejemplo real): ``` curl -X GET "https://TU_DOMINIO/api/v1/auth/api-keys" \ -H "X-API-Key: aa_9fe72924…" ``` Respuesta (200, ejemplo real acortado — nótese `"owner_type": "tenant"`): ``` [ { "id": "8a0b0f78-7b25-...", "name": "AK-18 fix round 1 demo", "prefix": "aa_9fe72924", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T06:28:37Z", "is_active": true, "owner_type": "tenant", "allowed_origins": [], "created_by": "admin@tu-negocio.com" } ] ``` > **Nota — Qué NO permite una clave de API** > > Autentica llamadas a la API REST con los permisos de su rol sellado (apartado 7) — nada más. En concreto: no sirve para iniciar sesión en la interfaz web de la Plataforma (esa sigue siendo email + contraseña, o Google), no es lo mismo que el «Acceso por canal» de WhatsApp/Telegram (Manual 51, un mecanismo distinto basado en verificación en dos pasos), y no da acceso a ver la propia clave de otra persona ni a las claves de otro tenant.