PrestaShop y Zapier: automatiza flujos de trabajo sin escribir código

Última revisión: junio de 2026. El directorio de Zapier y la compatibilidad de PrestaShop con JSON cambian con el tiempo, verifica ambos para tu versión antes de descartar cualquier opción. Rutas del back office verificadas en PrestaShop 1.6, 1.7, 8.x y 9.x.

"Sin escribir código" es la promesa que atrae a la mayoría de los comerciantes a Zapier, y, en líneas generales, es cierta, pero hay un dato sobre PrestaShop que nadie te cuenta al principio: en el momento de escribir este artículo, no existe una aplicación mantenida por PrestaShop en el directorio de Zapier. Busca "PrestaShop" en Zapier y no encontrarás el conector limpio, al estilo Shopify, que quizá esperabas (comprueba el directorio de Zapier por si existen opciones actuales de terceros antes de descartarlo). Eso no significa que la vía sin código esté cerrada. Significa que la vía directa sin código suele pasar por la API Webservice integrada de PrestaShop y el paso genérico Webhooks de Zapier, con módulos conectores de terceros o middleware como alternativa. Entender exactamente cómo encajan esas dos piezas es la clave. Esta guía recorre el cableado real sin código en un back office de PrestaShop, donde de verdad no hace falta escribir ni una línea, y señala los dos o tres puntos en los que alguien te entrega discretamente un fragmento y lo llama "sin código" de todos modos.

Si todavía estás decidiendo qué plataforma estandarizar, o quieres ver el catálogo amplio de operaciones de tienda que merece la pena automatizar, empieza por nuestro artículo complementario, Zapier y Make para PrestaShop, y vuelve aquí para la mecánica práctica de conexión.

Por qué no hay una "app de PrestaShop", y por qué no pasa nada

Las plataformas alojadas como Shopify publican y mantienen una aplicación de Zapier porque hay una empresa que controla una única base de código. PrestaShop es autoalojado y de código abierto: tu tienda vive en tu servidor, en tu versión (1.6, 1.7, 8.x, 9.x), con tus módulos. No hay una entidad central que publique y certifique un único conector para todo ese abanico. Así que, en lugar de una app con marca propia, PrestaShop expone una API Webservice, una interfaz REST estándar integrada en el núcleo, y Zapier habla con ella igual que habla con cualquier API personalizada: mediante pasos genéricos de Webhooks by Zapier. Una vez aceptas eso, el problema de "no hay app nativa" se convierte en una configuración de quince minutos, no en un callejón sin salida.

Paso 1, activa el Webservice (realmente sin código)

Esta es la base y se hace solo con clics en el back office:

• Ve a Parámetros avanzados → Servicio web (en PrestaShop 1.6 está en Parámetros avanzados → Servicio web).
• Cambia Activar el servicio web de PrestaShop a Sí y guarda.
• Haz clic en Añadir una nueva clave de servicio web. PrestaShop genera una clave larga y aleatoria. Esta es la credencial que usará Zapier, así que trátala como una contraseña.
• En la tabla de permisos, concede solo los recursos que realmente necesitas. Para leer pedidos, marca orders (y normalmente customers, addresses) en Ver (GET). Para escribir de vuelta, por ejemplo, actualizar stock, marca stock_availables en Modificar (PUT). Deja todo lo demás desactivado.

¿Qué consigues con esto? Una clave limitada que puede hacer exactamente una tarea y nada más. Si esa clave se filtra alguna vez, el alcance del daño será lo que hayas marcado, no toda tu base de datos. Una trampa real que suele afectar a alojamientos compartidos o antiguos: el Webservice necesita que la reescritura de URL funcione. Si lo activas y las llamadas devuelven 404, comprueba que Parámetros de la tienda → Tráfico & SEO → URL amigable esté activado y que tu servidor realmente reescriba URLs; algunas configuraciones de Apache necesitan mod_rewrite habilitado y las reglas de reescritura generadas por PrestaShop en .htaccess (las reglas que enrutan /api al dispatcher del Webservice). Eso es una configuración del servidor, no código que tengas que escribir.

Paso 2, elige la dirección: de la tienda a Zapier o de Zapier a la tienda

Cada automatización funciona en una de dos direcciones, y PrestaShop las gestiona de formas muy distintas. Entender bien esta diferencia es lo que separa una configuración que funciona de una que pierde pedidos en silencio.

Paso 3, la dirección del disparador (donde el "tiempo real" esconde una condición)

Quieres un Zap que se ejecute cuando entra un nuevo pedido. Hay dos formas honestas de hacerlo, y se sienten muy distintas.

La vía puramente sin código: consulta programada

Usa un disparador de Schedule by Zapier (por ejemplo, cada 15 minutos) seguido de un paso Webhooks by Zapier → GET que llame al endpoint de pedidos:

• URL: https://yourstore.com/api/orders?display=full&sort=[id_DESC]&limit=5&output_format=JSON
• Autenticación: Basic Auth, usuario = tu clave del Webservice, contraseña = en blanco.

El parámetro display=full importa tanto como el resto de la URL: sin él, el Webservice devuelve solo referencias a recursos (una lista de ID), no los campos del pedido que quieres mapear, así que añades display=full o haces una consulta en dos pasos (listar ID y luego hacer GET de cada pedido por id). El parámetro output_format=JSON es la otra pieza clave, por defecto, el Webservice devuelve XML, y la salida JSON depende de que tu versión de PrestaShop la admita, así que confirma que tu tienda realmente la respeta. Este tipo de consulta programada también necesita lógica de deduplicación: guarda el último id o la última fecha de pedido vistos y actúa solo sobre filas más recientes; de lo contrario, reprocesarás los mismos pedidos en cada ejecución o perderás un pico que llegue entre consultas. La otra contrapartida: la consulta programada no es instantánea (esperas hasta el siguiente intervalo) y consume una tarea en cada ejecución, haya o no un pedido nuevo. Para la mayoría de tiendas pequeñas y medianas, es un precio razonable por no depender de un desarrollador. Esta es la ruta que recomendamos para empezar.

La vía en tiempo real: un webhook desde tu tienda

Si de verdad necesitas que un pedido llegue a Zapier en el mismo instante en que se realiza, la tienda tiene que enviar. El núcleo de PrestaShop no envía webhooks salientes por sí solo, así que esto implica instalar un módulo de webhooks que lance un HTTP POST en eventos como la creación de pedido (internamente enganchándose a actionValidateOrder o actionOrderStatusPostUpdate) hacia una URL de Catch Hook que te da Zapier. La buena noticia: un módulo de webhooks bien construido se configura por completo desde el back office, pegas la URL de captura de Zapier en un campo y eliges qué eventos enviar. Sin código. La advertencia honesta: ahora dependes de que un módulo sea compatible con cada versión de PrestaShop y PHP que uses, justo el tipo de dolor de cabeza de compatibilidad del que nos ocupamos para que tú no tengas que hacerlo.

Paso 4, la dirección de la acción (el asterisco de "sin código")

Escribir de vuelta en PrestaShop es donde la promesa sin código recibe su asterisco. El Webservice acepta cambios como XML, no como los cómodos campos de formulario que Zapier muestra para las apps nativas. Para actualizar el stock de un producto, el flujo correcto es: hacer GET de la fila exacta de stock_available para ese producto (coincidiendo con el id_product_attribute adecuado para combinaciones y con el contexto de tienda correcto en multitienda), cambiar el valor de <quantity> y luego hacer PUT de todo el bloque XML de vuelta, conservando todos los campos obligatorios. Es fácil estropearlo: PUT sustituye el recurso completo, así que eliminar o no hacer coincidir un campo, el id de la combinación, el id de la tienda, una dependencia. Puede escribir el stock incorrecto o romper la fila. Pruébalo siempre en una copia de staging antes de apuntarlo a tu tienda en producción. En un paso de Webhooks by Zapier estás pegando una plantilla XML e insertando campos mapeados dentro. No es programación. No hay bucles, variables ni lógica, pero es más que arrastrar bloques, y una guía honesta debe decirlo en lugar de fingir que todo es hacer clic.

El cuerpo XML para ese PUT de stock, conservando los campos que PrestaShop espera, tiene este aspecto, observa que primero haces GET de la fila para conocer los ids reales y luego cambias solo <quantity>:

<?xml version="1.0" encoding="UTF-8"?>
<prestashop xmlns:xlink="http://www.w3.org/1999/xlink">
  <stock_available>
    <id>42</id>
    <id_product>15</id_product>
    <id_product_attribute>0</id_product_attribute>
    <id_shop>1</id_shop>
    <id_shop_group>0</id_shop_group>
    <depends_on_stock>0</depends_on_stock>
    <out_of_stock>2</out_of_stock>
    <quantity>37</quantity>
  </stock_available>
</prestashop>

¿Y esto en qué te afecta? Para automatizaciones de lectura y notificación (nuevo pedido → Slack, nuevo cliente → hoja de cálculo), probablemente nunca tocarás XML. Para automatizaciones que escriben de vuelta (sincronizar stock, cambiar el estado de un pedido, crear un cliente), reserva una tarde para dejar correcta la primera carga útil, después la copiarás para cada Zap parecido.

Las opciones de conexión, ordenadas por lo poco que tienes que tocar

Los límites de los que Zapier no te avisará

La automatización sin código es la herramienta adecuada para muchísimos trabajos, y la herramienta equivocada para unos cuantos. Conocer el límite antes de chocarte con él te ahorra una migración dolorosa más adelante:

• Volumen. Zapier cobra por tarea. Una tienda con 30 pedidos al día repartidos entre cuatro automatizaciones funciona sin problema; una con miles de pedidos diarios verá cómo la factura sube rápido, llegado ese punto, una integración directa o una integración ERP cuando tu tienda supere el trabajo manual sale más barata por transacción.
• Sincronización bidireccional de gran volumen. Mantener stock, precios y pedidos en concordancia constante en ambos sentidos entre PrestaShop y otro sistema grande no es para lo que sirve Zapier, consulta los patrones que de verdad aguantan en patrones de integración ERP que funcionan.
• Precisión contable. Puedes enviar pedidos a un software de contabilidad mediante Zapier, pero las reglas fiscales, los abonos y los reembolsos se vuelven delicados enseguida; normalmente tiene más sentido un puente específico, como explicamos en conectar PrestaShop con tu software de contabilidad.
• Correo electrónico transaccional. No envíes confirmaciones de pedido a través de un Zap, eso pertenece al propio sistema de correo de PrestaShop, configurado correctamente. Consulta configuración de correo electrónico en PrestaShop.

Tres hábitos que evitan que las automatizaciones sin código te den problemas

• Limita la clave y luego olvídate de ella. La mayor mejora de seguridad es la tabla de permisos del Paso 1, concede lo mínimo, y una clave filtrada apenas podrá hacer nada.
• Prueba primero con un pedido desechable. Haz un pedido de prueba real y observa cómo se ejecuta todo el Zap de principio a fin antes de confiar en él. Una automatización silenciosa que se salta uno de cada tres pedidos es peor que no automatizar, porque dejas de revisar. (Si mientras tanto desaparece la confirmación de un pedido de prueba, eso es un problema de entrega de correo, no de Zapier. Resend Order Confirmation te permite relanzarla desde el pedido mientras corriges la causa.)
• Vigila el historial de tareas durante una semana. Zapier registra cada ejecución; un Zap que escribe de vuelta y empieza a fallar porque PrestaShop devolvió un error XML se quedará ahí sin hacer ruido. Cinco minutos el lunes bastan para detectarlo.

Preguntas frecuentes

¿De verdad no hay una app de PrestaShop en Zapier?

En el momento de escribir este artículo, no existe ninguna app mantenida por PrestaShop en el directorio de Zapier, porque PrestaShop es autoalojado, con muchas versiones y módulos, y no hay una única entidad que publique y certifique una. En su lugar, te conectas mediante la API Webservice integrada de PrestaShop y los pasos genéricos Webhooks by Zapier. Comprueba el directorio por si existen conectores actuales de terceros antes de descartarlos, pero la vía del Webservice es el camino sin código más fiable.

¿Conectar PrestaShop con Zapier es realmente "sin código"?

Para leer y notificar, nuevo pedido a Slack, nuevo cliente a una hoja de cálculo, sí, todo se hace con clics: activas el Webservice, limitas una clave y consultas con un GET de Webhooks. Para escribir de vuelta en tu tienda (actualizar stock, cambiar el estado de un pedido), te encontrarás con un poco de XML, porque el Webservice acepta cambios como cuerpo XML en lugar de campos de formulario. No hay bucles ni lógica, pero es más que arrastrar bloques, y conviene saberlo desde el principio.

¿Cómo llevo los pedidos de PrestaShop a Zapier en tiempo real?

La consulta programada no puede ser realmente instantánea, revisa según el intervalo que definas (por ejemplo, cada 15 minutos). Para tiempo real necesitas que la tienda envíe: un módulo de webhooks que lance un HTTP POST al crear un pedido (enganchándose a actionValidateOrder) hacia una URL de Zapier Catch Hook. El núcleo de PrestaShop no incluye un emisor de webhooks salientes, así que hace falta un módulo, pero uno bueno se configura por completo desde el back office pegando la URL de captura.

¿Por qué mi llamada al Webservice devuelve 404?

Casi siempre por la reescritura de URL. El endpoint /api del Webservice depende de las URL amigables y de las reglas de reescritura del .htaccess generado por PrestaShop. Confirma que Parámetros de la tienda → Tráfico & SEO → URL amigable esté activado y que tu servidor realmente reescriba URLs (algunas configuraciones de Apache necesitan mod_rewrite habilitado). Es una configuración del servidor, no código.

¿Por qué mi GET del Webservice devuelve solo números de ID en lugar de los detalles del pedido?

Te falta display=full. Sin él, el Webservice devuelve una lista de referencias a recursos (solo ID), no los campos que quieres mapear. Añade &display=full a la URL, o haz una consulta en dos pasos, lista los ID y luego haz GET de cada pedido por su id.

Lecturas relacionadas

• Zapier y Make para PrestaShop, elegir y operar la plataforma, con la comparación entre Make y Zapier
• Configuración de correo electrónico en PrestaShop, por qué las confirmaciones de pedido pertenecen a tu sistema de correo, no a un Zap
• Cuando tu tienda supera el trabajo manual, la señal de que debes pasar del pegamento a una integración real

En qué punto te deja todo esto

La promesa de "sin escribir código" sobrevive al contacto con PrestaShop. Con una corrección honesta: no hay una app lista para conectar y usar, así que te conectas mediante la API Webservice y los pasos genéricos de webhook de Zapier. Para leer desde tu tienda y lanzar notificaciones, esa vía funciona realmente solo con clics. Para escribir de vuelta en tu tienda, te encontrarás con un poco de XML, y conviene saberlo antes de descubrirlo a mitad del montaje. Empieza con una automatización de lectura basada en consulta programada, pruébala con un pedido de test y amplía desde ahí. Cuando el volumen o la complejidad bidireccional superen lo que un Zap puede manejar con soltura, esa será la señal de pasar a una integración más profunda, no una señal de que hayas hecho mal la parte sin código.