Tester solvethree dans Postman

1. 1.

   Importez le JSON téléchargé

   Dans Postman, choisissez Importer et sélectionnez le fichier de collection. Il contient Créer une tâche et Récupérer une tâche, avec une autorisation Bearer héritée et des variables de substitution.

2. 2.

   Vérifiez le profil du site

   Votre espace de travail doit disposer d’un profil actif pour le nom d’hôte cible. Configurez-le dans la console avant le test ; l’envoi d’un nom d’hôte et d’une action ne crée pas de profil. Consultez la configuration du profil de site.

3. 3.

   Configurez des valeurs d’environnement privées

   Créez et sélectionnez un environnement pour ce test. Renseignez les valeurs ci-dessous de manière privée, y compris les éventuels identifiants du proxy. Ne placez pas de secrets directement dans la collection et n’exportez pas les secrets renseignés.

4. 4.

   Configurez l’autorisation Bearer

   Au niveau de la collection, sélectionnez Bearer Token et référencez une variable d’environnement privée contenant la clé API de votre espace de travail. Laissez les deux requêtes hériter de l’autorisation. L’API attend Authorization: Bearer suivi de cette clé.

Ouvrez Créer une tâche. Cette requête envoie un POST à https://api.solvethree.com/v1/tasks avec un corps JSON brut renseigné à partir de l’environnement sélectionné.

{
  "site": "{{SITE}}",
  "action": "{{ACTION}}",
  "proxy": "{{PROXY}}",
  "requestId": "{{REQUEST_ID}}"
}

Cette requête utilise reCAPTCHA Enterprise v3 par défaut. N’ajoutez pas de champ type ou url. Elle fournit un seul proxy ; n’ajoutez donc pas aussi proxyCandidates : exactement un de ces champs est requis.

Définissez REQUEST_ID avant l’envoi, puis cliquez une seule fois sur Envoyer. Vérifiez d’abord la réponse HTTP. Si elle indique un échec, examinez l’erreur de requête au lieu de considérer le corps comme une réponse de tâche réussie. Corrigez les entrées invalides plutôt que de les renvoyer à répétition sans les modifier.

Si la réponse de création indique une réussite, copiez l’id renvoyé dans votre valeur d’environnement privée TASK_ID. Ne cliquez pas de nouveau sur Créer une tâche pour simplement vérifier la progression.

Ouvrez Récupérer une tâche et vérifiez que TASK_ID contient l’ID de tâche renvoyé. Cette requête utilise GET /v1/tasks/:id sur la même API. Envoyez-la manuellement, vérifiez la réponse HTTP, puis examinez le status de la tâche.

Un code HTTP 200 ou 201 ne signifie pas à lui seul qu’une solution est prête ; seul status: ready l’indique. Ce test manuel vérifie la création et la récupération de la tâche, pas l’acceptation du résultat par le site cible.

Si vous poursuivez en soumettant le jeton reCAPTCHA à sa cible prévue, utilisez l’identité de navigateur userAgent et secChUa renvoyée, ainsi que le proxy ayant permis la résolution. Ne changez pas d’adresse IP et n’utilisez pas une identité de navigateur sans rapport. Un jeton prêt peut tout de même être rejeté par la cible.

Un dépassement du délai de connexion ne prouve pas que la création a échoué. Si vous avez l’ID de tâche, récupérez-la. Si vous n’avez jamais reçu l’ID, renvoyez Créer une tâche avec le même REQUEST_ID et les entrées de tâche inchangées. Cela récupère la tâche existante au lieu de créer une autre tâche logique.

Ne générez pas un nouveau REQUEST_ID simplement parce que la réponse a été perdue. Réutiliser un ID avec des entrées de tâche différentes provoque un conflit ; utilisez un nouvel ID lorsque vous démarrez délibérément une nouvelle tâche.