Rapprocher l’utilisation des CAPTCHA du solde de votre espace de travail

Les requêtes API s’authentifient avec une clé API d’espace de travail. Vérifiez cet espace de travail lors du rapprochement de l’utilisation ; un nom d’hôte cible commun ne signifie pas que les requêtes appartiennent au même espace de travail.

L’utilisation sur /usage porte le libellé 28 derniers jours. Elle affiche Request volume, Successful, Failed (not billed), Average latency et soit Period spend, soit Unlimited coverage. Ne déduisez pas de cette seule période une facture correspondante ou le solde de crédit actuel.

Utilisez By site profile pour repérer un pic. Comparez Site, Share et Requests pour trouver où le volume a augmenté, puis examinez Success et Billing. Il s’agit d’événements d’utilisation du service, pas de preuves que la cible a accepté les requêtes résultantes.

Une tâche au statut ready est facturée. Une résolution échouée est remboursée. Créer une tâche ou recevoir une réponse HTTP de succès ne revient pas à recevoir une solution utilisable ; seul ready en contient une.

Si le solveur renvoie une solution prête mais que le site web rejette la requête suivante, il ne s’agit pas d’un échec de tâche du solveur. Ne le comptabilisez pas dans Failed (not billed) et ne supposez pas qu’il donne lieu à un remboursement automatique. Une tâche de remplacement qui atteint ready constitue une autre résolution facturée.

Le dépôt minimal de crédit est de $10 ; le crédit de bienvenue est de $5. Un dépôt ajoute du crédit à l’espace de travail : il ne correspond pas au montant dépensé pendant la période d’utilisation. Distinguez le crédit acheté du crédit de bienvenue lorsque vous comparez vos paiements au solde.

Pour estimer le coût à l’usage, basez-vous sur les tâches facturées au statut ready, et non sur le volume total de requêtes. Si la console affiche Unlimited coverage, consultez plutôt le forfait mensuel propre au produit concerné au lieu de facturer toutes les requêtes à l’usage. Le crédit du compte ou un bonus applicable peut également modifier le crédit supplémentaire nécessaire.

1. 1.

   Identifier le site et la période concernés

   Utilisez la répartition par profil de site pour affiner la recherche, puis comparez les journaux de votre application sur la même période. Consignez la requête logique, son requestId, l’ID de tâche renvoyé et le statut final.

2. 2.

   Rechercher plusieurs tâches pour une même requête

   Plusieurs ID de tâche distincts pour une seule résolution prévue peuvent expliquer des frais supplémentaires si ces tâches atteignent le statut ready. Distinguez les résolutions de remplacement délibérées des nouvelles tentatives effectuées parce qu’une réponse a été perdue.

3. 3.

   Récupérer les requêtes de création ayant expiré

   Une expiration du délai de connexion ne prouve pas que la création de la tâche a échoué. Si vous avez l’ID de tâche, récupérez cette tâche. Sinon, renvoyez la même requête de tâche avec son requestId d’origine pour récupérer la tâche existante plutôt que de créer une nouvelle tâche logique.

4. 4.

   Attribuer requestId avant la première tentative

   Utilisez un requestId par résolution prévue et conservez-le lors des nouvelles tentatives. Il accepte de 1 à 64 caractères ASCII : lettres, chiffres, traits de soulignement ou traits d’union. Le même ID avec la même requête de tâche renvoie la tâche existante ; son utilisation avec des paramètres différents provoque un conflit.

Pour rechercher des créations en double, comptez les tâches distinctes, pas seulement les tentatives HTTP. Plusieurs nouvelles tentatives renvoyant le même ID de tâche n’ont pas créé plusieurs tâches.