Usa APIRequestContext de Playwright con una solución de CAPTCHA

1. 1.

   Instala las dependencias

   Usa Node.js 22+ e instala el paquete playwright. Instala el SDK oficial de JavaScript desde el archivo tarball de la versión 0.1.0 de solvethree: solvethree-sdk-0.1.0.tgz, disponible en /downloads/ en solvethree.com. Se importa como @solvethree/sdk; no des por hecho que hay una versión disponible en el registro.

2. 2.

   Configura las variables de entorno

   Proporciona SOLVETHREE_API_KEY, SOLVETHREE_PROXY y TARGET_URL al proceso de Node.js. Mantén la clave de API del espacio de trabajo en el servidor. TARGET_URL debe ser el endpoint POST real de la aplicación, no simplemente la página que muestra el CAPTCHA. Usa una URL de proxy HTTP o HTTPS sin ruta, parámetros de consulta ni fragmento.

3. 3.

   Confirma el perfil del sitio y la acción

   El nombre de host de destino necesita un perfil activo disponible en tu espacio de trabajo. Configúralo en la consola antes de resolver el CAPTCHA; pasar un nombre de host no crea un perfil. El ejemplo usa la acción login; cámbiala si el destino espera otra acción. La solicitud usa reCAPTCHA Enterprise v3 de forma predeterminada.

Ten preparados los campos obligatorios del formulario y los requisitos de sesión de la aplicación antes de ejecutar el ejemplo. Este solo envía el campo de respuesta del CAPTCHA. Consulta la configuración del perfil del sitio si el nombre de host aún no está configurado.

import { request } from 'playwright';
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const target = new URL(process.env.TARGET_URL);
const proxy = new URL(process.env.SOLVETHREE_PROXY);
const result = await client.solve({ site: target.hostname, action: 'login', proxy: process.env.SOLVETHREE_PROXY });
const proxyConfig = { server: `${proxy.protocol}//${proxy.host}`, username: decodeURIComponent(proxy.username), password: decodeURIComponent(proxy.password) };

const targetClient = await request.newContext({
  proxy: proxyConfig, timeout: 30000,
  extraHTTPHeaders: { 'User-Agent': result.solution.userAgent, 'sec-ch-ua': result.solution.secChUa },
  // storageState: 'your-application-session.json', // only if your flow needs it
});
try {
  const response = await targetClient.post(target.href, {
    form: { 'g-recaptcha-response': result.solution.token }, maxRedirects: 0,
  });
  console.log('Application HTTP status:', response.status());
  // Inspect the response and supply the application's actual fields/CSRF/session.
} finally { await targetClient.dispose(); }

client.solve() crea la tarea una sola vez y consulta su estado hasta que esté lista o se lance una excepción. El ejemplo usa un mismo proxy para resolver el CAPTCHA y enviar la solicitud. Para Playwright, separa la dirección del servidor proxy de sus credenciales y decodifica el nombre de usuario y la contraseña.

El contexto de solicitud aplica solution.userAgent y solution.secChUa como cabeceras. El formulario envía solution.token en g-recaptcha-response, no el ID de la tarea. Mantén el proxy y la identidad devuelta juntos; no los sustituyas por cabeceras de navegador ajenas ni envíes el token a un destino diferente.

Amplía el formulario con los campos reales de la aplicación, incluidas las credenciales o los datos CSRF cuando sean necesarios. Si ya tienes la sesión requerida de la aplicación, habilita la opción storageState y haz que apunte al estado guardado de esa sesión.

APIRequestContext mantiene su propio almacén de cookies, de modo que las solicitudes realizadas a través del mismo contexto conservan las cookies que recibe. No comparte automáticamente las cookies con un contexto de navegador independiente. Mantén las solicitudes previas necesarias para la sesión y el POST final en el mismo contexto cuando necesiten compartir cookies. El bloque finally libera el contexto cuando finaliza el envío.

El ejemplo registra el estado HTTP de la aplicación; no confirma que el inicio de sesión haya tenido éxito. Con maxRedirects establecido en cero, ves la respuesta inicial en lugar de seguir una redirección. Inspecciona su cuerpo, sus cabeceras y sus cookies y compáralos con la respuesta de éxito esperada de la aplicación. Una redirección o un HTTP 200 por sí solos pueden no indicar si la operación tuvo éxito.

La tarea está lista, pero la aplicación rechaza el POST.

Inspecciona primero la solicitud saliente: el campo del token, el nombre de host y la acción, el proxy, la identidad devuelta, los campos obligatorios del formulario, el valor CSRF y las cookies de sesión.

Prueba esto: Corrige los datos de la solicitud que falten o no coincidan antes de pagar por otra resolución. Una tarea lista proporciona una solución utilizable, no una garantía de que la aplicación de destino la acepte.

La resolución termina con una tarea fallida.

Lee errorCode y error; no trates todos los fallos como un problema de saldo.

Prueba esto: Deja de consultar el estado de esa tarea y soluciona la causa indicada. Las resoluciones fallidas se reembolsan. Para interpretar los errores, consulta la gestión de errores de la API.

Se agota el tiempo de espera al crear la tarea o se interrumpe la conexión.

Determina si tienes un ID de tarea o si usaste un requestId. Que se agote el tiempo de espera de la conexión no demuestra que la creación haya fallado.

Prueba esto: Recupera la tarea existente cuando tengas su ID. Para las solicitudes de creación recuperables, proporciona un requestId y reutilízalo con exactamente los mismos datos de entrada; esto devuelve la tarea existente. No inicies inmediatamente otra resolución lógica.

La solicitud a la aplicación devuelve un error HTTP.

Inspecciona la respuesta del destino por separado del resultado de la tarea de solvethree.

Prueba esto: Gestiona la respuesta que no indica éxito antes de tratar su cuerpo como datos de una respuesta exitosa. Corrige la solicitud a la aplicación o el error del servidor indicado en lugar de asumir que el token lo causó.