Conecte su tienda con nuestra API.

POST, PATCH, PUT y DELETE en /product-listings/async aceptan las mismas entradas, maxItems 100. HTTP 202 indica que se confirmó la aceptación de al menos una entrada, o que el lote estaba vacío; después procesamos nosotros las entradas aceptadas, sin nada que consultar. El informe es { submissionId, acceptedCount, failures }: acceptedCount más failures equivale a las entradas enviadas, y cada error incluye index, error, retryable y, cuando puede devolverse con seguridad, sourceListingId. Si no se acepta nada: 503 para envíos no confirmados, reintentables o bloqueados; si no, 500 para errores internos; 413 cuando solo falla el tamaño; en otro caso, 400. La existencia del anuncio, las subastas y la autorización del proveedor se comprueban durante el procesamiento.

Envíe una sola cabecera Idempotency-Key: de 1 a 128 caracteres ASCII visibles, sin comas. Sin ella, se genera una clave y se devuelve en el informe; si esa respuesta se pierde, la clave no se puede recuperar. Tras una respuesta perdida o incierta, reenvíe exactamente el mismo lote, sin cambios y en el mismo orden, con la misma clave, incluidas las entradas rechazadas. retryable marca los errores en los que procede ese reenvío (ENQUEUE_UNCONFIRMED puede estar ya en cola); los errores de validación y de tamaño no son reintentables. Corrija las entradas no válidas en una solicitud nueva con una clave nueva, sin las entradas aceptadas ni las inciertas. submissionId solo sirve para correlacionar. Para consultar los anuncios usted mismo, use GET en /product-listings; los tokens delegados también necesitan product-listings:read.

POST, PATCH, PUT y DELETE en /product-listings: maxItems 100; [] devuelve HTTP 200 con []. Cada entrada se ejecuta en su propia transacción. Con éxito parcial, HTTP 200 devuelve solo errores como { listingSourceId, sourceListingId, error }. Si todas las entradas de un lote no vacío fallan, el primer error se devuelve como application/problem+json. No repita las entradas correctas.

POST requiere sourceListingId, url e images; incluya title y description localizados cuando estén disponibles (el contrato actual permite omisión o null). No se admiten campos de vendedor ni dirección. availability puede ser null. El precio es { type: MONETARY, currency: EUR, amount: 420000 } en unidades monetarias menores, o { type: ON_REQUEST }; null no registra precio.

Los campos omitidos conservan los valores existentes. null borra title, description, availability, price y cada estimación de precio. url: null, images: null y auction: null son inválidos (400 BAD_BODY_VALUE). images: [] borra las imágenes. Se valida el contrato del lote completo antes de iniciar las transacciones.

En anuncios existentes, omita title, description, availability o precios para conservar, envíe null para borrar o un valor para establecer. Omita images para conservar, [] para borrar o un array para reemplazar; null es inválido. Omitir url o enviar null conserva la URL; un valor la reemplaza. Los nuevos anuncios requieren sourceListingId, url e images; title, description, availability y precios omitidos/null no registran valor.

Omitir auction conserva su contexto; auction: null es inválido. Dentro de auction, auctionId debe identificar una subasta existente del mismo proveedor: omitir conserva la pertenencia, null la borra y un ID la establece. Para lotNumber, cataloguePosition y cada campo temporal (biddingOpens, scheduledCloses, reportedClosedAt), omita para conservar, null para borrar o un valor para establecer. Los tiempos son instantes RFC3339.

DELETE acepta un array de { sourceListingId } en cualquiera de las dos rutas. Retira anuncios, algo reversible, y conserva su historial; PUT restaura un anuncio retirado antes de aplicar los datos actuales. Lea el resultado según su modo: el informe de aceptación en asíncrono, las entradas fallidas en síncrono.