TL;DR: La actualización de passkeys de WhatsApp de junio de 2026 impone una aserción estricta de WebAuthn que los servidores headless no pueden falsificar. Si tu integración con Baileys o Puppeteer está atascada en un error 428, migra a Whapi.Cloud y usa la solución de Pegado Manual para inyectar un payload de un solo uso y restaurar la conectividad de inmediato.
El lanzamiento de junio de 2026: Por qué los bots fallan de repente
A finales de junio de 2026, WhatsApp implementó una actualización en sus servidores que detuvo los bots de producción a nivel mundial. Las integraciones basadas en Baileys, whatsmeow y whatsapp-web.js comenzaron a devolver repentinamente errores 428 durante la vinculación de dispositivos.
WhatsApp activó el flujo de vinculación "Shortcake", que requiere un passkey para vincular un nuevo dispositivo. Esto afecta exactamente a la etapa de emparejamiento donde operan las cuentas automatizadas, congelando de inmediato las bibliotecas de código abierto que dependen de códigos QR. Hemos visto cómo cuentas de mensajería de alto volumen que usan integraciones no oficiales de Baileys para flujos de trabajo CRM se detienen repentinamente debido a las agresivas restricciones de los Passkeys.
Cómo WebAuthn bloquea los servidores headless
Los servidores headless fallan en navigator.credentials.get() porque carecen de un autenticador de hardware y no pueden coincidir con el ID de la parte usuaria (relying-party) whatsapp.com.
El protocolo WebAuthn del W3C utiliza criptografía de hardware para evitar el secuestro de sesiones remotas. Imagínalo como un cajero automático. WhatsApp es el banco, el Passkey es tu tarjeta bancaria física, la aplicación móvil de WhatsApp es tu sucursal local y WhatsApp Web es el cajero automático. Cuando vinculas un dispositivo, el cajero le pide al banco que verifique tu tarjeta. El banco emite un desafío criptográfico que solo la tarjeta física puede firmar.
// Without a hardware authenticator, headless Puppeteer fails here
// The promise rejects with: DOMException: The operation either timed out or was not allowed.
const credential = await navigator.credentials.get({
publicKey: {
challenge: serverChallenge,
rpId: "whatsapp.com",
userVerification: "required"
}
});
Un contenedor headless de Chromium que se inicia en un centro de datos no tiene una tarjeta física. Falsificar una aserción firmada fuera de un navegador real es imposible sin acceso a la clave privada del passkey aprovisionado. La API de WebAuthn impone la verificación del dominio contra el ID de la parte usuaria whatsapp.com, rechazando el cliente headless y devolviendo un error permanente de "Algo salió mal".
El flujo de vinculación "Shortcake" y sus fallos de UX
La defectuosa experiencia de usuario (UX) de WhatsApp provoca bucles interminables cuando los passkeys no coinciden entre cuentas de Google sincronizadas o cuando falla la vinculación por proximidad Bluetooth.
Una vez que un usuario crea un passkey, WhatsApp lo exige para todas las vinculaciones de dispositivos futuras. Si el passkey se elimina del dispositivo pero sigue activo en los servidores de WhatsApp, el usuario queda bloqueado. Esta fricción complica la implementación para los usuarios legítimos y crea obstáculos insuperables para las implementaciones automatizadas.
El costo oculto de las bibliotecas de código abierto "gratuitas"
Las bibliotecas gratuitas ocultan enormes costos de mantenimiento cuando WhatsApp introduce actualizaciones criptográficas no documentadas, obligando a los equipos a recurrir a soluciones manuales no escalables.
Cuando llegó la actualización de los passkeys, la solución inmediata de la comunidad fue la extracción manual de sesiones: iniciar sesión en el cliente oficial de WhatsApp Web, extraer los datos de la sesión autenticada e inyectarlos en la biblioteca. En la práctica, los equipos descubren rápidamente que esta extracción manual desde clientes web oficiales es insostenible para plataformas CRM automatizadas que gestionan cientos de números.
Este incidente expone el verdadero costo de la infraestructura autohospedada. El código abierto se rompe de forma inesperada; los mantenedores y los operadores asumen juntos el impacto. Whapi.Cloud absorbe los cambios de protocolo de forma interna, manteniendo estable la API orientada al cliente y reduciendo las interrupciones sorpresivas vinculadas a cambios silenciosos en el protocolo.
Cómo desbloquear tu integración: La solución de Pegado Manual
El Pegado Manual de Whapi inyecta un payload seguro y de un solo uso para superar la barrera de WebAuthn y restaurar la conectividad en minutos.
Whapi.Cloud ofrece una solución optimizada que elimina los complejos extractores de sesiones. La función de Pegado Manual te permite generar la aserción de WebAuthn requerida en tu propio navegador local y pasarla de forma segura a tu instancia de Whapi.Cloud.
El payload es una firma criptográfica de un solo uso que expira inmediatamente. Copias el script de desafío desde el panel de Whapi, lo pegas en la consola de una pestaña de WhatsApp Web con la sesión iniciada y devuelves la aserción firmada. Esto evita la limitación headless sin exponer tus claves privadas.
Para conocer los pasos detallados, lee la guía de Whapi.Cloud sobre el nuevo paso de passkey.
Lo que viene a continuación: AutoPasskey
El próximo AutoPasskey de Whapi abstraerá por completo la compleja ceremonia de aserción del W3C para los desarrolladores.
Si bien el Pegado Manual resuelve la crisis inmediata, la solución a largo plazo requiere eliminar por completo el paso del navegador. Whapi.Cloud está desarrollando activamente AutoPasskey, que manejará automáticamente las restricciones de la parte usuaria. Migrar a una infraestructura en la nube gestionada garantiza que tu integración sobreviva a la próxima actualización de protocolo no documentada.
