Erreurs de l’API solvethree : que corriger et quand réessayer

Traitez les réponses HTTP qui n’indiquent pas un succès avant de lire les données de réussite. Pour POST /v1/tasks, 201 signifie qu’une nouvelle tâche a été créée ; 200 signifie qu’un renvoi idempotent a retourné la tâche existante. Aucune de ces réponses ne signifie que la résolution est terminée.

400 — corps de requête invalide

Comparez le corps soumis aux champs et aux exigences documentés pour votre type de tâche.

Essayez ceci : Corrigez les données avant de soumettre à nouveau la requête. Renvoyer un corps invalide sans le modifier ne corrigera pas le problème. Utilisez le contrat de création des tâches pour vérifier la requête.

401 — clé API invalide

Vérifiez que la requête inclut Authorization: Bearer suivi d’une clé API valide de l’espace de travail.

Essayez ceci : Ajoutez la clé manquante ou corrigez la clé rejetée. Conservez-la sur le serveur plutôt que de l’exposer dans le code du navigateur.

402 — crédit insuffisant

Vérifiez le solde de crédit de l’espace de travail associé à la clé API.

Essayez ceci : Ajoutez du crédit à cet espace de travail avant de réessayer. Ne considérez pas les erreurs HTTP ou les échecs de tâches sans rapport comme des problèmes de solde.

403 — profil de site inactif

Pour reCAPTCHA, vérifiez que le site cible dispose d’un profil actif accessible à votre espace de travail.

Essayez ceci : Configurez le site cible dans la console et vérifiez que le profil est actif. Fournir un nom d’hôte et une action dans la tâche ne crée pas de profil. Cette réponse de la passerelle ne prouve pas que le site web cible vous a bloqué.

409 — conflit d’identifiant de requête

Vérifiez si le même requestId a déjà été utilisé avec des données de tâche différentes.

Essayez ceci : Utilisez les données d’origine pour récupérer la tâche d’origine. Si vous souhaitez créer une tâche différente, attribuez-lui un nouvel identifiant de requête.

410 — résultat stocké expiré

Vérifiez si vous tentez de récupérer une tâche terminée dont le résultat stocké n’est plus conservé.

Essayez ceci : Arrêtez de demander ce résultat. Lancez une nouvelle résolution si vous en avez encore besoin. Ce statut concerne la conservation des résultats de l’API, pas la durée de validité du jeton ou du cookie cible.

429 — limite de débit atteinte

Lisez la valeur Retry-After effectivement renvoyée dans la réponse.

Essayez ceci : Attendez la durée indiquée avant de réessayer et réduisez le débit des requêtes. Ne continuez pas à interroger ou à soumettre au même rythme pendant que la limitation s’applique.

502 — service de génération indisponible

Distinguez l’indisponibilité du service des données invalides ou d’un crédit insuffisant.

Essayez ceci : Réessayez plus tard. Pour une nouvelle tentative de la même requête de création, réutilisez son identifiant de requête et les données de tâche inchangées.

HTTP 503 signifie qu’aucune capacité de génération n’est disponible. Réessayez plus tard ; pour la même requête de création, réutilisez son identifiant de requête et les données de tâche inchangées.

• pending ou solving : continuez à interroger la tâche existante ; n’en créez pas une autre simplement parce qu’elle n’est pas prête.
• ready : arrêtez l’interrogation et lisez la solution.
• failed : arrêtez l’interrogation et examinez errorCode et error.

{
  "id": "example_login_001",
  "status": "failed",
  "errorCode": "site-unreachable",
  "error": "target page did not respond"
}

Ici, site-unreachable est un code d’erreur de tâche, pas un statut HTTP. Vérifiez l’URL cible soumise et assurez-vous que la page répond avant de demander une autre résolution. Des interrogations supplémentaires ne relanceront pas cette tâche en échec, et renvoyer son identifiant de requête d’origine retourne la tâche existante au lieu d’en lancer une nouvelle.

Un délai de connexion dépassé ne prouve pas que la création de la tâche a échoué. Utilisez un requestId facultatif avant votre première tentative de création pour pouvoir récupérer la même tâche logique en toute sécurité. Il doit contenir de 1 à 64 lettres ASCII, chiffres, traits de soulignement ou traits d’union.

1. 1.

   Si vous avez l’identifiant de la tâche, récupérez-la

   Utilisez GET /v1/tasks/:id et traitez la réponse HTTP avant de vérifier le statut de la tâche.

2. 2.

   Si la réponse de création a été perdue, renvoyez la requête d’origine

   Soumettez les mêmes données de tâche avec le même identifiant de requête. Le renvoi idempotent retourne la tâche existante si elle a été créée. Ne modifiez pas les données associées à cet identifiant.

3. 3.

   Ne créez une tâche de remplacement que si vous souhaitez lancer une autre résolution

   Un nouvel identifiant de requête représente un nouveau travail, pas la récupération de la requête précédente. Utilisez-le délibérément, par exemple après avoir examiné un échec définitif et décidé de réessayer.

Consultez la récupération par identifiant de requête pour gérer les renvois, ou l’interrogation et les délais d’attente lorsque la création a réussi mais que la tâche est toujours en cours.