Comparer les prix Vinted entre tailles et états via l'API

Pour comparer efficacement les prix de vêtements sur Vinted selon la taille et l'état, extrayez systématiquement ces données via un endpoint dédié. L'API LeBonDeal permet d'automatiser cette collecte en interrogeant des catalogues filtrés pour analyser instantanément les écarts tarifaires.

Principe technique du regroupement par attributs

L’analyse comparative des prix sur Vinted exige de structurer les données brutes extraites par l’API. La réponse JSON contient un tableau items où chaque objet représente une annonce distincte. Pour établir une comparaison pertinente, vous devez regrouper ces éléments selon deux attributs clés : la taille (size) et l’état (status). Ces champs permettent de segmenter le marché virtuel en sous-groupes homogènes.

Chaque article possède des caractéristiques uniques qui influencent directement sa valeur marchande. Une pièce « Neuf avec étiquette » ne se compare pas à un modèle identique mais « Très bon état ». De même, une taille 38 n’a aucune pertinence comparative directe avec une taille 42 sur le même article spécifique. L’objectif est donc d’isoler les variants comparables pour calculer des moyennes ou identifier des anomalies de prix.

Le processus technique suit cette logique :

• Extraire la liste complète des items renvoyés par l’endpoint Vinted.
• Itérer sur chaque élément pour lire les valeurs de size et status.
• Créer une clé composite unique, par exemple "L-Très bon état", servant d’index dans un objet temporaire.
• Agréger les prix bruts (price) associés à cette clé.

Ce regroupement initial est crucial avant toute normalisation monétaire ou statistique. Sans cette étape de segmentation, vos calculs de moyenne seraient biaisés par la diversité des offres. Vous devez également noter que le champ status peut varier légèrement selon la formulation exacte saisie par l’annonceur (ex : « Comme neuf » vs « Neuf comme neuf »). Une normalisation minimale des chaînes de caractères est souvent nécessaire pour éviter une fragmentation excessive des groupes.

Configuration de la requête API Vinted

La configuration de la requête repose sur l'envoi d'une URL catalogue Vinted déjà filtrée via le paramètre url. Vous devez construire votre filtre directement dans le navigateur, copier l'URL résultante et la transmettre à l'endpoint /api/v1/vinted/search en GET. L'en-tête Authorization: Bearer YOUR_API_KEY est obligatoire pour authentifier chaque appel sans exposer vos identifiants côté client.

import os
import requests

BASE_URL = os.environ.get("LEBONDEAL_BASE_URL", "https://bot.lebondeal-bot.fr")
API_KEY = os.environ["LEBONDEAL_API_KEY"]
VINTED_FILTER_URL = "https://www.vinted.fr/catalog?search_text=..." 

endpoint = f"{BASE_URL}/api/v1/vinted/search"
headers = {"Authorization": f"Bearer {API_KEY}"}
params = {"url": VINTED_FILTER_URL}

try:
    response = requests.get(endpoint, headers=headers, params=params, timeout=45)
    
    if response.status_code == 200:
        data = response.json()
        items = data.get("items", [])
        for item in items:
            print(f"{item['title']} - {item['price']}")
            
    elif response.status_code == 429:
        import time
        time.sleep(5) # Backoff simple pour la démonstration
        
    else:
        err = response.json()
        if "error" in err:
            print(f"Erreur API : {err['message']}")

except requests.exceptions.Timeout:
    print("Timeout dépassé (40s max serveur). Réessayez.")

Ce script initialise les variables d'environnement pour sécuriser la clé et construit l'URL complète en concaténant BASE_URL avec le chemin de l'endpoint. Il effectue une requête GET avec un timeout explicite de 45 secondes, nécessaire car des incidents temporaires peuvent prolonger le temps de réponse côté serveur. La gestion des erreurs capture spécifiquement les timeouts et traite différemment les succès (200) des limitations de débit (429). Pour plus de détails sur la syntaxe exacte des filtres Vinted, consultez notre documentation Vinted.

Traitement des prix et conversion monétaire

Les données retournées par l'endpoint /api/v1/vinted/search ne contiennent pas de valeurs numériques brutes pour les montants. Chaque champ price est une chaîne de caractères formatée, incluant la devise à droite du montant (par exemple "15.0 EUR"). Cette structure impose un prétraitement systématique avant toute opération statistique ou comparaison entre différentes tailles et états d'un même article.

Pour extraire le prix effectif, vous devez isoler les caractères numériques décimaux de la chaîne initiale. Une approche robuste consiste à utiliser une expression régulière pour identifier le motif numérique, puis à convertir explicitement le résultat en type flottant ou entier selon votre besoin de précision. Ignorer cette étape entraînerait des erreurs de calcul lors du regroupement par attributs (size, status).

Lors du traitement par lots pour comparer les prix entre tailles :

• Analysez chaque élément de la liste items retournée.
• Extrayez le nombre décimal via regex (\d+\.\d+).
• Convertissez-le en float.
• Agrégez ces valeurs par clé composite (size, status).

Ce prétraitement est indispensable pour garantir l'intégrité des analyses de prix. Sans conversion explicite, les comparaisons directes sur la chaîne brute sont invalides car elles dépendent du formatage initial et ne permettent pas d'opérations arithmétiques fiables. Pour plus de détails sur la structure exacte de la réponse JSON, consultez la documentation officielle disponible sur la page API Vinted.

Gestion des erreurs et limites du service

Lors de l'intégration de la requête Vinted, vous devez anticiper plusieurs scénarios d'échec qui interrompent le flux normal des données. Le tableau ci-dessous récapitule les codes HTTP retournés et leur signification technique pour votre logique de reprise.

L'anomalie majeure à gérer est l'ambiguïté du code 503. Contrairement à d'autres services, une recherche Vinted techniquement échouée après plusieurs tentatives internes renvoie le même statut qu'une page de résultats vide (aucune annonce ne correspond aux filtres). Dans les deux cas, vous recevrez un JSON avec error: "unexpected_error", count: 0 et credits_charged: 0. Votre algorithme doit donc traiter ces deux scénarios comme l'absence de données pertinentes pour la requête courante, plutôt que comme un incident système nécessitant une alerte critique. Pour les limites de débit (429), privilégiez des délais croissants entre vos appels afin d'éviter d'être temporairement bloqué par le serveur.

Intégration dans un workflow de veille

L'exécution régulière de ce script permet de maintenir une base de référence des prix du marché sans intervention manuelle. Pour automatiser cette veille, vous devez structurer votre boucle d'appels en respectant les contraintes de débit et la nature éphémère des listings. Il est recommandé d'implémenter un mécanisme de backoff exponentiel lors de la réception d'une erreur 429 rate_limited. Cela évite de saturer le serveur et préserve votre solde de crédits, comme détaillé sur la documentation Vinted.

La persistance des données est cruciale pour comparer les évolutions temporelles. Stockez chaque réponse normalisée dans une base locale ou un fichier CSV avec un horodatage précis. Cela vous permettra de calculer des moyennes mobiles par taille et par état, plutôt que de vous fier à un instantané unique qui peut être biaisé par la rareté d'un article spécifique.

Pour optimiser la consommation de ressources :

• Regroupez vos requêtes par famille d'articles similaires pour limiter le nombre d'appels distincts.
• Vérifiez systématiquement credits_remaining avant chaque lot important afin d'éviter une interruption brutale due à un solde insuffisant.
• Utilisez des filtres larges au départ, puis affinez uniquement si le volume de résultats est trop élevé pour être traité efficacement en temps réel.

Cette approche permet de construire un modèle prédictif fiable sur la dépréciation ou l'appréciation d'un produit selon ses attributs physiques, transformant ainsi une simple extraction de données en un outil décisionnel stratégique.

FAQ

Articles liés