Llama a la API de resolución de CAPTCHA desde n8n

1. 1.

   Activa el perfil del sitio

   Configura el nombre de host de destino en la consola de solvethree y comprueba que su perfil esté activo para tu espacio de trabajo. Enviar un nombre de host y una acción en una tarea no crea el perfil.

2. 2.

   Crear una credencial de autenticación por cabecera en n8n

   Configúrala para enviar una cabecera Authorization cuyo valor sea Bearer seguido de la clave de API de tu espacio de trabajo. Guarda la clave en la credencial, no en el JSON de la tarea.

Asigna al nodo HTTP Request el nombre Create task. El nodo de consulta hará referencia a este nombre para recuperar el ID de la tarea original.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

Sustituye site, action y proxy por el nombre de host, la acción y el proxy de tu solicitud. Envía exactamente uno de estos campos: proxy o proxyCandidates; este ejemplo usa un solo proxy. No añadas type ni url. El tipo de reCAPTCHA predeterminado es Enterprise v3.

Sustituye el requestId del ejemplo por un valor único para cada nueva tarea lógica. Mantén ese valor sin cambios si necesitas recuperar esta tarea tras agotarse el tiempo de espera. Admite entre 1 y 64 letras ASCII, números, guiones bajos o guiones.

waitMs debe ir en la cadena de consulta de la URL, no en el cuerpo JSON. Configura el tiempo de espera de la solicitud HTTP por encima de los 15 segundos de espera solicitados para dejar margen a la sobrecarga de red; 30 segundos es una configuración inicial razonable, no una garantía del tiempo de resolución. La credencial de autenticación por cabecera proporciona la autenticación, por lo que no necesitas duplicarla en Enviar cabeceras.

Gestiona las respuestas HTTP no satisfactorias antes de inspeccionar el contenido de la tarea. Si la respuesta es satisfactoria, conecta un nodo IF o Switch e inspecciona {{ $json.status }}.

Para una tarea de reCAPTCHA lista, envía el token devuelto usando la identidad devuelta en userAgent y secChUa, y el proxy que funcionó. Que una tarea esté lista significa que se generó una solución; no demuestra que el sitio web aceptara la solicitud posterior.

Las resoluciones fallidas se reembolsan. Diagnostica el error indicado en lugar de reintentar con los mismos datos de entrada o asumir que el espacio de trabajo no tiene crédito suficiente.

1. 1.

   Guardar un plazo límite fijo

   Antes de que se ejecute Create task, guarda un plazo límite de consultas en el flujo de trabajo; por ejemplo, dos minutos después de que comience la creación. Esta es la política de detención de tu flujo de trabajo, no un límite de la API de solvethree. Mantén el plazo límite fuera de la respuesta HTTP para que las respuestas posteriores no lo sobrescriban.

2. 2.

   Condicionar cada iteración de consulta

   Para los estados pendiente o en proceso de resolución, usa un nodo IF para comparar la hora actual con el plazo límite guardado. Si ha vencido, termina el bucle y conserva el ID de la tarea. De lo contrario, usa un nodo Wait para pausar durante dos segundos y vuelve a comprobar el plazo límite antes del GET.

3. 3.

   Recuperar la tarea existente

   Configura un segundo nodo HTTP Request con los ajustes siguientes. Devuelve su respuesta a la misma bifurcación por estado. Nunca redirijas la rama de consultas a Create task.

La expresión del ID de tarea es {{ $('Create task').item.json.id }}. Lee id del nodo de creación indicado, incluso cuando el elemento más reciente contiene una respuesta de consulta u otros datos del flujo de trabajo. Mantén el nombre del nodo en la expresión en consonancia con tu flujo de trabajo.

GET admite una espera de hasta 15 segundos. Asigna a esta solicitud HTTP el mismo margen de tiempo de espera que a la solicitud de creación. El plazo límite detiene los nuevos intentos de consulta; una solicitud ya en curso puede finalizar después.

La solicitud GET equivalente fuera de n8n es:

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

Que se agote el tiempo de espera de la conexión no demuestra que la creación haya fallado. Si recibiste un ID, recupera esa tarea. Si no, repite el POST con los mismos datos de entrada de la tarea y el mismo requestId para recuperar la tarea existente. Reutilizar ese ID con datos de entrada diferentes provoca un conflicto.

Del mismo modo, alcanzar el plazo límite de consultas es una condición de detención local, no un estado de tarea fallida. Conserva el ID original para que una ejecución posterior pueda recuperar la tarea en lugar de pagar por otra resolución.