Colleghi il suo negozio alla nostra API.

POST, PATCH, PUT e DELETE su /product-listings/async accettano le stesse voci, maxItems 100. HTTP 202 indica che almeno una voce è stata accettata con conferma, oppure che il batch era vuoto; le voci accettate le elaboriamo poi noi, senza nulla da interrogare. Il rapporto è { submissionId, acceptedCount, failures }: acceptedCount più failures corrisponde alle voci inviate, e ogni errore contiene index, error, retryable e, quando può essere restituito in sicurezza, sourceListingId. Se non viene accettato nulla: 503 per invii non confermati, ripetibili o bloccati; altrimenti 500 per errori interni; 413 quando fallisce solo la dimensione; altrimenti 400. L’esistenza dell’annuncio, le aste e l’autorizzazione del fornitore vengono verificate durante l’elaborazione.

Invii un solo header Idempotency-Key: da 1 a 128 caratteri ASCII visibili, senza virgole. Senza header viene generata una chiave restituita nel rapporto; se quella risposta va persa, la chiave non può essere recuperata. Dopo una risposta persa o incerta, reinvii esattamente lo stesso batch, invariato e nello stesso ordine, con la stessa chiave, comprese le voci rifiutate. retryable segnala gli errori per cui questo reinvio è appropriato (ENQUEUE_UNCONFIRMED potrebbe essere già in coda); gli errori di validazione e di dimensione non sono ripetibili. Corregga le voci non valide in una nuova richiesta con una nuova chiave, escludendo le voci accettate e quelle incerte. submissionId serve solo alla correlazione. Per consultare lei stesso gli annunci, usi GET su /product-listings; i token delegati richiedono anche product-listings:read.

POST, PATCH, PUT e DELETE su /product-listings: maxItems 100; [] restituisce HTTP 200 con []. Ogni voce viene eseguita nella propria transazione. In caso di successo parziale, HTTP 200 restituisce solo gli errori come { listingSourceId, sourceListingId, error }. Se tutte le voci di un batch non vuoto falliscono, il primo errore diventa una risposta application/problem+json. Non ripeta le voci riuscite.

POST richiede sourceListingId, url e images; includa title e description localizzati quando disponibili (il contratto attuale consente omissione o null). I campi venditore e indirizzo non sono supportati. availability può essere null. Il prezzo è { type: MONETARY, currency: EUR, amount: 420000 } in unità monetarie minori, oppure { type: ON_REQUEST }; null non registra un prezzo.

I campi omessi conservano i valori esistenti. null cancella title, description, availability, price e ogni stima di prezzo. url: null, images: null e auction: null non sono validi (400 BAD_BODY_VALUE). images: [] cancella le immagini. Il contratto dell’intero batch viene validato prima delle transazioni.

Per gli annunci esistenti, ometta title, description, availability o prezzi per conservare, invii null per cancellare o un valore per impostare. Ometta images per conservare, [] per cancellare o un array per sostituire; null non è valido. Omettere url o inviare null conserva l’URL; un valore lo sostituisce. I nuovi annunci richiedono sourceListingId, url e images; title, description, availability e prezzi omessi/null non registrano un valore.

Omettere auction conserva il contesto; auction: null non è valido. All’interno di auction, auctionId deve identificare un’asta esistente dello stesso fornitore: omissione per conservare l’associazione, null per cancellarla, un ID per impostarla. Per lotNumber, cataloguePosition e ogni campo temporale (biddingOpens, scheduledCloses, reportedClosedAt), ometta per conservare, null per cancellare o un valore per impostare. Gli orari sono istanti RFC3339.

DELETE accetta un array di { sourceListingId } su entrambi i percorsi. Ritira gli annunci, in modo reversibile, conservandone la cronologia; PUT ripristina un annuncio ritirato prima di applicare i dati attuali. Legga l’esito secondo la sua modalità: il rapporto di accettazione in asincrono, le voci non riuscite in sincrono.