Historial de Seller Platform

Fotos de las tiendas de importación WooCommerce

• Las tres operaciones de fotos del plugin aceptan la credencial de descubrimiento de una tienda de importación: el listado de fotos pendientes pide discovery.read, y la subida y el registro de fotos piden discovery.write. Una tienda con fuentes de sincronización guardadas sigue necesitando sync.write.

Fotos en la guía de WooCommerce

Pedidos de Moku en tiendas de importación WooCommerce

• Nuevas operaciones WooCommerce orders para el plugin emparejado: listar y leer los pedidos que Moku debe entregar a la instalación, tomar uno, aceptarlo con la prueba de que descontó el stock de cada línea, rechazarlo con un motivo e informar si se despachó o se canceló en WooCommerce.
• Usan los scopes deliveries.read y deliveries.write. Solo los recibe la credencial emparejada de una tienda de importación, con el consentimiento del dueño de la tienda; los tokens personales no los incluyen.
• Desde el 31 de octubre, POST …/woocommerce/delivery-runtime permite al plugin informar la salud de su consulta de pedidos.

Pedidos de Moku en tu tienda WooCommerce

Borrado de los datos de contacto de un pedido

• Los pedidos y los pedidos externos traen el campo obligatorio contact_erased_at. Moku borra la dirección de entrega, y en un pedido externo también el correo, 12 meses después de la última actividad del pedido.
• Este cambio fue incompatible dentro de v1: desde ese momento delivery_address es null, aunque Moku despache el pedido. Lee contact_erased_at antes de suponer que un pedido tiene dirección.

Pedidos y fulfillment

Eventos en un orden completo por tienda

• GET /events recorre todos los eventos confirmados de la tienda en un solo orden de llegada. Continuar desde el cursor nunca salta un evento, aunque se haya confirmado tarde.
• page.next_cursor viene en todas las respuestas, también en las vacías. page.has_more indica si debes pedir la página siguiente ahora o volver a consultar más tarde.
• occurred_after filtra ese orden sin cambiarlo, y el cursor queda ligado al filtro. No uses occurred_at ni el ID del evento como marca de lectura.

Leer eventos sin perder ninguno

Errores por campo, imágenes propias y categorías para publicar

• INVALID_REQUEST puede incluir errors: una lista con pointer (JSON Pointer al campo), code y detail. Hoy contiene la primera infracción encontrada; los clientes que solo leen code y detail pueden ignorarla.
• image_urls acepta solo imágenes que la tienda subió con PUT /vendors/{vendor_id}/media/{sha256}, usando la URL que devuelve. Cualquier otra URL, incluso una que no cambió, se rechaza con el código de campo media.
• Publicar exige una categoría canónica: category es una raíz existente, como shopify-aa, distinta de shopify-na, y subcategory es esa raíz o una categoría bajo ella. Los borradores pueden quedar sin clasificar.
• En los lotes, unknown significa que el ajuste empezó y su resultado no quedó registrado; not_attempted, que nunca empezó. Los registros pendientes de un lote detenido usan BACKGROUND_WORK_FAILED o BULK_OPERATION_STOPPED.

Errores y reintentos · Imágenes de producto

Moku genera las URLs y etiquetas de producto

• Crear o editar un producto ya no acepta slug ni badge. Moku genera el slug al crear el producto y no lo cambia al editarlo; la etiqueta de oferta o novedad se calcula al leer.
• Este cambio fue incompatible dentro de v1: una solicitud que todavía envía esos campos responde INVALID_REQUEST. Quítalos de tus solicitudes y sigue leyéndolos en las respuestas.

Precios por canal y operaciones del conector

• Tres operaciones nuevas leen la política de precios de una conexión y de cada publicación, y registran el precio observado en el canal. Guardar una política nunca autoriza escrituras remotas.
• Las operaciones del conector de WooCommerce y de efectos de stock usan los scopes sync.* y discovery.*. No forman parte de los tokens generales de lectura o escritura: las usa la credencial de conexión que emite Canales.

Roles por dominio en vez de perfiles

• Cada conexión declara un rol source o destination por dominio. Un rol de fuente reclama la Autoridad; uno de destino nunca la reclama.
• GET /authority devuelve quién administra catálogo y precio de referencia, y la Autoridad de inventario de cada Stock Pool. El origen y el fulfillment de un pedido quedan guardados en el pedido.

Fuente de verdad y conexiones

Stock por lotes y ubicación predeterminada

• La API pública incorpora operaciones por lotes de 1 a 25 ajustes de inventario, con un resultado independiente por registro.
• La respuesta 202 confirma aceptación, no ajustes aplicados. Consulta el ID devuelto con GET; bulk_operation.completed avisa que debes volver a leer el resultado.
• Ante un resultado unknown, reconcilia el inventario antes de emitir otro ajuste. Un fallo del lote no revierte los registros exitosos.
• Los items devuelven location_id: default, una ubicación virtual por vendedor. Los IDs existentes no cambian y no se crean bodegas físicas.

Guía de operaciones por lotes · Ubicación predeterminada de inventario

Contrato v1 completo para piloto

• Conexiones y tres perfiles de autoridad.
• Listings, reservas y pedidos externos.
• Fulfillment, cancelación terminal y protección de información de entrega.
• Eventos, webhooks firmados, reproducción asíncrona con seguimiento y reconciliación.
• 20 scopes y 56 operaciones documentadas.

Catálogo e inventario

• Productos versionados y transiciones explícitas.
• Ajustes de stock idempotentes y disponibilidad calculada.
• PAT con vencimiento, request IDs y rate limiting.