Chame a API de resolução de CAPTCHA pelo n8n

1. 1.

   Ative o perfil do site

   Configure o hostname de destino no console do solvethree e verifique se o perfil dele está ativo no seu workspace. Enviar um hostname e uma ação em uma tarefa não cria o perfil.

2. 2.

   Crie uma credencial Header Auth no n8n

   Configure-a para enviar um cabeçalho Authorization com o valor Bearer seguido da chave de API do seu workspace. Armazene a chave na credencial, não no JSON da tarefa.

Nomeie o nó HTTP Request como Create task. O nó de consulta periódica usará esse nome para recuperar o ID da tarefa original.

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

Substitua site, action e proxy pelo hostname, pela ação e pelo proxy da sua requisição. Envie exatamente um dos campos: proxy ou proxyCandidates; este exemplo usa um proxy. Não adicione type nem url. O tipo padrão de reCAPTCHA é Enterprise v3.

Substitua o requestId do exemplo por um valor exclusivo para cada nova tarefa lógica. Mantenha esse valor inalterado se precisar recuperar esta tarefa após um timeout. Ele aceita de 1–64 letras ASCII, números, sublinhados ou hífens.

waitMs deve ficar na query da URL, não no corpo JSON. Defina o timeout da requisição HTTP acima da espera solicitada de 15 segundos para acomodar a sobrecarga de rede; 30 segundos é uma configuração inicial razoável, não uma garantia de tempo de resolução. A credencial Header Auth fornece a autenticação, então não é necessário duplicá-la em Enviar cabeçalhos.

Trate respostas HTTP sem sucesso antes de inspecionar o payload da tarefa. Para uma resposta bem-sucedida, conecte um nó IF ou Switch e inspecione {{ $json.status }}.

Para uma tarefa de reCAPTCHA pronta, envie o token retornado usando a identidade retornada em userAgent e secChUa e o proxy que funcionou. Uma tarefa pronta significa que uma solução foi gerada; isso não comprova que o site aceitou a requisição subsequente.

Resoluções que falham são reembolsadas. Diagnostique o erro informado em vez de tentar novamente com os mesmos dados de entrada ou presumir que o workspace não tem crédito suficiente.

1. 1.

   Salve um prazo fixo

   Antes de executar Create task, armazene no workflow um prazo para as consultas — por exemplo, dois minutos após o início da criação. Essa é a política de parada do seu workflow, não um limite da API do solvethree. Mantenha o prazo fora da resposta HTTP para que respostas posteriores não o sobrescrevam.

2. 2.

   Verifique cada ciclo de consulta

   Para os estados pendente ou em resolução, use um nó IF para comparar a hora atual com o prazo salvo. Se o prazo tiver expirado, encerre o loop e mantenha o ID da tarefa. Caso contrário, use um nó Wait para pausar por dois segundos e verifique o prazo novamente antes do GET.

3. 3.

   Consulte a tarefa existente

   Configure um segundo nó HTTP Request com as configurações abaixo. Encaminhe a resposta dele de volta pela mesma ramificação de status. Nunca encaminhe a ramificação de consulta de volta para Create task.

A expressão do ID da tarefa é {{ $('Create task').item.json.id }}. Ela lê id do nó de criação nomeado, mesmo quando o item mais recente contém uma resposta de consulta ou outros dados do workflow. Mantenha o nome do nó na expressão consistente com o seu workflow.

GET aceita uma espera de até 15 segundos. Dê a esta requisição HTTP a mesma margem de timeout da requisição de criação. O prazo impede novas tentativas de consulta; uma requisição já em andamento pode terminar depois dele.

A requisição GET equivalente fora do n8n é:

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

Um timeout de conexão não prova que a criação falhou. Se você recebeu um ID, consulte essa tarefa. Caso contrário, repita o POST com os mesmos dados de entrada da tarefa e o mesmo requestId para recuperar a tarefa existente. Reutilizar esse ID com dados de entrada diferentes causa um conflito.

Da mesma forma, atingir o prazo das consultas é uma condição de parada local, não um status de falha da tarefa. Mantenha o ID original para que uma execução posterior possa consultá-lo em vez de pagar por outra resolução.