Solucionar el error "API Key Not Found in Cookies

TL;DR

• API key not found in cookies casi nunca significa que tu clave esté mal. Significa que la app del navegador que almacenó tu clave en una cookie no puede volver a leer esa cookie.
• El culpable habitual: las cookies de terceros están bloqueadas. Safari, Brave, Firefox y todas las ventanas de incógnito las bloquean por defecto, así que la cookie que contiene tu clave silenciosamente nunca persiste.
• Solución rápida: permite cookies para el dominio exacto de la app, cierra sesión y vuelve a iniciarla, luego vuelve a pegar tu clave. ¿Otro navegador o incógnito? Por eso “desapareció”.
• Solución permanente (para desarrolladores): deja de confiar en el tarro de cookies. Envía tu clave en un encabezado Authorization: Bearer a un endpoint estable. Sin cookie, no hay problema de cookies.

Si llegaste aquí porque una guía te dijo que este es un error de “Cursor” o “Windsurf”, no lo es. Este mensaje proviene de apps de navegador que mantienen tu clave API del lado del cliente, y la solución no tiene nada que ver con tu IDE.

¿Qué significa realmente “API key not found in cookies”?

Significa que la app esperaba encontrar tu clave API dentro de una cookie del navegador, revisó y la cookie no estaba allí. Tu clave probablemente está bien. Lo que se rompió es el almacenamiento que la contenía.

Este es el mecanismo. Algunas apps web — frontends de chat con IA, paneles de reverse-proxy, algunas consolas SaaS — no quieren tu clave en su servidor. Así que cuando la pegas, la guardan en una [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) (o una sesión respaldada por cookies) en tu propio navegador. Luego, cada solicitud vuelve a leer la clave desde esa cookie. Cuando la cookie falta, está bloqueada, expiró o está limitada a un dominio en el que no estás actualmente, la lectura no devuelve nada. Obtienes API key not found in cookies.

Así que este es un error de estado de autenticación del lado del cliente, no un error de “credenciales inválidas”. Nadie rechazó tu clave. La app simplemente no pudo encontrarla para enviarla.

Qué apps muestran este error — y por qué no es tu clave API

Cualquier app de navegador que almacene tu clave API en una cookie puede mostrarlo. Esa es la respuesta honesta, y vale la pena decirlo porque la guía mejor posicionada para esta consulta culpa a herramientas IDE como Cursor, Windsurf y Cline — con números de versión específicos que no corresponden a un error real basado en cookies. Esas herramientas almacenan claves en archivos de configuración locales, no en cookies del navegador.

Dónde ves realmente API key not found in cookies:

El hilo común: tu clave nunca llegó a una cuenta del lado del servidor. Está en tu navegador, y tu navegador le perdió la pista. Eso replantea todas las soluciones siguientes: no estás arreglando una clave, estás arreglando el almacenamiento de cookies.

¿Por qué sigue desapareciendo la cookie de la clave API?

Porque los navegadores modernos bloquean las cookies de terceros por defecto, y la cookie que contiene tu clave a menudo se trata como una. Esta es la causa raíz que la mayoría de guías de “borra tu caché” omiten.

Mira los valores predeterminados. Cambiaron bajo los pies de todos:

Así que la misma clave que “funciona en mi laptop” falla en una ventana privada, en un navegador de trabajo restringido o después de que una actualización del navegador cambió un valor predeterminado de privacidad. El intercambio parece completarse: la app simplemente no puede escribir o leer la cookie después.

Algunas razones más por las que la cookie desaparece:

• Borraste cookies (o usaste “borrar datos de navegación”): la cookie de la clave se fue con todo lo demás.
• Otro navegador o dispositivo: las cookies no se sincronizan entre ellos, así que la clave no está allí.
• Dominio o subdominio incorrecto: una cookie configurada en app.example.com no es visible en example.com, y viceversa.
• Desfase del reloj del sistema: las cookies llevan una marca de tiempo de expiración. Si tu reloj está desfasado por minutos, el navegador puede tratar una cookie nueva como ya expirada.
• Proxy corporativo con inspección SSL o VPN: algunos reescriben o descartan encabezados Set-Cookie, así que la cookie nunca llega.

¿Cómo arreglo “API key not found in cookies” ahora mismo?

Avanza por esta lista: los dos primeros pasos solucionan la mayoría de casos en menos de un minuto:

1. Permite cookies para el dominio exacto de la app. En Chrome/Edge: Configuración → Privacidad y seguridad → Cookies de terceros → agrega la URL de la app en “Permitidos para usar cookies de terceros”. En Safari: Configuración → Privacidad → desmarca “Impedir seguimiento entre sitios” (o agrega una excepción de sitio). En Firefox: icono de escudo en la barra de direcciones → desactiva la Protección contra rastreo mejorada para ese sitio.
2. Cierra sesión, vuelve a iniciarla y luego vuelve a pegar tu clave. Esto obliga a la app a crear una sesión nueva y escribir una cookie limpia. Es el equivalente de estado de autenticación a apagar y encender de nuevo.
3. Sal de Incognito/Private mode. Estos bloquean cookies de terceros por diseño, y nada persiste después de cerrar la ventana. Usa una ventana normal y vuelve a introducir la clave.
4. Desactiva bloqueadores de anuncios / extensiones de privacidad para ese sitio. uBlock Origin, AdGuard y complementos de privacidad pueden bloquear el subdominio por el que viaja la cookie. Pon la app en la lista de permitidos, recarga y vuelve a introducir la clave.
5. Revisa el reloj de tu sistema. Activa fecha/hora automáticas para que NTP te mantenga sincronizado. Un reloj desfasado expira silenciosamente cookies buenas.
6. Confirma que estás en la URL exacta donde se guardó la clave. Si guardaste la clave en app.tool.com, una cookie no aparecerá en tool.com. Haz coincidir el subdominio.
7. Regenera la clave en el panel del proveedor. Si un compañero de equipo la rotó o eliminó, la cookie ahora apunta a una clave muerta. Crea una nueva, pégala y listo.

Si estás en una red corporativa y nada de esto se mantiene, prueba con el hotspot de un teléfono durante dos minutos. Si funciona allí, un proxy con inspección SSL se está comiendo tus cookies: pídele a IT que omita el dominio de la app.

¿Cómo detengo este error para siempre?

Deja de depender de una cookie del navegador para transportar tu clave. Si controlas el código, envía la clave en un encabezado de solicitud en su lugar: las cookies son opcionales, los encabezados no.

Las claves almacenadas en cookies son frágiles por diseño: viven en un perfil de navegador, heredan las reglas de privacidad de ese navegador y desaparecen al borrar la caché. La autenticación basada en encabezados evita todo eso. La clave viaja en la solicitud:

curl https://api.velokey.ai/v1/chat/completions \
  -H "Authorization: Bearer $YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Sin tarro de cookies, sin política de cookies de terceros, sin sorpresa de incógnito. La misma llamada se ejecuta desde un script, un servidor, un trabajo de CI o un backend con el que habla tu frontend; ninguno de ellos tiene el problema de cookies en primer lugar. Si estás creando una app de navegador, el patrón duradero es mantener la clave en tu propio backend y hacer que el navegador llame a *tu* servidor, no pegar una clave de proveedor sin procesar en una cookie del lado del cliente.

También por eso las puertas de enlace de API no se topan con este error. Una puerta de enlace como [Velokey](https://api.velokey.ai) te da una clave que llega a muchos modelos — [GPT-5.6](/model/gpt-5.6), [Claude Opus 4.8](/model/claude-opus-4-8), [Claude Sonnet 5](/model/claude-sonnet-5) — a través de un único endpoint compatible con OpenAI, y esa clave viaja en el encabezado Authorization cada vez. No hay cookie que perder. Si estabas pegando una clave de proveedor en un frontend de chat solo para probar un modelo, llamar directamente a un endpoint estable es más simple y más difícil de romper. Para el lado de precios de eso, consulta nuestra guía de precios de Claude API; para un recorrido completo, cómo llamar a una API con una clave cubre la configuración de principio a fin.

Referencia de solución rápida

Preguntas frecuentes

¿“API key not found in cookies” es específico de una app?

No. Es un mensaje genérico de cualquier app de navegador que almacena tu clave API en una cookie: frontends de chat con IA, paneles de reverse-proxy y algunos playgrounds web usan este patrón. Las guías que lo atribuyen a un solo IDE están adivinando. La solución es la misma sin importar cuál sea: reparar o reemplazar la cookie que contiene tu clave.

¿Borrar cookies eliminará mi clave API permanentemente?

No. Tu clave vive en el panel del proveedor, no en la cookie. Borrar cookies solo elimina la copia local que la app estaba leyendo. Se cerrará tu sesión y se te pedirá que pegues la clave de nuevo, pero la clave en sí permanece intacta. Cópiala desde el proveedor antes de borrar, para que puedas volver a introducirla.

¿Puede Incognito o el modo privado causar este error?

Sí, de forma fiable. Las ventanas Incognito, Private e InPrivate bloquean cookies de terceros por defecto y eliminan todo cuando las cierras. Si guardaste la clave en una ventana privada, ya desapareció. Cambia a una ventana normal, vuelve a introducir la clave y persistirá entre sesiones.

¿Una VPN o un proxy corporativo lo desencadenan?

Puede ocurrir. Un proxy corporativo con inspección SSL o algunas VPN reescriben o eliminan el encabezado Set-Cookie, así que la cookie de la clave nunca llega a tu navegador. Prueba rápida: cambia al hotspot de un teléfono durante un minuto. Si el error desaparece, la red es la causa; pide a IT que agregue el dominio de la app a la lista de omisión de inspección.

¿Este error afecta a las llamadas API del lado del servidor?

No. Las llamadas de servidor a servidor envían la clave en un encabezado Authorization, y no hay ninguna cookie de navegador involucrada, así que este error no puede ocurrir allí. Solo aparece en apps de navegador que eligieron almacenar tu clave del lado del cliente. Mover la autenticación a un encabezado de solicitud es exactamente por lo que backends y scripts nunca lo ven.

¿Por qué las puertas de enlace o agregadores de API no tienen este problema?

Porque autentican con un encabezado, no con una cookie. Envías Authorization: Bearer <key> en cada solicitud a un endpoint estable, así que no hay cookie de navegador que bloquear, expirar o borrar. Esa es la razón estructural por la que una llamada a una puerta de enlace sigue funcionando entre navegadores, ventanas privadas y redes restringidas donde un frontend basado en cookies falla silenciosamente.