Connectez votre boutique à notre API.

POST, PATCH, PUT et DELETE sur /product-listings/async acceptent les mêmes entrées, maxItems 100. HTTP 202 signifie qu’au moins une entrée a été acceptée de façon confirmée, ou que le lot était vide ; nous traitons ensuite les entrées acceptées, sans rien à interroger. Le rapport est { submissionId, acceptedCount, failures } : acceptedCount plus failures correspond aux entrées envoyées, et chaque échec comporte index, error, retryable et, lorsqu’il peut être renvoyé sans risque, sourceListingId. Si rien n’est accepté : 503 pour des envois non confirmés, réessayables ou bloqués ; sinon 500 pour les erreurs internes ; 413 lorsque seule la taille échoue ; sinon 400. L’existence de l’annonce, les enchères et l’autorisation du fournisseur sont vérifiées pendant le traitement.

Envoyez un seul en-tête Idempotency-Key : 1 à 128 caractères ASCII visibles, sans virgule. Sans en-tête, une clé est générée et renvoyée dans le rapport ; si cette réponse est perdue, la clé ne peut pas être récupérée. Après une réponse perdue ou incertaine, renvoyez exactement le même lot, inchangé et dans le même ordre, avec la même clé, entrées refusées comprises. retryable signale les échecs pour lesquels ce renvoi convient (ENQUEUE_UNCONFIRMED est peut-être déjà en file) ; les erreurs de validation et de taille ne sont pas réessayables. Corrigez les entrées invalides dans une nouvelle requête avec une nouvelle clé, sans les entrées acceptées ni incertaines. submissionId sert uniquement à la corrélation. Pour consulter vous-même les annonces, utilisez GET sur /product-listings ; les jetons délégués ont aussi besoin de product-listings:read.

POST, PATCH, PUT et DELETE sur /product-listings : maxItems 100 ; [] renvoie HTTP 200 avec []. Chaque entrée s’exécute dans sa propre transaction. En cas de succès partiel, HTTP 200 renvoie uniquement les échecs sous la forme { listingSourceId, sourceListingId, error }. Si toutes les entrées d’un lot non vide échouent, le premier échec devient une réponse application/problem+json. Ne renvoyez pas les entrées réussies.

POST exige sourceListingId, url et images ; incluez title et description localisés lorsqu’ils sont disponibles (le contrat actuel autorise leur omission ou null). Les champs vendeur et adresse ne sont pas pris en charge. availability peut être null. Le prix est { type: MONETARY, currency: EUR, amount: 420000 } en unités monétaires mineures, ou { type: ON_REQUEST } ; null n’enregistre aucun prix.

Les champs omis préservent les valeurs existantes. null efface title, description, availability, price et chaque estimation de prix. url: null, images: null et auction: null sont invalides (400 BAD_BODY_VALUE). images: [] efface les images. Le contrat du lot complet est validé avant le début des transactions.

Pour les annonces existantes, omettez title, description, availability ou les prix pour conserver, envoyez null pour effacer ou une valeur pour définir. Omettez images pour conserver, [] pour effacer ou un tableau pour remplacer ; null est invalide. Omettre url ou envoyer null la conserve ; une valeur la remplace. Les nouvelles annonces exigent sourceListingId, url et images ; title, description, availability et prix omis/null n’enregistrent aucune valeur.

Omettre auction préserve son contexte ; auction: null est invalide. Dans auction, auctionId doit identifier une vente existante du même fournisseur : omission pour conserver l’appartenance, null pour l’effacer, un ID pour la définir. Pour lotNumber, cataloguePosition et chaque champ horaire (biddingOpens, scheduledCloses, reportedClosedAt), omettez pour conserver, null pour effacer ou une valeur pour définir. Les horaires sont des instants RFC3339.

DELETE accepte un tableau de { sourceListingId } sur l’un ou l’autre chemin. Il retire les annonces, de façon réversible, en conservant leur historique ; PUT restaure une annonce retirée avant d’appliquer les données actuelles. Lisez le résultat selon votre mode : le rapport d’acceptation en asynchrone, les entrées en échec en synchrone.