Appeler l’API de résolution de CAPTCHA depuis n8n

1. 1.

   Activer le profil de site

   Configurez le nom d’hôte cible dans la console solvethree et assurez-vous que son profil est actif pour votre espace de travail. Envoyer un nom d’hôte et une action dans une tâche ne crée pas le profil.

2. 2.

   Créer des identifiants Header Auth dans n8n

   Configurez-les pour envoyer un en-tête Authorization dont la valeur est Bearer suivi de la clé API de votre espace de travail. Stockez la clé dans les identifiants, pas dans le JSON de la tâche.

Nommez le nœud HTTP Request Create task. Le nœud d’interrogation utilisera ce nom pour récupérer l’ID de tâche d’origine.

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

Remplacez site, action et proxy par le nom d’hôte, l’action et le proxy de votre requête. Envoyez exactement un des champs proxy ou proxyCandidates ; cet exemple utilise un seul proxy. N’ajoutez ni type ni url. Le type reCAPTCHA par défaut est Enterprise v3.

Remplacez le requestId de l’exemple par une valeur unique pour chaque nouvelle tâche logique. Conservez cette valeur si vous devez récupérer cette tâche après expiration du délai. Elle accepte de 1 à 64 lettres ASCII, chiffres, traits de soulignement ou traits d’union.

waitMs doit figurer dans les paramètres de l’URL, pas dans le corps JSON. Définissez un délai d’expiration de la requête HTTP supérieur aux 15 secondes d’attente demandées pour tenir compte du temps réseau ; 30 secondes constituent une configuration initiale raisonnable, pas une garantie de temps de résolution. Les identifiants Header Auth assurent l’authentification : inutile de les dupliquer dans Envoyer les en-têtes.

Traitez les réponses HTTP non réussies avant d’examiner le contenu de la tâche. Pour une réponse réussie, connectez un nœud IF ou Switch et examinez {{ $json.status }}.

Pour une tâche reCAPTCHA prête, soumettez le jeton renvoyé en utilisant l’identité userAgent et secChUa renvoyée ainsi que le proxy qui a fonctionné. Une tâche prête signifie qu’une solution a été générée ; elle ne prouve pas que le site web a accepté la requête suivante.

Les résolutions échouées sont remboursées. Diagnostiquez l’erreur signalée plutôt que de réessayer avec des données inchangées ou de supposer que l’espace de travail manque de crédit.

1. 1.

   Enregistrer une échéance fixe

   Avant l’exécution de Create task, stockez une échéance d’interrogation dans le workflow — par exemple, deux minutes après le début de la création. Il s’agit de la règle d’arrêt de votre workflow, pas d’une limite de l’API solvethree. Conservez l’échéance en dehors de la réponse HTTP pour que les réponses suivantes ne l’écrasent pas.

2. 2.

   Conditionner chaque cycle d’interrogation

   Pour les statuts en attente ou en cours de résolution, utilisez un nœud IF pour comparer l’heure actuelle à l’échéance enregistrée. Si elle est dépassée, terminez la boucle et conservez l’ID de la tâche. Sinon, utilisez un nœud Wait pour attendre deux secondes, puis vérifiez à nouveau l’échéance avant le GET.

3. 3.

   Récupérer la tâche existante

   Configurez un second nœud HTTP Request avec les paramètres ci-dessous. Renvoyez sa réponse vers le même branchement selon le statut. Ne redirigez jamais la branche d’interrogation vers Create task.

L’expression de l’ID de tâche est {{ $('Create task').item.json.id }}. Elle lit id dans le nœud de création nommé, même lorsque le dernier élément contient une réponse d’interrogation ou d’autres données du workflow. Le nom du nœud dans l’expression doit correspondre à celui de votre workflow.

GET accepte une attente allant jusqu’à 15 secondes. Accordez à cette requête HTTP la même marge de délai qu’à la requête de création. L’échéance empêche de nouvelles tentatives d’interrogation ; une requête déjà en cours peut se terminer après celle-ci.

La requête GET équivalente en dehors de n8n est :

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

L’expiration du délai de connexion ne prouve pas que la création a échoué. Si vous avez reçu un ID, récupérez cette tâche. Sinon, répétez le POST avec les mêmes données de tâche et le même requestId pour récupérer la tâche existante. Réutiliser cet ID avec des données de tâche différentes provoque un conflit.

De même, atteindre votre échéance d’interrogation est une condition d’arrêt locale, pas un statut d’échec de la tâche. Conservez l’ID d’origine afin qu’une exécution ultérieure puisse récupérer la tâche au lieu de payer une autre résolution.