PrestaShop e Zapier: automatizzare i flussi di lavoro senza scrivere codice

Ultima revisione giugno 2026. La directory di Zapier e il supporto JSON di PrestaShop cambiano nel tempo: verifica entrambi per la tua versione prima di escludere qualsiasi opzione. Percorsi del back office verificati su PrestaShop 1.6, 1.7, 8.x e 9.x.

"Senza scrivere codice" è la promessa che attira la maggior parte dei commercianti verso Zapier: ed è sostanzialmente vera, ma su PrestaShop c'è un fatto che quasi nessuno ti dice subito: al momento in cui scriviamo, nella directory di Zapier non esiste un'app mantenuta da PrestaShop. Cerca "PrestaShop" su Zapier e non troverai il connettore pulito, in stile Shopify, che forse ti aspettavi (prima di scartare l'idea, verifica nella directory di Zapier se oggi esistono opzioni di terze parti). Questo non significa che la strada no-code sia chiusa: significa che il percorso diretto senza codice passa di solito dall'API Webservice integrata in PrestaShop e dal passaggio generico Webhooks di Zapier, mentre l'altra via è affidarsi a moduli connettori di terze parti o a middleware. Capire esattamente come si incastrano questi due elementi è il punto centrale. Questa guida mostra il collegamento no-code reale in un vero back office PrestaShop, dove non serve davvero scrivere codice, e quei due o tre punti in cui qualcuno ti passa di nascosto uno snippet e continua comunque a chiamarlo "no-code".

Se stai ancora decidendo quale piattaforma adottare come standard, o vuoi una panoramica più ampia delle operazioni del negozio che vale la pena automatizzare, parti dal nostro articolo collegato: Zapier e Make per PrestaShop. Poi torna qui per la parte pratica sul collegamento.

Perché non esiste una "app PrestaShop" e perché va bene così

Le piattaforme ospitate come Shopify pubblicano e mantengono un'app Zapier perché c'è una sola azienda che controlla un'unica base di codice. PrestaShop è self-hosted e open source: il tuo negozio vive sul tuo server, nella tua versione (1.6, 1.7, 8.x, 9.x), con i tuoi moduli. Non esiste un soggetto centrale che possa pubblicare e certificare un unico connettore per tutto questo. Quindi, invece di un'app con marchio, PrestaShop espone una API Webservice: un'interfaccia REST standard integrata nel core. Zapier le parla come parlerebbe a qualsiasi API personalizzata: tramite i passaggi generici Webhooks by Zapier. Una volta accettato questo, il problema della "mancanza di un'app nativa" diventa una configurazione da quindici minuti, non un vicolo cieco.

Passaggio 1: attiva il Webservice (davvero senza codice)

Questa è la base, e si fa solo cliccando nel back office:

• Vai su Parametri avanzati → Webservice (in PrestaShop 1.6 si trova sotto Parametri avanzati → Web service).
• Imposta Abilita il webservice di PrestaShop su Sì e salva.
• Fai clic su Aggiungi una nuova chiave webservice. PrestaShop genera una lunga chiave casuale: è la credenziale che userà Zapier, quindi trattala come una password.
• Nella griglia dei permessi, concedi solo le risorse che ti servono davvero. Per leggere gli ordini, seleziona orders (e di solito customers, addresses) sotto Visualizza (GET). Per scrivere nel negozio, per esempio aggiornare le giacenze, seleziona stock_availables sotto Modifica (PUT). Lascia disattivato tutto il resto.

Che cosa ottieni, in pratica? Una chiave limitata che può fare esattamente un lavoro e nient'altro. Se quella chiave dovesse finire in giro, il perimetro del danno è ciò che hai selezionato, non l'intero database. C'è un problema reale che colpisce spesso gli hosting condivisi o più datati: il Webservice ha bisogno che la riscrittura degli URL funzioni. Se lo abiliti e le chiamate restituiscono 404, controlla che Parametri negozio → Traffico & SEO → URL semplificato sia attivo e che il server riscriva davvero gli URL; alcune configurazioni Apache richiedono mod_rewrite abilitato e le regole di riscrittura generate da PrestaShop nel file .htaccess (quelle che indirizzano /api al dispatcher del Webservice). È un'impostazione del server, non codice da scrivere.

Passaggio 2: scegli la direzione, dal negozio a Zapier o da Zapier al negozio

Ogni automazione segue una di queste due direzioni, e PrestaShop le gestisce in modo molto diverso. Capire bene questa distinzione è ciò che separa una configurazione affidabile da una che si perde ordini in silenzio.

Passaggio 3: la direzione trigger (dove il "tempo reale" nasconde un dettaglio)

Vuoi uno Zap che parta quando arriva un nuovo ordine. Ci sono due modi corretti per farlo, e l'esperienza è molto diversa.

Il modo puramente no-code: polling programmato

Usa un trigger Schedule by Zapier (per esempio ogni 15 minuti), seguito da un passaggio Webhooks by Zapier → GET che chiama l'endpoint degli ordini:

• URL: https://yourstore.com/api/orders?display=full&sort=[id_DESC]&limit=5&output_format=JSON
• Autenticazione: Basic Auth, nome utente = la tua chiave Webservice, password = lasciata vuota.

Il parametro display=full è importante quanto il resto dell'URL: senza di lui, il Webservice restituisce solo riferimenti alle risorse (un elenco di ID), non i campi dell'ordine che vuoi mappare. Quindi aggiungi display=full, oppure fai una lettura in due passaggi (prima elenchi gli ID, poi fai GET di ogni ordine per id). L'altro elemento chiave è output_format=JSON: per impostazione predefinita il Webservice restituisce XML, e l'output JSON dipende dal supporto nella tua versione di PrestaShop, quindi verifica che il tuo negozio lo rispetti davvero. Un polling di questo tipo richiede anche una logica di deduplicazione: salva l'id o la data dell'ultimo ordine visto e agisci solo sulle righe più recenti, altrimenti rielaborerai gli stessi ordini a ogni esecuzione oppure perderai un picco arrivato tra due controlli. L'altro compromesso: il polling non è istantaneo (aspetti fino all'intervallo configurato) e consuma un task a ogni esecuzione, anche quando non c'è nessun nuovo ordine. Per la maggior parte dei negozi piccoli e medi è un prezzo ragionevole per non coinvolgere uno sviluppatore. È il percorso da cui consigliamo di partire.

Il modo in tempo reale: un webhook dal tuo negozio

Se hai davvero bisogno che un ordine arrivi su Zapier nell'istante in cui viene effettuato, il negozio deve inviare l'evento. Il core di PrestaShop non invia webhook in uscita da solo, quindi serve installare un modulo webhook che esegua una HTTP POST su eventi come la creazione dell'ordine (internamente agganciandosi a actionValidateOrder o actionOrderStatusPostUpdate) verso un URL Catch Hook fornito da Zapier. La buona notizia: un modulo webhook ben fatto si configura interamente dal back office. Incolli l'URL catch di Zapier in un campo e scegli quali eventi inviare. Niente codice. La nota onesta: a quel punto dipendi da un modulo che deve rimanere compatibile con ogni versione di PrestaShop e PHP che usi, ed è esattamente il tipo di grattacapo di compatibilità su cui noi insistiamo così che tu non debba farlo.

Passaggio 4: la direzione azione (l'asterisco del "no-code")

Scrivere di nuovo dentro PrestaShop è il punto in cui la promessa no-code prende il suo asterisco. Il Webservice accetta le modifiche come XML, non come i campi modulo amichevoli che Zapier mostra per le app native. Per aggiornare la giacenza di un prodotto, il flusso corretto è: fai GET della riga stock_available esatta per quel prodotto (con il corretto id_product_attribute per le combinazioni e il giusto contesto negozio in multishop), modifichi il valore <quantity>, poi fai PUT dell'intero blocco XML mantenendo tutti i campi obbligatori. È facile corrompere qualcosa: PUT sostituisce l'intera risorsa, quindi eliminare o sbagliare un campo, l'id della combinazione, l'id del negozio o una dipendenza può scrivere la giacenza sbagliata o rompere la riga. Provalo sempre su una copia di staging prima di puntarlo al negozio live. In un passaggio Webhooks by Zapier stai incollando un template XML e inserendo al suo interno i campi mappati. Non è programmazione: non ci sono cicli, variabili o logica. Ma è più che trascinare blocchi, e una guida onesta deve dirlo invece di fingere che sia tutto punta e clicca.

Il corpo XML per quella PUT delle giacenze, con i campi attesi da PrestaShop preservati, è questo: nota che prima fai GET della riga per conoscere gli id reali, poi cambi 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>

E quindi? Per le automazioni di lettura e notifica (nuovo ordine → Slack, nuovo cliente → foglio di calcolo), probabilmente non toccherai mai l'XML. Per le automazioni che scrivono nel negozio (sincronizzare le scorte, cambiare lo stato di un ordine, creare un cliente), metti in conto un pomeriggio per preparare correttamente il primo payload. Poi lo copierai per ogni Zap simile.

Le opzioni di collegamento, ordinate da quella che richiede meno intervento

I limiti di cui Zapier non ti avviserà

L'automazione no-code è lo strumento giusto per una quantità enorme di attività, e quello sbagliato per alcune. Conoscere il limite prima di sbatterci contro evita una migrazione dolorosa più avanti:

• Volume. Zapier fattura per task. Un negozio con 30 ordini al giorno distribuiti su quattro automazioni sta comodo; uno con migliaia di ordini al giorno vedrà il conto salire rapidamente. A quel punto, un'integrazione diretta o un'integrazione ERP quando il negozio supera il lavoro manuale costa meno per transazione.
• Sincronizzazione bidirezionale ad alto volume. Mantenere giacenze, prezzi e ordini costantemente allineati in entrambe le direzioni tra PrestaShop e un altro grande sistema non è ciò per cui Zapier è pensato: vedi gli schemi che reggono davvero in pattern di integrazione ERP che funzionano.
• Precisione contabile. Puoi anche inviare gli ordini a un software di contabilità tramite Zapier, ma regole fiscali, note di credito e rimborsi diventano complicati in fretta; di solito è più sensato un ponte dedicato, come spieghiamo in collegare PrestaShop al tuo software di contabilità.
• Email transazionali. Non instradare le conferme d'ordine attraverso uno Zap: appartengono al sistema email di PrestaShop, configurato correttamente. Vedi configurazione email in PrestaShop.

Tre abitudini che impediscono alle automazioni no-code di morderti

• Limita la chiave, poi dimenticatene. Il più grande vantaggio in termini di sicurezza è la griglia dei permessi nel Passaggio 1: concedi il minimo indispensabile e una chiave trapelata potrà fare quasi nulla.
• Prova prima con un ordine usa e getta. Effettua un vero ordine di test e osserva l'intero Zap dall'inizio alla fine prima di fidarti. Un'automazione silenziosa che perde un ordine su tre è peggio di nessuna automazione, perché smetti di controllare. (Se nel frattempo la conferma di un ordine di test sparisce, quello è un problema di recapito email, non di Zapier: Resend Order Confirmation ti permette di reinviarla dall'ordine mentre sistemi la causa.)
• Controlla la cronologia dei task per una settimana. Zapier registra ogni esecuzione; uno Zap che scrive nel negozio e inizia a fallire perché PrestaShop ha restituito un errore XML resterà lì in silenzio. Cinque minuti il lunedì bastano a intercettarlo.

Domande frequenti

Davvero non esiste un'app PrestaShop su Zapier?

Al momento in cui scriviamo, nella directory di Zapier non esiste un'app mantenuta da PrestaShop, perché PrestaShop è self-hosted, usato con molte versioni e molti moduli, e non c'è un unico soggetto che possa pubblicarne e certificarne una. Ti colleghi invece tramite l'API Webservice integrata in PrestaShop e i passaggi generici Webhooks by Zapier di Zapier. Prima di escluderli, controlla se oggi esistono connettori di terze parti nella directory, ma la strada tramite Webservice è il percorso no-code più affidabile.

Collegare PrestaShop a Zapier è davvero "senza codice"?

Per leggere e inviare notifiche, per esempio da un nuovo ordine a Slack o da un nuovo cliente a un foglio di calcolo, sì: si fa solo a clic. Attivi il Webservice, limiti una chiave e interroghi il negozio con un GET di Webhooks. Per scrivere nel tuo negozio (aggiornare le giacenze, cambiare lo stato di un ordine) incontrerai un po' di XML, perché il Webservice accetta le modifiche come corpo XML invece che come campi modulo. Non ci sono cicli né logica, ma è più che trascinare blocchi, ed è meglio saperlo prima di iniziare.

Come porto gli ordini PrestaShop in Zapier in tempo reale?

Il polling non può essere davvero istantaneo: controlla secondo la tua pianificazione (per esempio ogni 15 minuti). Per il tempo reale serve che il negozio invii l'evento: un modulo webhook che esegue una HTTP POST alla creazione dell'ordine (agganciandosi ad actionValidateOrder) verso un URL Zapier Catch Hook. Il core di PrestaShop non ha un invio webhook in uscita, quindi serve un modulo. Uno buono, però, si configura interamente dal back office incollando l'URL catch.

Perché la mia chiamata Webservice restituisce 404?

Quasi sempre per la riscrittura degli URL. L'endpoint /api del Webservice dipende dagli URL semplificati e dalle regole di riscrittura nel file .htaccess generato da PrestaShop. Verifica che Parametri negozio → Traffico & SEO → URL semplificato sia attivo e che il server riscriva davvero gli URL (alcune configurazioni Apache richiedono mod_rewrite abilitato). È un'impostazione del server, non codice.

Perché il mio GET del Webservice restituisce solo numeri ID invece dei dettagli dell'ordine?

Manca display=full. Senza di lui, il Webservice restituisce un elenco di riferimenti alle risorse (solo ID), non i campi che vuoi mappare. Aggiungi &display=full all'URL, oppure fai una lettura in due passaggi: prima elenchi gli ID, poi fai GET di ogni ordine per id.

Letture correlate

• Zapier e Make per PrestaShop, scegliere e gestire la piattaforma, con il confronto Make-vs-Zapier
• Configurazione email in PrestaShop, perché le conferme d'ordine appartengono al sistema email, non a uno Zap
• Quando il tuo negozio supera il lavoro manuale. Il segnale che è ora di passare dal collante a una vera integrazione

Dove ti lascia tutto questo

La promessa "senza scrivere codice" regge all'incontro con PrestaShop, con una correzione onesta: non esiste un'app pronta da collegare e usare, quindi ci si connette tramite l'API Webservice e i passaggi webhook generici di Zapier. Per leggere dal negozio e inviare notifiche, questo percorso è davvero fatto solo di clic. Per scrivere nel negozio incontrerai un po' di XML, ed è meglio saperlo prima che scoprirlo a metà configurazione. Parti con una sola automazione di lettura basata su polling, provala su un ordine di test e poi aggiungi il resto. Quando il volume o la complessità bidirezionale superano ciò che uno Zap può gestire con eleganza, quello è il segnale per passare a un'integrazione più profonda, non la prova che hai sbagliato la parte no-code.