Scarnox · Blog

Resolver PopularCaptcha invisible: en qué se diferencia y qué enviar

Un PopularCaptcha invisible parece no ser ningún captcha. No hay una casilla de "no soy un robot". El sitio llama a PopularCaptcha desde su propio JavaScript, normalmente cuando el visitante pulsa enviar, y muestra un desafío solo si no está seguro del visitante. Para un script de automatización el widget es más difícil de detectar, pero la resolución sigue siendo una sola petición.

Scarnox resuelve PopularCaptcha hoy, incluida la variante invisible. Activas un solo flag, is_invisible, y envías la misma petición que enviarías para un widget visible. Otros tipos de captcha llegarán pronto.

Cómo saber que es invisible

• El widget tiene data-size="invisible".
• El sitio llama a la función execute() del widget desde su propio código.
• Hay una sitekey en la página, pero no se ve ninguna casilla por ninguna parte.

La configuración de la sitekey es la que decide, no el aspecto de la página. Si no estás seguro, busca la sitekey y revisa las opciones del widget en el JavaScript de la página.

Qué enviar

Usa el mismo endpoint y el mismo tipo de tarea, y añade is_invisible con el valor true:

{
  "captcha_type": "PopularCaptchaTaskProxyless",
  "site_key": "10000000-ffff-ffff-ffff-000000000001",
  "site_url": "https://example.com/login",
  "is_invisible": true
}

Envíalo con tu clave en la cabecera Authorization: Bearer, como en todos los demás ejemplos. La llamada se bloquea hasta que el token está listo, sin sondeo. Usa un timeout de unos 185 segundos.

Cómo devolver el token

Las integraciones invisibles casi siempre usan un callback en lugar de un campo de formulario. El sitio pasa el nombre de una función al widget, ya sea en el atributo data-callback o en las opciones pasadas a render(). Llama a esa función con el token, y el propio código del sitio continúa como si el visitante hubiera superado el desafío:

await page.evaluate((t) => {
  document.querySelectorAll('[name="h-captcha-response"]').forEach((el) => { el.value = t; });
  const cb = document.querySelector("[data-sitekey]")?.dataset.callback;
  if (cb && typeof window[cb] === "function") window[cb](t);
}, token);

Rellenar también el campo oculto no hace daño, y cubre los sitios que leen ese campo al enviar.

El momento importa más de lo habitual

Con un widget invisible, el sitio decide cuándo se ejecuta el desafío, y normalmente es el momento en que el visitante envía. Así que resuelve en ese momento, no antes. El patrón más sencillo es disparar la resolución justo antes de pulsar el botón en tu script, y después llamar al callback y enviar.

Los tokens caducan en unos dos minutos. Un token obtenido durante la carga de la página y usado un minuto después probablemente será rechazado.

Error común

Enviar una sitekey invisible como una tarea visible normal puede producir un token que el sitio rechaza. Si la API devuelve un token pero el sitio lo rechaza, comprueba estos puntos en orden:

1. ¿Está is_invisible en true?
2. ¿Llama el sitio al callback, y lo hace antes de que se envíe el formulario?
3. ¿Es el site_url la página donde se ejecuta el widget invisible?
4. Si el sitio sigue rechazando el token, el problema puede estar ligado a la IP que lo resolvió. Compara con resolver con proxy frente a sin proxy.

Probar un flujo invisible de forma segura

Los widgets invisibles son difíciles de probar a mano, porque el desafío solo se ejecuta al enviar y, en la mayoría de los casos, pasa sin mostrar nada. Prueba en este orden:

1. Confirma que la resolución devuelve un token con is_invisible en true, usando la prueba rápida de la guía de la prueba gratuita.
2. Dispara tú mismo el callback del sitio en la consola del navegador con ese token, y observa si el formulario continúa.
3. Envía el formulario desde tu script y comprueba la página que aparece después.
4. Repite la ejecución desde una segunda red, si puedes, para confirmar que el token no está ligado a la IP que lo resolvió.

Mantén la prueba en un formulario que sea tuyo, o en una copia de staging del sitio que tengas permiso para probar. Nunca ejecutes un flujo invisible contra una cuenta real que no controlas.

El orden de los eventos en un envío invisible

Una integración que funciona sigue esta secuencia:

1. El visitante, o tu script, rellena el formulario.
2. Tu script lee la sitekey y la URL de la página desde la página.
3. Tu script llama al endpoint de resolución con is_invisible en true y espera el token.
4. Tu script escribe el token en el campo de respuesta y llama al callback del sitio.
5. El código del sitio envía el formulario con el token adjunto.

Si el paso 3 ocurre mucho antes que el paso 5, el token puede caducar antes de que se envíe el formulario. Mantén la separación lo más corta posible.

Cuando el sitio rechaza un token invisible

Un rechazo no siempre es un problema del token. Comprueba estos puntos antes de cambiar la petición de resolución:

• El callback se ejecutó antes de enviar el formulario, no después.
• El formulario lee el token del campo en el que escribió tu script. Algunos sitios usan otro campo para los widgets invisibles.
• La petición que lleva el token salió de la misma sesión que cargó la página. Las cookies de otra sesión no coinciden.
• La página no se recargó entre la resolución y el envío, lo que habría descartado el token.

Solo después de estas comprobaciones deberías pasar a la cuestión del proxy. La mayoría de los rechazos vienen del callback o de la sesión, no de la IP.

Próximos pasos

• Cómo resolver un PopularCaptcha en Python
• Resolver un PopularCaptcha en Playwright y Puppeteer
• Reintentos y manejo de errores que aguantan en producción
• Prueba gratuita del solver de captcha

Empieza con crédito de prueba gratis, sin tarjeta: crea una cuenta y prueba una sitekey invisible en una página que sea tuya.