Passer au contenu principal
Cette page décrit les erreurs rencontrées lors de l’utilisation des endpoints /auctions et /events de Topsort ou des API, classées par code d’état HTTP : 4xx : Problème de requête 5xx : Problème de service Topsort Les deux types d’erreurs renvoient des tableaux JSON contenant des objets d’erreur avec les champs : errCode, docUrl et un message optionnel.
ChampTypeDescription
errCodestringUne chaîne courte identifiant de manière unique le problème.
docUrlstringUn lien vers cette documentation fournissant plus d’informations sur l’erreur.
messagestringOptionnel. Si présent, explication lisible ou détails sur l’erreur. La chaîne pour une erreur donnée peut changer au fil du temps ; le code ne doit pas analyser ou distribuer en fonction de valeurs particulières pour ce champ.
Codes d’erreur et significations :
CodeDescriptionDétails
400Mauvaise requêteRequête inacceptable, c’est-à-dire formatage incorrect
403Interdit/Non autoriséProblème de clé API ou jetons manquants
404Non trouvéLe serveur ne peut pas trouver la ressource demandée. Soit l’URL de la requête n’est pas sur nos routes, soit la ressource n’est pas disponible (c’est-à-dire que la campagne demandée n’existe pas)
422Entité non traitableCorps de requête et modèle ne correspondent pas, c’est-à-dire qu’il vous manque une propriété, ou l’API attend une date mais a reçu un nombre
429Limite de taux dépasséeLimite de taux basée sur l’IP atteinte. Cette erreur est accompagnée des en-têtes suivants :
- X-RateLimit-Limit : nombre total de requêtes autorisées pour la période
- X-RateLimit-Remaining : nombre de requêtes restantes pour la période
- X-RateLimit-Reset : quand vous pourrez effectuer une autre requête

Codes d’erreur

Code d’erreurDescription
bad_requestLa requête n’a pas pu être analysée ; vérifiez la spécification OpenAPI pour le schéma correct.
empty_requestLa requête est vide ; vérifiez la spécification OpenAPI pour le schéma correct.
internal_server_errorProblème de serveur inattendu ; notre équipe résout généralement ces problèmes rapidement.
invalid_api_keyClé API manquante, invalide ou expirée ; voir authentification pour plus de détails.
invalid_auction_idL’ID d’enchère ne correspond pas à une enchère ; assurez-vous qu’un ID d’enchère valide est transmis dans la requête.
invalid_event_typeLe type d’événement doit être “Impression”, “Click” ou “Purchase”.
invalid_promotion_typeTypes de promotion invalides dans le champ slots.
invalid_sessionL’objet session doit contenir un sessionId non vide.
missing_aspect_ratioLe ratio d’aspect requis pour les bannières publicitaires est manquant.
missing_auctionsAu moins une enchère doit être spécifiée.
missing_contextContexte requis manquant ; spécifiez une catégorie, une liste de produits ou une requête de recherche.
missing_placementLe champ placement ou placement.page requis est manquant.
missing_product_idproductId manquant.
missing_promotion_typeUne enchère doit demander des emplacements pour au moins un type de promotion.
missing_purchased_atLe champ purchasedAt requis est manquant.
missing_sessionLe champ session requis est manquant.
missing_slotsLe champ slots requis est manquant.
no_productsAu moins un produit doit être spécifié.
no_purchase_itemsAu moins un article doit être acheté.
purchase_item_quantity_less_or_equal_than_zeroUn article acheté a une quantité inférieure ou égale à zéro.
resolved_bid_id_not_foundL’ID d’offre résolu fourni ne correspond pas à un enregistrement interne.
too_few_impressionsAu moins une impression doit être incluse.
too_few_slotsAu moins un emplacement doit être spécifié dans une enchère.
too_many_auctionsMaximum de 5 enchères peuvent être exécutées en parallèle ; contactez votre KAM pour augmenter cette limite.

Gestion de la limitation du taux

Nos endpoints - sauf pour les appels à /auctions ou /events - sont limités en taux pour éviter les abus. Si vous dépassez la limite de taux, vous recevrez une réponse d’erreur 429. Il existe deux méthodes recommandées pour gérer ces limites

Réessayer avec un délai exponentiel

La réessai avec délai exponentiel est une technique utilisée en programmation pour réessayer une opération avec des intervalles croissants entre les tentatives, ce qui aide à atténuer les problèmes tels que la latence réseau, les défaillances temporaires ou les contraintes de ressources. Ci-dessous se trouve un exemple de code en Python sur la façon dont la technique peut être implémentée.
def exponential_backoff_retry(url, max_retries=5, base_delay=1, max_delay=64, retry_on_status=429):
    retries = 0
    delay = base_delay
    while retries < max_retries:
        try:
            response = requests.get(url)
            if response.status_code == retry_on_status:
                print(f"Received status code {retry_on_status}, retrying...")
                retries += 1
                if retries < max_retries:
                    print(f"Retrying in {delay} seconds...")
                    time.sleep(delay)
                    delay = min(delay * 2, max_delay)
                else:
                    raise Exception(f"All retries exhausted for status code {retry_on_status}")
            else:
                response.raise_for_status()  # Raise an exception for HTTP errors other than the specified one
                return response.json()  # Assuming the response is JSON, adjust as needed
        except Exception as e:
            print(f"Attempt {retries + 1}/{max_retries} failed: {e}")
            retries += 1
            if retries < max_retries:
                print(f"Retrying in {delay} seconds...")
                time.sleep(delay)
                delay = min(delay * 2, max_delay)
            else:
                raise

Utiliser Retry-After

Utilisez les valeurs dans les en-têtes pour déterminer quand vous pouvez effectuer une autre requête :
  • X-RateLimit-Limit : combien de requêtes vous avez effectuées pendant la période
  • X-RateLimit-Remaining : requêtes restantes pendant la période
  • X-RateLimit-Reset : quand vous pouvez effectuer une autre requête
Notez que si vous avez des services distribués qui accèdent à la ressource, vous pouvez toujours obtenir 429, même si vous avez attendu le temps spécifié dans X-RateLimit-Reset. Si vous rencontrez ce problème, vous voudrez peut-être soit remplacer cette technique par le délai exponentiel ou les utiliser ensemble, c’est-à-dire attendre d’abord le temps donné par X-RateLimit-Reset puis revenir au délai exponentiel.