Conectar un marketplace a una tienda es cuestión de una tarde. Sin embargo, gestionar la integración de PrestaShop en Etsy y eBay simultáneamente es un problema completamente distinto, ya que ahora los tres sistemas creen poseer el número de stock oficial de un SKU, cada uno utiliza su propio modelo de autenticación y cada uno aplica su propio límite de solicitudes.
El fallo que realmente se produce en producción nunca es simplemente «la llamada a la API no funcionó». Se trata de una unidad sobrevendida en eBay porque un pedido de Etsy llegó 400 ms antes. Se trata de un anuncio que sobrevivió al producto que alguien eliminó el martes pasado. Se trata de un pedido importado dos veces porque un webhook se reintentó mientras el proceso estaba en curso. Por lo tanto, la pregunta clave no es si PrestaShop puede comunicarse con eBay y Etsy (obviamente puede), sino cómo diseñar la sincronización para que se mantenga correcta una vez que la tienda esté en funcionamiento.
1.0 API de servicio web de PrestaShop frente a un módulo conector de marketplace: ¿cuándo conviene implementarlo?
La respuesta honesta depende menos de tus habilidades en PHP que de quién asume el costo de mantenimiento cuando eBay deja de dar soporte a una versión de su API.
La API del servicio web de PrestaShop es una capa CRUD genérica sobre las entidades del ObjectModel de la tienda. Se ubica en /api/ y se autentica con una clave de acceso al back-office enviada como nombre de usuario HTTP Basic con una contraseña vacía (documentación para desarrolladores de PrestaShop ). Accede a productos, combinaciones, existencias disponibles y pedidos, y no tiene conocimiento de los marketplaces. La taxonomía de Etsy, las especificaciones de los artículos de eBay, la actualización de OAuth, los ID de los listados, la política de reintentos y las medidas de idempotencia son responsabilidad del desarrollador.
| Desarrollo personalizado en la API de servicio web | Módulo conector Marketplace | |
|---|---|---|
| Tiempo hasta la primera sincronización del listado | Las semanas, la autenticación, la asignación y la gestión de colas son lo primero. | De horas a días; pantallas de mapeo incluidas |
| Actualizaciones de la API del Marketplace | Puedes consultar las notas de lanzamiento de Etsy y eBay. | Responsabilidad del proveedor, if El vendedor permanece activo |
| Control de mapeo de datos | Es posible establecer una lógica de atributos totales por marca. | Limitado por la interfaz de mapeo del módulo |
| Arquitectura de sincronización | Tu elección de cola, trabajadores, bloqueos, retroceso | Generalmente se ejecuta mediante cron; el comportamiento en tiempo real varía. |
| Manejo en condiciones de carrera | Tan bueno como tú lo construyas | A menudo, la zona más débil |
| presupuesto de límite de tarifas | Usted es el propietario de los depósitos de tokens y puede priorizarlos. | Opaco; compruebe cómo el módulo regula el flujo. |
| Depurabilidad | Tus registros, tus identificadores de correlación | Formato de registro del proveedor; el seguimiento por SKU varía. |
| Costo continuo | Tiempo de desarrollador, indefinidamente | Licencia más fricción de actualización |
| El más adecuado para | Más de 2 canales, atributos complejos, precios personalizados. | Sincronización estándar de eBay/Etsy, equipos pequeños |
En la práctica, la secuencia es más efectiva que la disyuntiva: comprar el conector para demostrar que el canal genera ingresos y, posteriormente, ampliarlo una vez que el catálogo supere su modelo de mapeo. Conectores como la integración de PrestaShop con eBay Marketplace y la integración de PrestaShop con Etsy Marketplace de Knowband existen porque esa primera capa (perfiles, mapeo de categorías, estado de los listados, importación de pedidos, flujo de estado) es el mismo trabajo en todos los proyectos. Sea cual sea la ruta que elija, los criterios que se detallan a continuación siguen siendo válidos; un módulo solo se traslada a quien los implementa.
1.1 Lo que la API de servicios web no hará por usted
Mueve registros; no ejecuta lógica de negocio. POST /api/orders omite PaymentModule::validateOrder(), por lo que las disminuciones de stock, las facturas y los correos electrónicos de estado del pedido nunca se activan. Tampoco hay una cuota de solicitudes documentada, lo que no es lo mismo que no tener límite, cada llamada a /api/ inicia el framework, por lo que su límite real son los trabajadores de PHP-FPM, y un bucle de resincronización los agota mucho antes de que se apliquen los límites de eBay. Una solución ayuda aquí: un módulo puede registrar sus propios recursos de servicio web ( conceptos de servicio web del módulo ) y exponer un único punto final marketplace_sync en lugar de ocho llamadas genéricas por producto.
2.0 Mapeo de datos: Combinaciones de PrestaShop frente a la taxonomía de Etsy y las especificaciones de los artículos de eBay
Aquí es donde los proyectos de mercado pierden semanas silenciosamente. Los tres modelos de catálogo no solo usan nombres de campos diferentes; discrepan sobre qué es un producto.
PrestaShop modela un producto como un árbol de categorías anidado, un id_category_default y combinaciones generadas a partir de grupos de atributos. eBay requiere un único categoryId hoja más las especificaciones del artículo, cuyos nombres, cardinalidad y valores permitidos se dictan por categoría y se recuperan a través de getItemAspectsForCategory de la API de taxonomía ( API de taxonomía de eBay ). Etsy requiere un taxonomy_id de su propia taxonomía de vendedor más las propiedades de ese nodo, y limita las variaciones a dos propiedades por anuncio.
Tres consecuencias se hacen sentir durante el primer lanzamiento del catálogo:
- Un producto con tres grupos de atributos: tamaño, color, acabado, no puede Puede ser un único anuncio de Etsy. O bien se fusiona una dimensión en el título o se divide el producto, de modo que un producto de PrestaShop ahora se asigna a varios ID de anuncios de Etsy.
- eBay rechaza una publicación cuando falta un aspecto requerido, por lo que debe validar la asignación por categoría. antes el impulso en lugar de descubrirlo a partir de un 400.
- Ambos mercados revisan sus taxonomías, lo que hace que un ID de categoría codificado de forma fija sea una posible causa de interrupción en el futuro.
2.1 Establezca el SKU como clave de unión en cada canal.
Antes de realizar cualquier mapeo, defina la identidad. La referencia de PrestaShop debe ser el identificador de sincronización principal, y cada combinación necesita la suya propia: TSHIRT-BLK-M, TSHIRT-BLK-L, TSHIRT-WHT-M. La API de inventario de eBay utiliza direccionamiento por SKU por diseño ( API de inventario de eBay ), por lo que una combinación con una referencia vacía no se puede sincronizar. Valide esto durante la incorporación, no en cada actualización.
2.2 Almacene el mapeo como datos y realice versiones del mismo.
Resista la tentación de escribir mapCategory() en PHP. Las asignaciones son datos comerciales que un comerciante edita, no código que usted vuelve a implementar.
-- Esquema ilustrativo para la capa de mapeo
CREAR TABLA ps_mp_category_map (
id_map INT SIN SIGNO NO NULO AUTO_INCREMENTO,
canal ENUM('etsy','ebay') NO NULO,
id_category INT UNSIGNED NOT NULL, -- Categoría de PrestaShop
nodo_remoto VARCHAR(64) NOT NULL, -- etsy taxonomy_id | ebay categoryId
aspectos_json TEXTO NULO, -- valores predeterminados de aspectos estáticos
taxonomy_rev VARCHAR(32) NULL, -- Versión del árbol de categorías de eBay
CLAVE PRIMARIA (id_map),
CLAVE ÚNICA channel_cat (canal, id_categoría)
) MOTOR=InnoDB CONJUNTO DE CARACTERES PREDETERMINADO=utf8mb4;
CREAR TABLA ps_mp_listing_link (
id_producto INT SIN SIGNO NO NULO,
id_attribute INT UNSIGNED NOT NULL DEFAULT 0, -- 0 = producto simple
canal ENUM('etsy','ebay') NO NULO,
remote_id VARCHAR(64) NOT NULL, -- listing_id | offerId
remote_sku VARCHAR(64) NO NULO,
último_enviado_en FECHA Y HORA NULO,
CLAVE PRIMARIA (id_producto, id_atributo, canal),
CLAVE ÚNICA chan_remote (canal, remote_id)
) MOTOR=InnoDB CONJUNTO DE CARACTERES PREDETERMINADO=utf8mb4;
Almacena la versión del árbol de categorías de eBay junto con la asignación. Cuando getDefaultCategoryTreeId devuelve una nueva versión, cada fila con una taxonomy_rev obsoleta necesita una nueva validación, lo que marca la diferencia entre una reasignación programada y un lunes de fallos de publicación.
3.0 Arquitectura de sincronización de inventario: webhooks, sondeo programado o ambos.
Si comparamos lo que emite realmente cada lado, la respuesta deja de ser una cuestión de gustos.
| Channel | Capacidad de empuje | Brecha de cobertura |
|---|---|---|
| PrestaShop | No hay webhooks salientes nativos; un módulo intercepta actionUpdateQuantity, actionValidateOrder, actionProductUpdate | No se activa ningún mecanismo para ediciones SQL directas ni para algunas rutas de importación. |
| Etsy | Los webhooks cubren solo cuatro eventos de pedido: order.paid, order.canceled, order.shipped, order.delivered (Webhooks de Etsy) | No se creó ningún evento de recibo y evento de cambio de inventario no |
| eBay | API de notificaciones con suscripciones a temas y destinos HTTPS (API de notificaciones de eBay) | La disponibilidad de temas varía; enumere con getTopics en lugar de asumir |
Etsy no emite ninguna señal cuando un comprador modifica la cantidad de una compra ni cuando se crea un recibo. Esta falta de comunicación obliga a implementar sondeos en el diseño, independientemente de la eficiencia de la gestión de webhooks. Por lo tanto, la regla general es usar webhooks para minimizar la latencia y sondeos para verificar la información : los webhooks priorizan la velocidad de procesamiento, mientras que una conciliación cada 5-15 minutos vuelve a leer las cantidades y los recibos recientes, corrigiendo los errores detectados. La conciliación no es una solución de último recurso que se espera que nunca se ejecute, sino que es lo que, a la larga, garantiza la corrección del sistema.
Si se utiliza un conector, la arquitectura es la misma que la de las tareas programadas (cron jobs). Un módulo instalado, licenciado y configurado correctamente sigue pareciendo defectuoso si su tarea programada nunca se ejecuta, por lo que la verificación de cron debe incluirse en la lista de comprobación de puesta en marcha, no en las notas de solución de problemas.
3.1 Nunca llame a una API de mercado durante el proceso de pago.
// Ilustrativo: gancho de módulo. Solo encolar; nunca llame a una API de mercado aquí.
función pública hookActionUpdateQuantity($params)
{
$sku = $this->resolveSku((int) $params['id_product'], (int) $params['id_product_attribute']);
si (!$sku) {
volver;
}
Db::getInstance()->insert('mp_sync_queue', [
'sku' => pSQL($sku),
'op' => 'stock.push',
'payload' => pSQL(json_encode(['quantity' => (int) $params['quantity']])),
'dedupe_key' => pSQL('stock:' . $sku), // colapsa las ráfagas
'created_at' => date('Ymd H:i:s'),
], falso, verdadero, Db::REPLACE); // REPLACE = la última intención prevalece
}
Una llamada HTTP dentro del hook agrega latencia de mercado al proceso de pago y hace que el pedido falle cuando Etsy está lento, por lo que el hook solo pone en cola. REPLACE en una clave de deduplicación por SKU convierte veinte movimientos de stock en un minuto en una llamada saliente que transporta la cantidad actual.
4.0 Condiciones de carrera cuando un mismo SKU se vende en tres canales a la vez.
Toma cuatro unidades de TSHIRT-BLK-M. Un comprador de eBay toma dos, un comprador de Etsy una, la tienda una, todo en dos segundos. Tres trabajadores se activan, cada uno lee el stock, calcula una cantidad y la envía. Dos errores independientes están al acecho.
La aritmética relativa pierde actualizaciones. Si un trabajador envía "decrementar en 2" mientras otro envía "decrementar en 1" sobre un valor que ambos leen como 4, el resultado será 2 o 3 dependiendo del orden. Siempre envíe cantidades absolutas leídas en el momento de enviar. StockAvailable::getQuantityAvailableByProduct() es la única fuente de verdad, y las cantidades del mercado son proyecciones de esta, nunca entradas para cálculos aritméticos.
Las operaciones intercaladas generan un estado final obsoleto. El trabajador A lee 2, el trabajador B lee 1 un instante después, B envía 1, luego llega la solicitud más lenta de A y escribe 2. Ahora eBay anuncia una unidad que no existe. Un bloqueo por SKU más una verificación de versión monótona es la forma más económica de garantizar el orden.
// Ejemplo ilustrativo: serializar todas las notificaciones push para un SKU en todos los canales.
$lockName = 'mp_sku_' . md5($sku);
$db = Db::getInstance();
// Bloqueo consultivo de MySQL: espera hasta 3 s, devuelve 1 al adquirirlo, 0 al expirar el tiempo de espera.
if (!(int) $db->getValue("SELECT GET_LOCK('" . pSQL($lockName) . "', 3)")) {
$this->requeue($job, 5); // Otro trabajador es propietario de este SKU; reintentar en breve
volver;
}
tratar {
$qty = (int) StockAvailable::getQuantityAvailableByProduct($idProduct, $idAttribute);
$ver = (int) $db->getValue(
'SELECT stock_version FROM ' . _DB_PREFIX_ . 'mp_sku_state WHERE sku = "' . pSQL($sku) . '"'
);
si ($job['version'] < $ver) {
return; // Ya se envió una actualización más reciente; descartar esta
}
$this->etsy->setQuantity($sku, $qty); // valor absoluto
$this->ebay->setQuantity($sku, $qty); // valor absoluto
$db->execute(
'ACTUALIZAR ' . _DB_PREFIX_ . 'mp_sku_state
ESTABLECER stock_version = stock_version + 1, synced_qty = ' . $qty . ', synced_at = AHORA()
DONDE sku = "' . pSQL($sku) . '"'
);
} finalmente {
$db->execute("SELECT RELEASE_LOCK('" . pSQL($lockName) . "')");
}
GET_LOCK tiene un alcance de sesión, por lo que abarca los procesos de PHP-FPM y cron en la misma base de datos y se libera cuando la conexión se interrumpe, algo que no ocurre con un indicador de bloqueo en una fila. En varios servidores de bases de datos, traslade el bloqueo a Redis y mantenga la columna de versión como medida de seguridad.
Sin embargo, no eliminar el riesgo residual no lo elimina. Entre el proceso de pago de Etsy y tu publicación, eBay puede vender legítimamente la misma unidad, así que mitízalo comercialmente: publica "disponible - 1" para los artículos de alta rotación y publica "0" para la última unidad inmediatamente en lugar de esperar a la siguiente conciliación.
5.0 Cómo influyen los límites de velocidad de la API de Etsy, los límites de velocidad de la API de eBay y el límite máximo de PrestaShop.
Cada presupuesto parece generoso por sí solo. Sin embargo, en una sincronización a tres bandas, se multiplican en función de la cantidad de SKU.
| Channel | Límites documentados | Señales para leer |
|---|---|---|
| Etsy | Cuotas QPS y QPD por aplicación en una ventana deslizante; el valor predeterminado documentado de una nueva aplicación es de 10 solicitudes/segundo y 10,000 por 24 horas, que se incrementan a petición (límites de tarifas de Etsy) | x-límite-por-segundo, x-restante-este-segundo, x-límite-por-día, x-restante-hoy; reintentar-después-del-enlace 429 |
| eBay | Límites diarios de llamadas por aplicación, por API y por recurso, establecidos a través de la comprobación de crecimiento de la aplicación (Límites de llamadas a la API de eBay) | API de análisis para desarrolladores getRateLimits: cuota, usado, restante, ventana de reinicio |
| PrestaShop | No hay cuota publicada; limitada por los trabajadores de PHP-FPM y el costo de arranque del framework por llamada a /api/. | Tu propia tasa 5xx y profundidad de cola FPM |
Una resincronización completa de 3,000 SKU requiere una escritura de inventario de Etsy por cada listado, una actualización de oferta de eBay por cada SKU y una lectura de PrestaShop por cada SKU. Con la tasa de consultas por segundo (QPS) predeterminada de Etsy, esto supone un consumo continuo de cinco minutos sin margen de maniobra para el proceso de sondeo de pedidos, la única tarea que nunca debe detenerse. Tres reglas mantienen el presupuesto bajo control:
- Se utiliza un depósito de tokens por canal, compartido por todos los trabajadores. Aplícalo en Redis, porque un limitador por proceso multiplica tu tasa real por el número de trabajadores.
- Priorizar las colas. Las órdenes de compra y las liquidaciones de stock tienen mayor prioridad que las actualizaciones de precios y las cargas de imágenes. El gasto en miniaturas mientras se produce una sobreventa es un error de diseño.
- Lote y diferencial. La API de inventario de eBay ofrece actualizaciones masivas de precios y cantidades, así que procese por lotes hasta el límite máximo actual por llamada, luego compare con synced_qty y detenga el gasto de la cuota para confirmar que 7 sigue siendo igual a 7.
6.0 Autenticación: API OAuth de Etsy, OAuth 2.0 de eBay y claves API de PrestaShop
Tres modelos, y solo dos de ellos caducan.
PrestaShop envía la clave de acceso como nombre de usuario HTTP Basic con una contraseña vacía. Sin caducidad, sin actualización, sin modo de fallo de actualización de token, el riesgo es el contrario, ya que una clave nunca rota a menos que se rote.
Etsy utiliza la concesión de código de autorización OAuth 2.0 con PKCE obligatorio: un code_verifier de 43 a 128 caracteres y un code_challenge S256. Los tokens de acceso tienen expires_in: 3600 y los tokens de actualización duran 90 días ( autenticación de Etsy ). Cada solicitud necesita el encabezado x-api-key y el token de portador, y el formato del token es {user_id}.{token}. Ese prefijo numérico pertenece a la credencial, y eliminarlo es un error clásico del primer día.
eBay emite tokens de acceso de usuario válidos por 7,200 segundos y tokens de actualización válidos por 47 304 000 segundos, aproximadamente dieciocho meses ( tokens OAuth de eBay ). Los tokens de aplicación protegen los datos públicos, pero cualquier operación que afecte al inventario de un vendedor requiere el token de usuario.
El fallo que realmente mata los trabajos de sincronización no es la expiración. Es que diez trabajadores detecten la expiración al mismo instante. Por lo tanto, proteja la actualización con un bloqueo de vuelo único, vuelva a comprobar el token almacenado bajo ese bloqueo y actualice con un margen de dos minutos en lugar de reaccionar ante un error 401. Conserve el token de actualización rotado en la misma escritura que el token de acceso, ya que un fallo entre dos escrituras pierde la concesión. Luego, genere alertas sobre la antigüedad de la actualización exitosa , así como sobre la actualización fallida, porque una concesión que no se ha actualizado en 24 horas es un problema incluso cuando no ha ocurrido ningún error ( mejores prácticas de OAuth de eBay ).
7.0 Sincronización de pedidos del mercado: impuestos, envío, moneda e idempotencia.
La importación de pedidos es donde los contables encuentran los errores. Un pedido de marketplace no es un pedido de PrestaShop con nombres de campos diferentes; es un documento financiero liquidado. Hay cuatro discrepancias que deben resolverse antes de escribir el importador.
Impuesto para facilitadores de mercado. Etsy y eBay recaudan y remiten el impuesto sobre las ventas o el IVA en nombre del vendedor en muchas jurisdicciones. Este impuesto se incluye en la carga útil, pero no representa ni la responsabilidad ni los ingresos del comerciante, por lo que importarlo a una regla fiscal normal aumenta el importe de la declaración del IVA. Asigne este impuesto a una regla de tipo cero y añada un campo contable independiente, y luego confirme el tratamiento con el contable del comerciante.
Envío. Los marketplaces envían un importe ya calculado según sus propios perfiles de envío. No vuelva a ejecutar las reglas de transportista de PrestaShop, ya que los totales difieren y el pedido nunca se concilia con el pago. En su lugar, cree un transportista por canal y establezca el coste a partir de la carga útil.
Moneda. La carga útil lleva su propia moneda y el pago puede llegar en una tercera. Conserve el importe del mercado, el importe en la moneda de la tienda y el tipo de cambio utilizado en la importación, ya que reutilizar el tipo de cambio actual para reimprimir una factura de hace tres meses genera un documento que no coincide con nada.
Ruta de creación. Crea el carrito y luego llama a PaymentModule::validateOrder(), la única ruta que decrementa el stock, genera la factura, establece el estado del pedido y activa los hooks de los que dependen otros módulos.
// Ejemplo ilustrativo: importación de pedidos de mercado idempotente.
$externalId = $channel . ':' . $remoteOrderId;
si (Db::getInstance()->getValue(
'SELECT id_order FROM ' . _DB_PREFIX_ . 'mp_order_link
DONDE external_id = "' . pSQL($externalId) . '"'
)) {
return; // ya importado: reintento de webhook o sondeo superpuesto
}
$cart = nuevo Cart();
$cart->id_customer = $idCustomer;
$cart->id_currency = (int) Currency::getIdByIsoCode($payload['currency']);
$cart->id_carrier = (int) Configuration::get('MP_CARRIER_' . strtoupper($channel));
$cart->id_address_delivery = $idAddress;
$cart->id_address_invoice = $idAddress;
$cart->add();
para cada ($payload['lines'] como $line) {
$cart->updateQty((int) $line['qty'], (int) $line['id_product'], (int) $line['id_attribute']);
}
$module = Module::getInstanceByName('mpsync');
$module->validateOrder(
(int) $cart->id,
(int) Configuration::get('PS_OS_PAYMENT'),
(flotante) $payload['total_paid'],
$canal . ' Mercado',
nulo
['transaction_id' => $remoteOrderId],
(int) $cart->id_moneda,
falso,
$cart->clave_segura
);
Db::getInstance()->insert('mp_order_link', [
'external_id' => pSQL($externalId),
'id_order' => (int) $module->currentOrder,
'importado_en' => date('Ymd H:i:s'),
]);
Crea un índice ÚNICO en external_id. La consulta SELECT anterior es solo una ruta rápida; el índice es la garantía, ya que dos procesos pueden superar esa comprobación en el mismo milisegundo. Luego, pagina los pedidos de eBay y los recibos de la tienda de Etsy mediante un cursor de actualización persistente en lugar de un desplazamiento fijo que cambia automáticamente.
La idempotencia se extiende a pedidos anteriores. Un envío de producto consta de cuatro llamadas: crear artículo de inventario, crear oferta, cargar imágenes y publicar. Por lo tanto, se registra el estado de cada paso según (sku, canal, paso) y se permite reanudar el reintento en lugar de reiniciarlo. Etsy también firma los webhooks con webhook-id, webhook-timestamp y webhook-signature, por lo que se eliminan los duplicados por webhook-id y se rechazan las marcas de tiempo con una diferencia superior a unos 300 segundos. Este encabezado por sí solo elimina la clase de reintento de duplicados.
8.0 Monitoreo de la sincronización del mercado de producción
Una sincronización que falla ruidosamente es una tarea de mantenimiento. Una que falla silenciosamente es una cola de reembolsos.
| Registra cada operación con | Alerta en |
|---|---|
| ID de correlación que abarca webhook → cola → llamada a la API | divergencia de acciones, local ≠ remoto para más de N minutos |
| SKU, canal, operación, cantidad absoluta enviada | Error de autenticaciónCualquier error de actualización de OAuth se pagina inmediatamente. |
| Solicitud y respuesta completas para quienes no sean de la serie 2xx; información confidencial censurada. | quema de límite de velocidad, cuota diaria restante por debajo del 20% antes de las 18:00 |
| Presupuesto restante de límite de velocidad por canal | Edad de la cola, trabajo sin procesar más antiguo de más de 5 minutos |
| Fecha de caducidad del token y marcas de tiempo de la última actualización exitosa | Brecha de ordencero pedidos de un canal en una ventana normalmente ocupada |
| Resultados de la conciliación: comprobados, reparados, sin resolver | Silencio cron, una tarea de sincronización programada que no se ha ejecutado a tiempo |
Dos métricas merecen especial atención. La antigüedad de la cola es el indicador principal, ya que aumenta antes de que los clientes detecten algún problema. El recuento de reparaciones de conciliación es la métrica de honestidad: cuando el proceso de 15 minutos sigue solucionando los mismos SKU, significa que el proceso rápido está fallando y el sondeo lo está ocultando discretamente.
Finalmente, registra la cantidad absoluta que enviaste en lugar de la diferencia. Cuando un comerciante pregunte por qué eBay mostró 3 mientras que PrestaShop mostró 1, la respuesta debe poder recuperarse simplemente a partir de la línea de registro.
9.0 Solución de problemas: cuatro fallos de sincronización del marketplace de PrestaShop que probablemente te encontrarás.
9.1 Los listados muestran cantidades obsoletas mientras que los registros muestran HTTP 200.
Comprueba la carga útil, no el código de estado. En Etsy, una actualización del inventario de un anuncio reemplaza toda la estructura del inventario, por lo que una estructura parcial puede restablecer ofertas que nunca quisiste modificar. En eBay, actualizar un artículo del inventario no es lo mismo que actualizar la oferta publicada, y la oferta incluye la cantidad vendible. Lee un SKU inmediatamente después de una actualización y compara campo por campo. En una configuración basada en conectores, sigue la misma cadena primero: ¿está el producto mapeado?, ¿tiene una referencia válida?, ¿está habilitada la tarea de sincronización?, ¿se ejecutó el cron?
9.2 Los 429 aparecen solo durante la resincronización completa nocturna.
Tu depósito de tokens es por proceso, por lo que ocho trabajadores cron se ejecutan a ocho veces la velocidad prevista. Mueve el limitador al almacenamiento compartido. Luego, cuestiona la resincronización completa, compara con `synced_qty` y envía solo los cambios, y el consumo nocturno generalmente se reduce en un orden de magnitud. Respeta `retry-after` en los errores 429 de Etsy y verifica `getRateLimits` de eBay antes de un lote grande en lugar de encontrarte con el muro a mitad de la ejecución.
9.3 El mismo pedido se importa dos veces, con horas de diferencia.
Ventanas de sondeo superpuestas más una restricción faltante. Confirme que el índice UNIQUE en external_id existe, ya que una consulta SELECT para verificar duplicados sin él genera una condición de carrera en lugar de una protección. Luego, verifique el cursor: un sondeo que solicita cada 15 minutos "pedidos actualizados en los últimos 30 minutos" ofrece cada pedido dos veces por diseño. Mantenga un límite máximo, superpóngalo deliberadamente y deje que la base de datos garantice la unicidad.
9.4 La sincronización se detiene para un canal a las 3 am sin errores.
Generalmente se trata de una pérdida de token de actualización. Un token de actualización de Etsy superó silenciosamente su período de 90 días, o una actualización simultánea rotó el token dos veces y su trabajador conservó el que no lo hizo. Primero, verifique la fecha y hora de caducidad y de la última actualización exitosa del almacén de tokens. Luego, confirme que el servicio cron del servidor o el programador externo aún esté ejecutando las tareas de sincronización; un programador detenido produce exactamente este síntoma y estos registros vacíos.
10.0 Lista de verificación de preparación para la producción en PrestaShop (venta multicanal)
Antes de dar por finalizada la integración con Etsy o eBay, revise esta lista:
- ProductosCada producto y combinación sincronizada tiene una referencia única, las categorías se asignan a nodos válidos del mercado, se completan los aspectos requeridos y las imágenes cumplen con los requisitos del mercado.
- InventarioPrestaShop es la fuente de información fidedigna, las actualizaciones contienen cantidades absolutas bloqueadas por cada SKU, las actualizaciones de stock cero se realizan de inmediato y la conciliación se ejecuta según un cronograma.
- Mis pedidosEl ID del pedido del mercado se almacena bajo una restricción única, los impuestos y los gastos de envío del facilitador se asignan deliberadamente y las importaciones se procesan a través de validateOrder().
- API y autenticaciónLas credenciales se almacenan de forma segura, la actualización se ejecuta con un margen detrás de un bloqueo de vuelo único y los límites de velocidad se comparten entre los trabajadores.
- Cron y monitorizaciónCada tarea requerida se ejecuta de forma verificable, la antigüedad de la cola y las reparaciones de conciliación son visibles, y los fallos de autenticación generan una alerta en lugar de una línea en el registro.
11.0 Por dónde empezar
Para crear una integración de mercado PrestaShop desde cero, el orden que evita retrabajos es el siguiente: integridad de SKU, mapeo de tablas, control de cantidad absoluta mediante un bloqueo por SKU, importación de pedidos con un ID externo único, conciliación y, por último, webhooks. Los webhooks son la clave de la optimización. Un bucle de sondeo correcto con bloqueos e idempotencia ya constituye un sistema fiable.
Si prefiere partir de un conector funcional y dedicar tiempo de desarrollo a las necesidades específicas de su catálogo, evalúe el módulo según esa misma lista: asignación, programación, visibilidad de errores, protección contra duplicados, conciliación y confirme sus tareas programadas antes de su lanzamiento. En cualquier caso, el objetivo no es sincronizar una sola vez, sino que siga sincronizado dentro de seis meses.
Si tiene preguntas o necesita ayuda con el rendimiento o la migración de su sitio web, nuestros expertos están aquí para ayudarle. Póngase en contacto con el equipo de Knowband en [email protected] hoy mismo para obtener plugins de comercio electrónico fiables y adaptados a sus necesidades.
