API e integraciones de PrestaShop: Webservice, ERP, Zapier y Make

Qué haríamos

Empezaríamos por la tarea manual o el fallo que puedes medir y comprobaríamos si tu integración existente ya puede resolverlo. Para un intercambio continuo, empieza con una tarea incremental programada si el negocio tolera el retraso. Elige un conector mantenido si cubre todo el flujo; encarga un proceso de trabajo o un módulo cuando las reglas de negocio que faltan justifiquen mantener código personalizado.

La vía depende de las versiones instaladas de PrestaShop y PHP, los módulos, otras integraciones, las personalizaciones del tema y del proceso de compra, la calidad de los datos, las combinaciones y la configuración multitienda. Incluye los mercados, monedas y casos fiscales que atiendes, las capacidades del sistema receptor y el equipo disponible para operarlo. Ensaya el cambio en una copia de pruebas con datos representativos y la misma configuración pertinente, aislada del correo real a clientes, los despachos de almacén y las escrituras en producción en otros sistemas. Planifica el cambio y la reversión antes de activar el proceso que escribirá en producción.

Si necesitas un conector construido con estas reglas, el PrestaShop Custom Module Development Service parte de una especificación escrita y criterios de aceptación para las conexiones acordadas.

Elige la vía más sencilla que cumpla el requisito

Elige la API y define el contrato de integración

El Webservice clásico es una función del núcleo. Ofrece acceso HTTP orientado a recursos, solicitudes XML y respuestas XML o JSON en PrestaShop 1.7.8 y 9.1. PrestaShop 9 también tiene una Admin API con OAuth2 y JSON. Estas API tienen autenticación, rutas y cobertura diferentes.

Antes de elegir, enumera las operaciones exactas que necesitas: creación de productos, correspondencias de combinaciones, actualizaciones de stock, exportación de pedidos, reembolsos, seguimiento o documentos contables. Comprueba la lista de recursos y la documentación generada de la tienda instalada. No supongas que ninguna de las dos API cubre todas las operaciones en todas las versiones. Para cada operación, registra su origen, destino, contexto de tienda, campos obligatorios, efectos de negocio esperados y respuesta de aceptación. Un conector que lee un pedido puede carecer de la operación de abono o seguimiento que necesita tu proceso.

Prioriza una API o un servicio de aplicación compatible para las escrituras habituales. El SQL directo se salta la validación de la aplicación, los hooks y otros procesos. Una migración especializada debe gestionar expresamente las asociaciones, la indexación, el stock, los archivos multimedia y la invalidación de la caché; vaciar la caché por sí solo no basta. No existe un umbral universal de tamaño del catálogo a partir del cual el SQL directo sea la opción correcta.

Esta guía empieza por el funcionamiento del Webservice y después trata el diseño del ERP y las plataformas de automatización. Consulta la documentación oficial del Webservice para conocer los detalles de la versión instalada.

Activa el acceso y comprueba el enrutamiento

1. Abre Parámetros avanzados, Webservice. Activa el Webservice.
2. Crea una clave activa independiente para cada integración.
3. Concede solo los recursos y métodos necesarios en el contexto de tienda correcto.
4. Guarda la clave en un almacén de secretos o en un archivo de credenciales protegido fuera del control de versiones.
5. Prueba el acceso por HTTPS desde el sistema que ejecutará realmente la integración.

En la autenticación HTTP Basic, la clave es el nombre de usuario y la contraseña queda vacía. El despachador también acepta ws_key en una cadena de consulta, pero evita ese método porque las URL pueden acabar en registros, historiales y analítica.

Los ejemplos utilizan un archivo privado de configuración de curl cuya ruta se guarda en WS_CURL_CONFIG. En Bash, introduce la URL base HTTPS real de la tienda, incluido cualquier subdirectorio de instalación, y la clave de la integración. El archivo temporal de credenciales se elimina al salir de esta sesión de shell. Mantén abierta la misma sesión para los ejemplos posteriores de curl.

umask 077
read -r -p 'Shop HTTPS base URL: ' SHOP_URL
read -r -s -p 'Webservice key: ' WS_KEY
printf '\n'
WS_CURL_CONFIG="$(mktemp)"
trap 'rm -f "$WS_CURL_CONFIG"' EXIT
printf 'user = "%s:"\n' "$WS_KEY" > "$WS_CURL_CONFIG"
unset WS_KEY
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/?output_format=JSON"

La ruta de la API y el despachador

/api suele ser una ruta virtual. Las reglas generadas por Apache la dirigen a webservice/dispatcher.php con un parámetro url. Esa regla de la API se genera independientemente del ajuste de URL amigables de la tienda.

En Nginx, conserva la ruta del recurso y los argumentos originales. La forma estándar de reescritura de la configuración oficial es:

rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

Para una tienda instalada en /shop/, adapta ambos lados:

rewrite ^/shop/api/?(.*)$ /shop/webservice/dispatcher.php?url=$1 last;

Estas reglas deben integrarse en un servidor correctamente configurado, con su gestión de PHP existente. Por ejemplo, /shop/api/products?limit=5 debe llegar al despachador con url=products y limit=5. Nginx añade los argumentos originales con esta forma de reescritura. Prueba la configuración efectiva del servidor y ambas rutas después de recargarla.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/webservice/dispatcher.php?url=products&limit=1"

Si el acceso directo al despachador funciona pero la ruta de la API falla, revisa la reescritura, la ruta base y el enrutamiento del proxy. Aplica restricciones por IP y límites de solicitudes tanto a la ruta amigable como al despachador real. Un archivo .htaccess en un directorio /api/ inexistente no protege el punto de acceso PHP. Comprueba las restricciones después de cualquier reescritura interna.

Descubre los recursos, los esquemas y los formatos de respuesta

La raíz de la API muestra los recursos disponibles para la clave autenticada. Los grupos habituales incluyen productos, categorías, combinaciones, atributos, clientes, direcciones, pedidos, detalles de pedidos, historiales de pedidos, transportistas y disponibilidad de stock. Las imágenes tienen sus propias rutas de gestión.

No copies una lista universal de recursos de otra versión. Por ejemplo, supply_orders aparece en la lista de recursos de PrestaShop 1.7.8 y no en la de 9.1.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,reference,active]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/products"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,id_product,id_product_attribute,quantity]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/stock_availables"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products?schema=synopsis"

Sin una selección de campos, las colecciones de recursos suelen devolver ID y enlaces. Usa campos seleccionados para listas, display=full cuando necesites todo el contexto que admite escritura, u obtén recursos individuales. Inspecciona la respuesta real antes de asignarla a otro sistema. En un editor de automatización, comprueba si la respuesta es una colección y cómo se convierte en acciones individuales en destino. Asignar solo el primer objeto devuelto puede superar una prueba de un único pedido y perder el resto de la página.

schema=blank proporciona una plantilla del recurso. schema=synopsis añade indicadores de obligatoriedad, formatos de validación, longitudes e información de solo lectura. No declara todos los filtros que acepta la API.

Los corchetes forman parte de la sintaxis de consulta del Webservice. Poner una URL entre comillas la protege del shell, pero no desactiva la expansión de patrones de URL de curl. Usa --globoff, codifica los corchetes o construye consultas con --get --data-urlencode. Consulta el manual de curl.

Filtra, ordena y pagina sin perder cambios

Para filtros de date_add o date_upd, incluye date=1. PrestaShop 1.7.8 y 9.1 eliminan esos campos de la lista de filtros permitidos si no se incluye, por lo que la solicitud puede devolver HTTP 400.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'date=1' \
  --data-urlencode 'filter[date_upd]=[2026-10-01 00:00:00,2026-10-02 00:00:00]' \
  --data-urlencode 'sort=[date_upd_ASC,id_ASC]' \
  --data-urlencode 'display=[id,reference,current_state,date_upd]' \
  --data-urlencode 'limit=0,100' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/orders"

Una consulta periódica completa de pedidos nuevos

1. Guarda de forma persistente el último ID de pedido procesado correctamente, con un valor independiente por tienda u origen.
2. Obtén los pedidos con un ID superior a ese punto de control en orden ascendente. Un intervalo acotado como filter[id]=[next_id,upper_id] puede delimitar una ejecución.
3. Pagina hasta haber procesado todos los pedidos coincidentes. Una muestra de los cinco últimos no es una consulta completa.
4. Haz que la acción en destino sea idempotente y registra el resultado correcto.
5. Avanza el punto de control solo hasta el trabajo completado correctamente, o guarda de forma duradera los elementos fallidos antes de continuar.

Para las actualizaciones de pedidos existentes, usa una ventana acotada por fecha de modificación y un criterio estable de desempate, como el ID. Mantén un solapamiento y elimina los duplicados, ya que varios registros pueden compartir marca de tiempo y los cambios simultáneos pueden mover filas entre páginas. Guarda la ventana solo cuando la hayas completado. Los registros relacionados necesitan su propia gestión de cambios: actualizar el número de seguimiento de un transportista de pedido no modifica necesariamente la marca de tiempo del pedido principal. Concilia los datos relacionados en vez de depender de una consulta limitada a los pedidos.

Elige los intervalos según la latencia medida, el ritmo de variación del stock y la carga de la API. Una tarea de catálogo cada hora y un proceso frecuente de stock tienen requisitos distintos. No existe un único intervalo óptimo para todas las tiendas.

Crea y actualiza recursos completos que admitan escritura

Usa un esquema en blanco para crear recursos, rellena los campos obligatorios y valida los ID en la tienda de destino. No des por hecho que la categoría 2, el idioma 1 o el grupo de impuestos 1 tienen el significado previsto. Para un producto, comprueba su nombre y URL amigable por idioma, categoría predeterminada, asociaciones de categorías, precio, configuración de impuestos, indicador de activación y estado de publicación.

Para un PUT, obtén el recurso, compáralo con su sinopsis, elimina los campos que no admiten escritura y conserva los campos y asociaciones obligatorios que sí la admiten. Modifica los valores previstos y envía XML con el Content-Type correcto. Un GET de producto puede contener un campo que no admite escritura, como manufacturer_name; devolver la respuesta sin cambios puede fallar.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products/42" -o product.xml

# Edit and validate product.xml, removing read-only fields first.
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --request PUT --header 'Content-Type: application/xml' \
  --data-binary @product.xml "$SHOP_URL/api/products/42"

Usa únicamente registros desechables en un entorno de pruebas para los ejemplos de escritura. En el Webservice de PrestaShop 9.1, PATCH admite actualizaciones parciales. Comprueba la versión instalada, los permisos de la clave y el recurso antes de elegirlo; PrestaShop 1.7.8 no admite PATCH.

Para un registro de stock de PrestaShop 9.1 cuyo ID hayas comprobado, un cuerpo parcial incluye el ID de su recurso:

<prestashop>
  <stock_available>
    <id>89</id>
    <quantity>100</quantity>
  </stock_available>
</prestashop>

Envíalo con PATCH a /api/stock_availables/89, no como un PUT abreviado. Si PATCH no está disponible, obtén el registro de stock con GET y conserva todos los valores obligatorios que admiten escritura para el PUT. En ambos casos, verifica el producto, la combinación y la tienda antes de escribir y vuelve a leer la cantidad después.

Comprueba los errores de transporte, el estado HTTP y el cuerpo de la respuesta de cada elemento de un lote. Reintenta los fallos transitorios de lectura con espera progresiva, un retraso máximo y un límite de intentos o tiempo transcurrido, respetando las respuestas de límite de solicitudes. Mantén recuperables los elementos que agoten los reintentos y avisa al operador. Tras una escritura de resultado incierto, concilia el resultado real antes de reintentar. Repetir a ciegas una solicitud de creación o una variación de stock puede duplicar su efecto. Conserva una correspondencia duradera entre ID externos y locales y registra los elementos sin resolver para recuperarlos.

Usa un serializador XML para escapar el texto. CDATA puede contener marcado, pero debe gestionar correctamente su propio terminador. Envía UTF-8 y un elemento raíz prestashop.

Eliminación

DELETE es destructivo y no hay una papelera de reciclaje general. Prioriza desactivar un elemento si eso satisface la necesidad del negocio. Solo para registros desechables, la eliminación masiva usa ID separados por comas, como ?id=[42,43,44], con la expansión de patrones de curl desactivada. Las barras verticales pertenecen a la sintaxis de filtros, no a esta lista de eliminación.

Gestiona imágenes, combinaciones y contexto del stock

Imágenes

La carga de imágenes usa datos multipart en lugar del XML del producto. Revisa los tipos de imagen y los límites de procesamiento de la tienda de destino.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --form 'image=@photo.jpg;type=image/jpeg' \
  "$SHOP_URL/api/images/products/42"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/images/products/42"

Una ruta para una imagen y un tipo concretos puede ser /api/images/products/42/15/large_default, si ese tipo existe. La eliminación de imágenes usa la ruta del recurso de imagen y DELETE. Prueba las dimensiones, el formato, los límites de carga, la memoria y la generación de miniaturas con archivos representativos. No existe un límite universal de fallo de 2048 píxeles o 5 MB.

Combinaciones

1. Crea o asigna el grupo de atributos, como Talla, mediante product_options.
2. Crea o asigna sus valores, como M, mediante product_option_values.
3. Crea la combinación para su producto principal y asocia los ID de valor correctos.
4. Guarda una correspondencia externa estable y una referencia única por artículo vendible.

El precio de una combinación es un impacto sobre el precio base del producto, no su precio de venta final. Si el origen proporciona un precio final de base más impacto, calcula el impacto con la moneda y la base fiscal correctas. Establece los demás valores obligatorios, como la cantidad mínima, a partir del esquema y los requisitos del negocio.

Disponibilidad de stock

Localiza stock_availables usando el ID del producto, el ID de la combinación y el contexto correcto de tienda o de tiendas con stock compartido. Los productos sin combinaciones usan un ID de atributo cero. En los productos con combinaciones, actualiza los registros de las combinaciones correspondientes; no sobrescribas el total del producto como si representara una talla o un color concretos.

Conserva los ajustes de productos sin stock y de dependencia del stock. Decide si los valores son instantáneas absolutas o variaciones, quién gestiona las reservas y cómo se contabilizan los pedidos en tránsito hacia el ERP. Una instantánea autoritativa retrasada puede sobrescribir una deducción local más reciente si ese contrato es incorrecto.

Exporta pedidos y controla los efectos sobre estados, seguimiento y correos

Lee un pedido desde /api/orders/1234 y sus filas relacionadas desde order_details filtradas por id_order. Comprueba las direcciones, monedas, totales de impuestos, descuentos, información de pago, facturas y abonos que necesita el sistema receptor.

Consulta los order_states de la tienda real. No fijes en el código los ID numéricos predeterminados habituales. Los indicadores de estado pueden afectar al stock, al procesamiento de facturas o entregas y a las notificaciones.

Para una transición deliberada del flujo, envía un registro order_history con POST. Solicita el correo expresamente con sendemail=1 si procede; también importan la configuración de correo del estado y una plantilla válida.

<prestashop>
  <order_history>
    <id_order>1234</id_order>
    <id_order_state>4</id_order_state>
  </order_history>
</prestashop>

Este es un ejemplo para un entorno de pruebas con ID ilustrativos. Su punto de acceso que solicita correo es /api/order_histories?sendemail=1. Sin ese indicador, OrderHistory::addWs() cambia el estado y guarda el historial sin solicitar por sí mismo el correo de estado. Otros módulos que escuchan los cambios de estado pueden tener efectos independientes. No cambies estados solo para reenviar un mensaje.

Los números de seguimiento se representan mediante order_carriers. Obtén el registro del transportista correcto, conserva los campos que admiten escritura y actualiza el número de seguimiento. Verifica el comportamiento resultante del correo y del enlace del transportista en tu versión; no des por hecho que todas las escrituras por API tienen los mismos efectos que todos los comandos del back office.

Creación de pedidos

El método de creación de pedidos del Webservice llama a validateOrder() del módulo de pago indicado. No se limita a saltarse la validación del pedido, el procesamiento del stock y los hooks. Necesitas un carrito válido, contexto de cliente, un módulo de pago compatible y la configuración del estado de pago del Webservice, incluido PS_OS_WS_PAYMENT.

Valida los importes, impuestos, envío, moneda, significado de los pagos y protección contra duplicados en un entorno de pruebas. Un pago importado de un marketplace no es un nuevo cargo en tarjeta. Comprueba todos los correos y efectos sobre el stock generados por la vía elegida. Usa un conector compatible o una operación de aplicación personalizada cuando necesites controlar expresamente una transacción más compleja.

Usa el cliente PHP y expón los datos del módulo de forma deliberada

El cliente PHP oficial del Webservice ofrece herramientas XML sobre las solicitudes HTTP. Elige una versión de la biblioteca compatible con tu entorno de ejecución, mantén desactivada la depuración en producción y no escribas credenciales ni respuestas completas de clientes en los registros.

composer require prestashop/prestashop-webservice-lib

Para una consulta incremental, las opciones del cliente también deben incluir el indicador de fecha. Este ejemplo supone que el cliente y las credenciales ya están inicializados:

$options = [
    'resource' => 'orders',
    'date' => 1,
    'filter[date_upd]' => '[2026-10-01 00:00:00,2026-10-02 00:00:00]',
    'display' => '[id,reference,current_state,date_upd]',
    'sort' => '[date_upd_ASC,id_ASC]',
    'limit' => '0,100',
];
$xml = $ws->get($options);

Esta es una página de una consulta acotada, no un bucle de sincronización completo. Aplica el punto de control, la paginación y la gestión de fallos descritos antes. Para actualizar stock, rechaza las búsquedas sin resultados o con resultados ambiguos antes de editar cualquier registro devuelto.

Un módulo puede exponer su propio ObjectModel mediante addWebserviceResources. Por ejemplo, un recurso de artículos puede indicar la clase Article del módulo y prohibir DELETE. Define su estructura de datos con $webserviceParameters, limita los campos expuestos y verifica los permisos y la salida de la sinopsis. La clase y su validación deben existir realmente; declarar un recurso no implementa por sí solo el modelo de negocio de un punto de acceso.

Usa la documentación sobre recursos personalizados y el código fuente oficial del cliente PHP al implementar esta capa.

Evalúa por separado la Admin API de PrestaShop 9

La Admin API usa credenciales de cliente OAuth2, autorización por ámbitos y JSON mediante una implementación Symfony/API Platform. Consulta /admin-api/docs en la instalación y la documentación de la Admin API para conocer las operaciones y los ámbitos disponibles.

La ruta del token es /admin-api/access_token. Proporciona las credenciales de cliente configuradas y los ámbitos necesarios, y usa después el token de acceso devuelto como token Bearer. Lee la caducidad en la respuesta en lugar de fijar una duración de una hora en el código. Con credenciales de cliente, solicita otro token cuando lo necesites; no des por hecho que existe un flujo de token de actualización.

Crea un cliente independiente para la integración y concédele los ámbitos documentados. No reutilices una clave del Webservice clásico ni supongas que un recurso con nombre parecido usa la misma ruta o el mismo cuerpo. Prueba todo el flujo necesario antes de elegir la Admin API o combinar ambas API.

Diagnostica las respuestas y protege ambas rutas de la API

Compara la ruta de la API con el despachador directo usando la misma clave y solicitud. Los ejemplos usan --fail de curl, que suprime los cuerpos de error HTTP: para el diagnóstico usa --fail-with-body si tu curl lo admite, inspecciona el estado y el cuerpo de la respuesta y oculta los datos sensibles antes de compartirlos. Comprueba el reenvío de la cabecera Authorization, el contexto de tienda, los permisos de método, los nombres exactos de recursos y los parámetros de consulta codificados.

Usa credenciales independientes, privilegios mínimos, HTTPS y un proceso documentado de rotación y revocación. Restringe el acceso a servidores conocidos cuando sea viable. Aplica controles adecuados de acceso y límites de solicitudes tanto al despachador como a la URL reescrita.

Registra los ID de operación, el origen, la dirección, los tiempos, el estado, los reintentos y un error útil sin datos sensibles. Usa hashes del contenido o datos de diagnóstico mínimos cuando sea posible. Nunca registres claves, cabeceras Authorization ni información personal innecesaria. Define el acceso y la conservación. Auditar la API es un control de seguridad útil, no una prescripción legal universal de registrar cada lectura de recursos.

Diseña la autoridad de los datos del ERP, los reintentos y la conciliación

Empieza por una única fuente de autoridad por campo. Una posible organización es que el ERP controle los datos de productos, precios e inventario, y que los pedidos y cambios de clientes originados en PrestaShop se envíen al exterior. Otro negocio puede usar un PIM o WMS para parte de esa función. Documéntalo expresamente en lugar de dar por hecho que el ERP siempre prevalece.

Guarda ID externos estables junto con los ID locales. Los nombres no son identificadores y las referencias pueden editarse o duplicarse si no impones su estabilidad. Asigna productos y combinaciones por separado.

Usa una clave de idempotencia que identifique el origen, la entidad, la operación y un evento o versión estable. Un reintento no debe duplicar una factura o deducción de stock, pero una actualización válida posterior debe seguir procesándose. Marca el éxito solo después de completar la operación y conserva los fallos recuperables.

Los hooks estándar de PrestaShop son eventos locales, no un servicio general duradero de webhooks salientes. Usa actionValidateOrder para el evento de creación de pedidos del módulo de pago. Usa actionOrderStatusPostUpdate para transiciones de estado explícitas con eliminación de duplicados, no como un disparador intercambiable de nuevos pedidos.

Para actionProductUpdate, algunas llamadas solo contienen id_product. Resuelve y valida un Product cuando no se proporcione un objeto e incluye el contexto correcto de tienda e idioma. Los eventos de stock necesitan identificadores de combinación y tienda. Pon la entrega en cola en vez de bloquear un guardado del back office o el proceso de compra con una solicitud HTTP remota.

Firma o autentica de otro modo los eventos salientes, usa tiempos de espera y reintentos, y diseña el sistema para entregas duplicadas o desordenadas. Concilia el stock y los pedidos periódicamente. Informa de las divergencias y aplica correcciones solo conforme a una política documentada de autoridad de datos y reservas.

Ejemplo práctico: el pedido llega al almacén, pero se pierde la respuesta

Supongamos que tu sistema de almacén controla el stock vendible y los detalles de envío, mientras PrestaShop crea el pedido del cliente. El almacén acepta pedidos para prepararlos solo en la fase de pago o aprobación que hayáis acordado. Un pedido nuevo y uno listo para preparar son eventos distintos; registra la regla de admisión en lugar de enviar todos los pedidos creados a preparación.

1. El proceso de trabajo lee un pedido admitido, resuelve sus correspondencias de combinaciones y envía la solicitud al almacén con una clave estable del pedido de origen.
2. El almacén lo acepta, pero se agota el tiempo de espera de la red antes de que el proceso reciba la referencia de aceptación. Mantén el elemento sin resolver; agotar el tiempo de espera no demuestra que el almacén lo haya rechazado.
3. Busca la clave del pedido de origen en el almacén. Si existe, guarda su referencia de aceptación. Si el receptor admite repetir el envío de forma segura con esa clave, usa ese mecanismo documentado. En caso contrario, exige una conciliación antes de volver a enviarlo.
4. Una vez registrada la aceptación, repetir el procesamiento no debe crear otra preparación. Una cancelación o modificación posterior sigue su propia operación y confirmación, en lugar de suprimirse como pedido duplicado.
5. Compara los pedidos de origen admitidos con las solicitudes aceptadas por el almacén y muestra los registros sin correspondencia. Cuando llegue el seguimiento, vincúlalo independientemente de la consulta periódica original de pedidos.

Considera ahora una instantánea de stock preparada antes de que este pedido llegara al almacén. Si aún incluye la unidad que la tienda ha descontado, aplicarla sin cambios puede volver a poner esa unidad a la venta. El acuerdo debe identificar las reservas pendientes y el orden de las instantáneas. Prueba este solapamiento con una exportación retrasada antes de permitir correcciones automáticas de stock.

No existe una URL de cron universal del núcleo. Indica el comando real o el punto de acceso compatible del módulo, su ejecutor y su alerta de fallo. Cron Manager permite gestionar tareas compatibles, como explica su ayuda; programar una tarea no crea el conector ERP ni la lógica de correspondencias o conciliación.

Decide si se justifica un ERP o una exportación más sencilla

Busca la reintroducción repetida de pedidos, el stock poco fiable, la conciliación lenta a final de mes, los múltiples canales de venta y las responsabilidades poco claras en la preparación de pedidos. Son síntomas que medir, no un umbral de volumen de pedidos o tamaño de equipo que demuestre que necesitas un ERP.

1. Registra el tiempo dedicado a volver a introducir pedidos, facturas, direcciones, stock y seguimiento durante una semana representativa.
2. Multiplica esas horas por el coste total de las personas que hacen el trabajo.
3. Registra los costes reales de corrección: devoluciones, facturas duplicadas, reembolsos, ventas por encima del stock y trabajo de conciliación.
4. Prueba si el proceso puede absorber un aumento plausible, como un 50% más de pedidos. Es un escenario de planificación, no un umbral del sector.
5. Compara la carga recurrente con los costes de implementación, licencias, alojamiento, mantenimiento, soporte y recuperación de fallos.

Prueba la exportación a contabilidad antes de comprar un ERP

Supongamos que el personal copia líneas de pedido a contabilidad y, por separado, datos de entrega a una herramienta de almacén. Prueba la exportación contable con un archivo que el contable pueda importar realmente. Si elimina la introducción contable pero mantiene la del almacén y la revisión de reembolsos, cuenta solo el trabajo que elimina. No atribuyas a la exportación ahorros que requieran una integración posterior.

Convierte los costes mensuales de errores y suscripciones al mismo periodo que el registro semanal de tiempo antes de compararlos. Si los ahorros recurrentes son positivos pero no permiten recuperar el coste de configuración en tu periodo de planificación, reduce el alcance o conserva el proceso manual repetible. Si los errores repetidos de stock dominan el coste, una exportación solo contable deja intacto el principal problema. Para asignar los documentos, usa la guía de contabilidad y facturas.

Una exportación manual de archivos que puedas repetir puede resolver un cuello de botella. Un intercambio programado necesita un sistema real y compatible que lo ejecute. No hay una frontera fija de 100 pedidos al día entre archivos, automatización y un ERP.

Orders CSV List Exporter ofrece exportaciones autenticadas desde el back office y entrega programada por correo o en el servidor; confirma las opciones de programación de la versión instalada, el ejecutor necesario y los destinatarios antes de depender de exportaciones desatendidas.

Para conocer las funciones de exportación específicas de facturas, consulta la ayuda de Invoice CSV List Exporter.

Prioriza el problema medido. Los pedidos hacia contabilidad, las actualizaciones de inventario, el seguimiento y los registros de clientes tienen correspondencias y riesgos diferentes. Asigna un responsable que supervise la integración tras el lanzamiento. Una única autoridad para el stock aporta claridad, pero no elimina por sí sola las ventas por encima del stock.

Compara Zapier, Make y una integración directa

Usa una plataforma de automatización cuando sus aplicaciones disponibles y su gestión de errores encajen con el flujo. Verifica el directorio actual de aplicaciones, las operaciones compatibles y la versión de PrestaShop en lugar de suponer que existe un conector oficial o que no puede existir porque alojas la tienda por tu cuenta. Compara también la aplicación de destino: Make puede ofrecer la operación de tienda que necesitas y Zapier admitir mejor la otra herramienta, o al revés. En Zapier un flujo es un Zap; en Make es un escenario. Prueba toda la cadena con tus datos de muestra en lugar de elegir por el número de aplicaciones.

Make ofrece una aplicación PrestaShop. No trates un módulo Watch como un webhook instantáneo sin comprobar su tipo de disparador. El acceso HTTP genérico es una alternativa cuando una aplicación no expone el recurso necesario.

Zapier contabiliza las tareas según las reglas de su plan. Make usa ahora créditos: las operaciones habituales sin IA suelen consumir un crédito, mientras que algunas funciones se contabilizan de otra forma. Compara una ejecución representativa que incluya búsquedas, bucles, comprobaciones sin resultados, reintentos y acciones posteriores. No uses antiguas tablas de precios por operación como precios actuales.

Como carga ilustrativa, 200 pedidos al día por cinco acciones por 30 días son 30.000 ejecuciones de acciones. Eso no equivale automáticamente a 30.000 unidades facturables en ninguno de los servicios; aplica las reglas de facturación vigentes. Un módulo nativo sigue teniendo costes de alojamiento, mantenimiento y posibles servicios externos.

Make publica IP de salida específicas de cada zona sin la supuesta restricción a planes de pago. Zapier documenta compatibilidad con IP estáticas en Professional y planes superiores para aplicaciones concretas, incluido Webhooks. Usa la lista vigente para la aplicación y la zona reales.

Mantén la precisión contable, las reservas de stock y las combinaciones complejas en un flujo que las implemente correctamente. Que una herramienta sea local o use un hook no garantiza una entrega instantánea, un menor coste ni disponibilidad durante una caída de otro proveedor.

Mailchimp Integration sincroniza la pertenencia a audiencias con consentimiento y reintenta las sincronizaciones de contactos fallidas, en lugar de sincronizar catálogos, segmentos o pedidos, como explica su ayuda. Comprueba la gestión de altas y bajas antes de conectar otro proceso que escriba en la audiencia; la existencia de una cuenta de cliente no es por sí sola una instrucción para suscribirla.

Crea y opera una primera automatización completa

Un primer flujo sencillo es una notificación de pedido o una fila de informe. Para probar con una hoja de cálculo, configura la autenticación Basic en los campos de credenciales de la plataforma con la clave del Webservice como usuario y la contraseña vacía, obtén los campos de pedido necesarios, procesa todos los pedidos devueltos y asigna la tienda, el ID de pedido, la referencia y el estado actual a la acción de crear fila. Aplica la lista de recuperación siguiente: que un disparador de consulta marque un elemento como visto no demuestra que su acción de destino se haya completado. Mantén el flujo en solo lectura mientras verificas las credenciales, las correspondencias de datos y la gestión de fallos. Evita exponer datos completos de clientes en un mensaje al equipo si basta con una referencia de pedido y un enlace seguro al back office.

1. Elige un disparador de consulta periódica o una programación compatibles. Schedule by Zapier documenta disparadores cada hora o con intervalos superiores; no es un disparador genérico cada 15 minutos.
2. Para una consulta periódica, comprueba Webhooks by Zapier Retrieve Poll y el intervalo compatible con tu cuenta, o implementa una consulta programada acotada.
3. Lee todos los pedidos por encima de un punto de control guardado, en orden ascendente y con paginación. Asigna campos seleccionados o recursos completos obtenidos expresamente.
4. Procesa cada pedido con una clave estable para eliminar duplicados. Guarda de forma persistente el resultado en destino y avanza el estado solo cuando la acción quede registrada de forma segura.
5. Prueba con más pedidos de los que caben en una página, un evento duplicado, un tiempo de espera agotado y una acción fallida en destino.
6. Activa las alertas de fallo y documenta el responsable del flujo, las credenciales, la programación, las correspondencias y el procedimiento de recuperación.

Para una entrega push, un módulo debe enviar el evento adecuado al Catch Hook del receptor o una URL equivalente. Instalar un receptor no hace que PrestaShop emita eventos salientes. Mantén separados los mensajes de cambio de estado y de creación de pedidos.

Para flujos que devuelven escrituras, valida el XML y usa el recurso, la combinación y la tienda correctos. Un editor de automatización basado en formularios no elimina la necesidad de entender PUT, PATCH, los impuestos o los efectos sobre los pedidos. Al pasar de los pasos de solo lectura, mantén separada la credencial de escritura y concédela solo al proceso que la necesita. Si el editor no puede conservar el recurso que admite escritura o recuperar de forma segura una escritura incierta, usa un puente mantenido o una operación de aplicación para ese paso.

Comprueba el historial de ejecución con regularidad y tras actualizar la tienda o los módulos. Prueba el correo a clientes a través del transporte previsto de la tienda o del proveedor, evitando añadir por accidente una segunda vía de confirmación de pedidos. Activa un flujo cada vez en producción, con una forma clara de detenerlo y repetir el trabajo de forma segura. Conserva una respuesta de muestra correcta y el resultado esperado en destino para comprobar regresiones tras actualizar. Un cambio en la estructura de un campo o una asignación vacía puede mantener correcta la solicitud HTTP y generar un registro incompleto en destino. Para comprobar el transporte de correo, consulta la guía de configuración del correo.

Qué preguntar a tu desarrollador o agencia

Entrega al responsable de implementación registros de muestra de la tienda y del sistema receptor, una descripción del proceso manual actual y el resultado que debe ver el personal. Incluye casos difíciles de tus propios datos: combinaciones, descuentos, distintos tratamientos fiscales, reembolsos, direcciones editadas y preparación dividida cuando se use. Pide una respuesta escrita a estas preguntas antes de aceptar el alcance del desarrollo.

• ¿Qué encaja ya? ¿Qué conector instalado, exportación nativa u operación de API compatible se puede reutilizar y qué requisito exacto necesita desarrollo?
• ¿Cuáles son las correspondencias? ¿Qué campos de origen se convierten en qué campos de destino, con qué moneda, base fiscal, redondeo, idioma y contexto de tienda? ¿Quién aprueba una coincidencia rechazada o ambigua?
• ¿Cuándo se admite el trabajo? ¿Qué evento de pago o pedido autoriza la exportación, qué cuenta como aceptación y cómo se representan las modificaciones, devoluciones y cancelaciones posteriores?
• ¿Qué plazo de entrega se garantiza? Especifica un retraso aceptable de principio a fin, la carga esperada, el trabajo acumulado durante una caída y el objetivo de recuperación. Mide la finalización en destino, no solo la programación de consultas.
• ¿Cómo funciona el soporte? ¿Quién se responsabiliza de las credenciales, el código, las correspondencias y el alojamiento, quién responde a fallos y quién repite las pruebas tras actualizar la tienda, un módulo o la API receptora? Incluye en la entrega acceso al código fuente, instrucciones y registros de recuperación.

Acuerda las pruebas de aceptación

Ensaya el cambio y planifica el paso a producción

1. Prepara la copia aislada. Sustituye las claves y URL receptoras copiadas de producción, desactiva los emisores programados reales y dirige el correo a un destino de prueba. Comprueba todas las vías de salida, incluidos los módulos existentes, antes de crear pedidos de ensayo.
2. Establece la referencia. Registra las versiones, los ajustes, las correspondencias, el progreso actual de la integración y resultados representativos de stock y pedidos. Demuestra que se pueden restaurar las copias de seguridad pertinentes y guarda la configuración necesaria para volver a la vía anterior.
3. Ejecuta los casos de aceptación. Usa registros desechables del entorno de pruebas y cuentas de prueba en el receptor. Incluye tu proceso de compra real, los módulos de pago y las acciones del personal para que los eventos y efectos secundarios procedan de la vía que usarás en producción.
4. Fija el límite del traspaso. Si sustituyes una integración, acuerda el último elemento o intervalo completado a cargo del proceso anterior y el primero a cargo del nuevo. Transfiere los fallos pendientes y las correspondencias y evita que ambos procesos escriban los mismos campos durante el cambio.
5. Cambia en una ventana acordada. Guarda el progreso, pausa el proceso de escritura saliente, aplica la configuración revisada y activa el nuevo ejecutor. Verifica la aceptación en destino y la antigüedad de la cola, además de las respuestas HTTP correctas. Designa a quien puede detener el cambio si falla la aceptación.
6. Mantén un registro de recuperación. Conserva las solicitudes aceptadas a ambos lados del límite. La reversión puede restaurar código o ajustes, pero las facturas, preparaciones, correos y cambios de stock aceptados necesitan su propia conciliación. Reanuda el proceso de escritura anterior solo desde un límite comprobado que tenga en cuenta el trabajo ya completado.

Tras el cambio, compara el trabajo admitido en origen, los registros aceptados en destino y los fallos sin resolver del mismo periodo. Revisa el elemento sin procesar más antiguo y la última conciliación completada, no solo el último inicio programado. Acuerda quién atiende una alerta y cuándo escalarla; un programador en verde por sí solo no demuestra que el intercambio de negocio haya terminado.

Preguntas de los propietarios

¿Necesito sustituir mi ERP actual?

Primero prueba si puede recibir y devolver los datos de tu contrato mediante un conector compatible, archivos o una API. Una conexión ausente puede justificar un pequeño puente; cambiar el sistema de gestión interna necesita una justificación de negocio aparte.

¿Puedo hacerlo sin un desarrollador?

Una exportación ocasional o una notificación de solo lectura puede ser manejable con tus herramientas actuales. Antes de confiar escrituras a un editor, comprueba si puedes explicar y recuperar sus fallos. Usa el selector de vías para elegir por dónde empezar y la tabla de aceptación para valorar el resultado.

¿Cambiar el tema arreglará una integración?

Primero rastrea el campo o evento que falta. Un fallo de correspondencias de API necesita una corrección de datos. Un proceso de compra personalizado que cambia la creación de pedidos debe probarse con la integración, así que conserva el comportamiento pertinente del tema y del proceso de compra en la copia de ensayo.

¿Puedo probar enviando un pedido real al almacén?

Acuerda primero una cuenta de prueba o un procedimiento controlado con el receptor. Un pedido copiado aún puede provocar una preparación real, una factura o un mensaje al cliente si el emisor del entorno de pruebas usa credenciales de producción.

¿Desactivar el módulo deshace lo que ha enviado?

No. Usa el registro de recuperación de la lista de cambio para identificar el trabajo aceptado y coordinar cualquier cancelación o corrección necesaria con el sistema responsable antes de reanudar otro proceso de escritura.

¿Qué debo recibir en la entrega?

Las correspondencias acordadas, los casos probados, las instrucciones del ejecutor y las credenciales, los responsables de las alertas y un procedimiento demostrado de parada y recuperación. Confirma la responsabilidad y el coste de la compatibilidad futura por separado de la corrección de defectos en el alcance entregado.