Zapier und Make für PrestaShop: Automatisieren Sie Ihre Shop-Abläufe

Zuletzt geprüft im Juni 2026. Preise und Abfrageintervalle ändern sich auf beiden Plattformen häufig, verstehen Sie die Angaben als Orientierung und prüfen Sie die aktuellen Tarife, bevor Sie sich festlegen. Backoffice-Pfade wurden mit PrestaShop 1.7, 8.x und 9.x geprüft.

Jeder PrestaShop-Shop verliert Zeit durch dieselbe Lücke: kleine operative Aufgaben, die jeweils nur zwei Minuten dauern und zusammen einen ganzen Nachmittag pro Woche verschlingen. Eine neue Bestellung muss ans Lager weitergeleitet werden. Der Status "Versendet" sollte eine SMS auslösen, nicht nur eine E-Mail. Ein neuer Kunde gehört ins CRM. Nichts davon ist schwierig, es hört nur nie auf. Zapier und Make (ehemals Integromat) übernehmen genau diese Verbindungsarbeit: Sie verbinden die Daten aus PrestaShop mit den hundert anderen Werkzeugen, die Ihr Unternehmen bereits nutzt. Die eigentliche Frage ist nicht, ob Sie automatisieren sollten, sondern mit welcher Plattform, und ebenso oft, wann eine Automatisierungsplattform schlicht das falsche Werkzeug ist und stattdessen ein natives Modul eingesetzt werden sollte.

Genau diese Entscheidung klärt dieser Leitfaden. Wir vergleichen Zapier und Make speziell für PrestaShop-Shops direkt miteinander, zeigen die drei realistischen Wege, PrestaShop mit einer der beiden Plattformen zu verbinden (inklusive der exakten Backoffice-Pfade), und geben Ihnen ein Raster dafür, wann eine externe Plattform ihre monatlichen Kosten wert ist und wann sie leise zum Risiko wird. Wenn Sie eine ruhige Schritt-für-Schritt-Anleitung für Ihren ersten No-Code-Automatisierungsablauf suchen, ist das ein eigenes Thema, siehe PrestaShop und Zapier: Arbeitsabläufe automatisieren, ohne Code zu schreiben. Hier geht es darum, die Plattform auszuwählen und zuverlässig zu betreiben.

Zapier vs. Make: der ehrliche Vergleich für PrestaShop

Beide Plattformen tun im Kern dasselbe, sie beobachten ein Ereignis in einer Anwendung und lösen anschließend eine Aktion in einer anderen aus. Zapier nennt einen solchen Ablauf einen Zap; Make nennt ihn ein Scenario. Die Unterschiede, die für PrestaShop-Händler wirklich zählen, sind die Integrationstiefe, das Preismodell und die Art, wie die Plattform Ihre Nutzung misst.

Was heißt das konkret für Sie? Für die meisten PrestaShop-Shops ist Make die bessere Standardwahl, vor allem wegen des nativen PrestaShop-Connectors (Makes eigene App, nicht von PrestaShop SA gepflegt). Er nimmt Ihnen den fehleranfälligsten Teil der Einrichtung ab: das manuelle Verdrahten von Webhooks und Webservice. Außerdem altert die Abrechnung pro Operation besser, wenn Ihr Bestellvolumen steigt. Greifen Sie eher zu Zapier, wenn die anderen Anwendungen in Ihrem Ablauf wichtiger sind und dort einen stärkeren Zapier-Connector haben, oder wenn Sie den absolut kürzesten Weg von der Idee zur laufenden Automatisierung wollen und PrestaShop ohnehin nur über einen einfachen Webhook anbinden. Die Preise beider Plattformen ändern sich, daher sollten Sie die Zahlen oben als Orientierung verstehen und die aktuellen Tarife prüfen, bevor Sie sich festlegen, der strukturelle Unterschied (pro Task vs. pro Operation, offizielle App vs. keine) bleibt der belastbare Teil.

Drei Wege, PrestaShop anzubinden, und wann welcher passt

Unabhängig von der gewählten Plattform muss PrestaShop Daten liefern. Für Automatisierungen im Stil von Zapier oder Make gibt es drei gängige Wege, die Einrichtungsaufwand gegen Echtzeitnähe abwägen. (Reale Shops nutzen außerdem spezialisierte Marktplatzmodule, ERP-/Buchhaltungs- und Middleware-/iPaaS-Connectoren, direkten Datenbank- oder Dateiaustausch in älteren ERP-Systemen sowie individuelle Module, aber die drei folgenden Wege sind diejenigen, die Sie typischerweise mit Zapier oder Make verbinden.)

Weg 1: der integrierte Webservice (REST-ähnliche API)

PrestaShop bringt einen integrierten Webservice mit: eine REST-ähnliche HTTP API, standardmäßig XML, mit JSON-Ausgabe in unterstützten Versionen. Das ist die flexibelste Verbindung, weil sie nahezu jede Ressource zugänglich macht, Bestellungen, Kunden, Produkte, Lagerbestand, Warenkörbe, Adressen, , aber sie ist pull-basiert: Die Automatisierungsplattform muss sie nach Zeitplan abfragen. So aktivieren Sie sie:

• Gehen Sie im Backoffice zu Erweiterte Einstellungen → Webservice.
• Stellen Sie PrestaShop-Webservice aktivieren auf Ja (dadurch wird das Konfigurations-Flag PS_WEBSERVICE gesetzt).
• Klicken Sie auf Neuen Webservice-Schlüssel hinzufügen und vergeben Sie anschließend Berechtigungen pro Ressource, aktivieren Sie nur die Ressourcen, die die Automatisierung benötigt (z. B. GET für orders und customers, nicht mehr).
• Kopieren Sie den erzeugten Schlüssel als Authentifizierungsdaten in Make oder Zapier. Die Authentifizierung erfolgt per HTTP Basic, mit dem Schlüssel als Benutzername und leerem Passwort, über HTTPS.

Eine Abfrage nach "neuen Bestellungen" ist auf diesem Weg ein einzelner GET. Dieser Aufruf liefert die fünf neuesten Bestellungen mit allen Feldern als JSON:

GET https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5

# Auth: HTTP Basic – username = your Webservice key, password = blank
curl -u "YOUR_WEBSERVICE_KEY:" \
  "https://yourstore.com/api/orders?display=full&output_format=JSON&sort=[id_DESC]&limit=5"

Der Parameter display=full wird leicht vergessen. Ohne ihn gibt der Webservice nur eine Liste von Ressourcen-IDs zurück, nicht die Bestellfelder, die Sie tatsächlich in Ihren Zap oder Ihr Scenario übernehmen möchten. output_format=JSON wird nur in Versionen berücksichtigt, die es unterstützen; die Standardausgabe ist XML. Speichern Sie in der Plattform die höchste Bestell-ID, die Sie bereits verarbeitet haben, und reagieren Sie nur auf Zeilen darüber. Sonst verarbeiten Sie bei jeder Abfrage dieselben Bestellungen erneut.

Zwei Dinge sind hier nicht verhandelbar: Stellen Sie die API immer über HTTPS bereit (der Schlüssel reist in der Anfrage mit), und halten Sie Berechtigungen minimal, ein Schlüssel mit Schreibzugriff auf orders, der nach außen gelangt, kann Ihre Verkaufshistorie überschreiben. Wenn Ihre Plattform statische ausgehende IPs anbietet, setzen Sie diese auf Server- oder Firewall-Ebene auf die Whitelist, damit nur Ihre Automatisierung den Endpunkt erreichen kann.

Weg 2: Webhooks (Push, Echtzeit)

Webhooks drehen die Richtung um: Statt dass die Plattform alle paar Minuten fragt "Gibt es etwas Neues?", sendet PrestaShop das Ereignis in dem Moment, in dem es passiert. Das ist das richtige Modell für alles Zeitkritische, eine Slack-Meldung in dem Augenblick, in dem eine Bestellung eingeht, eine Betrugsprüfung direkt an der Kasse. Der Haken: PrestaShop Core hat keinen integrierten Webhook-Sender. Etwas muss am passenden Hook lauschen (actionValidateOrder für eine neue Bestellung, actionOrderStatusPostUpdate für eine Statusänderung, actionObjectCustomerAddAfter für einen neuen Kunden) und die Nutzdaten per POST an die URL Ihres Scenarios senden. Dieses "Etwas" ist ein kleines Modul, entweder aus dem Marktplatz oder ein paar Zeilen Code, die an diese Hooks gebunden sind. Der Gewinn ist echtes Echtzeitverhalten ohne Abfragekosten und ohne gemessenen Task für leere Prüfungen.

Weg 3: Makes nativer PrestaShop-Connector

Wenn Sie sich für Make entschieden haben, ist der native PrestaShop-Connector (Makes eigene App, nicht von PrestaShop SA gepflegt) der Weg mit dem geringsten Widerstand. Er übernimmt die Webservice-Authentifizierung für Sie und stellt fertige Auslöser bereit, um neue und aktualisierte Bestellungen, Produkte und Kunden zu beobachten. Sie tragen also Ihre Shop-URL und den Schlüssel ein und können mit dem Aufbau beginnen. Unter der Haube wird trotzdem abgefragt (er erbt also die unten beschriebene Latenz), aber Sie überspringen jeden manuellen Schritt aus Weg 1. Deshalb fallen die Empfehlungen "Make verwenden" und "den nativen Connector verwenden" bei einem typischen Shop oft zusammen.

Schnelle Entscheidungshilfe: Muss es sofort passieren (Benachrichtigungen, Betrugsabwehr, Timing bei abgebrochenen Warenkörben)? Nutzen Sie Webhooks (Weg 2). Brauchen Sie breiten Lesezugriff auf Katalog und Bestellungen nach Zeitplan und verwenden Make? Nutzen Sie den nativen Connector (Weg 3). Arbeiten Sie mit Zapier oder brauchen eine Ressource, die die App nicht abdeckt? Verdrahten Sie den Webservice manuell (Weg 1).

Die Latenzsteuer. Warum "automatisiert" nicht "sofort" heißt

Das ist der meistmissverstandene Punkt bei Zapier und Make, und er entscheidet darüber, welche Automatisierungen überhaupt sinnvoll sind. Abfragebasierte Auslöser reagieren nicht in dem Moment, in dem etwas passiert, sie prüfen in einem Intervall. Je nach Tarif fragt Zapier ungefähr alle 1–15 Minuten ab, Make in kostenpflichtigen Tarifen bis zu einmal pro Minute (im kostenlosen Tarif seltener). Für ein Protokoll "neue Bestellung nach Google Sheets" ist eine Verzögerung von wenigen Minuten unsichtbar und irrelevant. Bei der Rückgewinnung abgebrochener Warenkörbe, wo das optimale Zeitfenster in Dutzenden Minuten gemessen wird, können diese Abfrageverzögerung plus ein langer Scenario-Zeitplan bedeuten, dass Sie den richtigen Moment vollständig verpassen. PrestaShops eigene Hooks feuern synchron und sofort, genau deshalb gehören manche Aufgaben in ein Modul auf Ihrem Server, nicht in eine Cloud-Plattform irgendwo im Internet.

Wann eine Automatisierungsplattform das falsche Werkzeug ist

Zapier und Make sind in einer Sache hervorragend: Sie verbinden PrestaShop mit einem Nischenwerkzeug, das Ihr Unternehmen nutzt und für das es nie ein eigenes Modul geben wird, ein bestimmter 3PL-Anbieter, eine interne Google-Tabelle, ein Discord-Kanal, ein regionales SMS-Gateway. Für diesen langen Randbereich einzelner Verbindungen sind sie kaum zu schlagen. Es gibt aber klare Fälle, in denen eine externe Plattform mehr kostet, als sie spart:

• Kosten bei Skalierung. Ein Shop mit 200 Bestellungen pro Tag und fünf Automatisierungen pro Bestellung erzeugt rund 30.000 Tasks/Operationen pro Monat. Bei Zapiers Abrechnung pro Task rutschen Sie damit schnell in einen hohen Tarif; bei Makes Modell pro Operation ist es günstiger, aber ein natives Modul ist ein einmaliger Kauf und erledigt die Arbeit danach ohne weitere Task-Kosten. Rechnen Sie mit Ihren eigenen Zahlen, bevor Sie annehmen, die Plattform sei die wirtschaftlichere Wahl.
• Echtzeitaufgaben. Alles, bei dem Timing der eigentliche Zweck ist, Rückgewinnung abgebrochener Warenkörbe, Lagerbestandswarnungen, die einen Überverkauf verhindern müssen, Betrugssignale, kämpft gegen die oben beschriebene Abfrageverzögerung. Ein Modul an einem Hook gewinnt hier klar.
• PrestaShops Datenmodell. Spezifische Preise, Kombinationen, Warenkorbregeln, Multishop, Steuerregeln: all das ist wirklich komplex. Ein externes Scenario, das diese Logik über API-Aufrufe rekonstruieren muss, wird spröde und schwer zu warten; ein gut gebautes natives Modul kann stattdessen PrestaShops eigenes Modell und seine Dienste nutzen, statt diese Regeln extern nachzubauen.
• Abhängigkeitsrisiko. Jede externe Plattform ist eine weitere Stelle, die ausfallen kann. Wenn Zapier oder Make ausfällt, stehen Ihre Automatisierungen mit still. Code, der auf Ihrem eigenen Server läuft, nicht.

Die konkreten Aufgaben, von denen wir bei einer generischen Plattform abraten würden: E-Mail-Marketing und abgebrochene Warenkörbe (ein dedizierter PrestaShop-Connector für Mailchimp, Brevo oder Klaviyo synchronisiert Segmente, Kaufhistorie und den vollständigen Katalog, und verfolgt Warenkorbaktivität in Echtzeit, statt gegen ein Abfragefenster zu arbeiten), Buchhaltung (die Rechnungserstellung ist über eine dafür gebaute Integration deutlich sauberer, die Abwägungen behandeln wir in PrestaShop mit Ihrer Buchhaltungssoftware verbinden) und ernsthafter Bestands- oder Bestellabgleich über Kanäle und Backoffice-Systeme hinweg, der eigentlich eine ERP-Aufgabe ist.

Der letzte Punkt verdient eine eigene Zeile, weil Shops hier am häufigsten mit Zapier zu weit gehen: Ein Wildwuchs aus Scenarios, die Bestände, Bestellungen und Kunden zwischen PrestaShop und einem Backoffice-System synchron halten sollen, ist ein Zeichen dafür, dass Sie über einfache Verbindungsautomatisierung hinausgewachsen sind und ein echtes Integrationsmuster brauchen. Wir ordnen diese Muster in PrestaShop mit Ihrem ERP verbinden ein und beschreiben die Signale, dass Sie diese Grenze überschritten haben, in wenn Ihr Shop über manuelle Arbeit hinauswächst.

Wo mypresta.rocks ins Bild passt

Wir entwickeln PrestaShop-Module, die schwere, shopkritische Integrationen nativ erledigen, auf Ihrem Server, an einem Hook, ohne monatlichen Task-Zähler und ohne Internet-Rundweg zwischen Ereignis und Reaktion. Was ist also die praktische Konsequenz? Aufgaben, die Abfragen und Abrechnung pro Task bestrafen, sofortige Bestellbenachrichtigungen, Echtzeitabgleich von Bestand und Verkaufskanälen, Timing bei abgebrochenen Warenkörben, tiefe CRM- und E-Mail-Plattform-Verbindungen. Laufen schneller und günstiger als Code, der Ihnen gehört, statt als gemietete Operationen. Das ist kein Argument gegen Zapier und Make; es ist eine Arbeitsteilung. Behalten Sie Cloud-Plattformen für wirklich individuelle, niedrigvolumige Verbindungen zu Werkzeugen, für die niemand je ein Modul bauen wird, und verlagern Sie die volumenstarken, zeitkritischen, PrestaShop-bewussten Abläufe in etwas Natives. Für die geplanten Arbeiten, die doch auf Ihrem Server bleiben. Ein nächtlicher Export, ein wiederkehrender Abgleich. Gibt Cron Manager jeder Aufgabe einen Eintrag und eine sichtbare letzte Ausführung, sodass ein Job, der still nicht mehr läuft, sich bemerkbar macht, statt unbemerkt zu bleiben. Und wenn Ihre Automatisierungen den Katalog oder Segmente an eine E-Mail-Plattform senden, hält ein nativer Mailchimp-Connector diese Synchronisierung an einem Hook statt in einer gemessenen Abfrage. Die Vorteile verstärken sich von beiden Seiten: weniger Ausgaben für gemessene Tasks, weniger bewegliche Teile, die ausfallen können, und Abläufe, die in dem Moment reagieren, in dem Ihr Shop es tut.

Automatisierungen betreiben, ohne sich zu verbrennen

Egal auf welcher Seite der Grenze ein Ablauf landet: Einige betriebliche Gewohnheiten verhindern, dass Automatisierung zu einem stillen Risiko wird:

• Ein Ablauf nach dem anderen. Bringen Sie einen einzelnen Zap oder ein einzelnes Scenario zuverlässig mit Testbestellungen zum Laufen, bevor Sie das nächste bauen. Ungetestete Automatisierung gegen Live-Bestelldaten ist der Weg, auf dem man eine fehlerhafte Nutzlast erst entdeckt, nachdem sie bereits im Buchhaltungssystem gelandet ist.
• Achten Sie auf stille Fehler. Ein Zap, der still stehen bleibt, ist schlimmer als einer, der laut scheitert, verpasste Bestellbenachrichtigungen und nicht versendete SMS melden sich nicht von selbst. Prüfen Sie die Ausführungsprotokolle wöchentlich und aktivieren Sie die Fehlerbenachrichtigungen der Plattform.
• Benennen und dokumentieren Sie alles. Nach einem Dutzend Abläufen ist "Kopie von Scenario 7" ein künftiger Notfall. Nutzen Sie die Beschreibungsfelder; notieren Sie, was jeder Ablauf berührt.
• Rotieren und begrenzen Sie Ihre Schlüssel. Wechseln Sie den Webservice-Schlüssel nach Zeitplan und beschränken Sie seine Ressourcenberechtigungen exakt auf das, was die Automatisierung liest oder schreibt, gewähren Sie nie der ganzen API Zugriff "nur für den Fall".
• Senden Sie transaktionale E-Mails über SMTP, nicht über die Plattform. Wenn Ihre Automatisierungen Benachrichtigungen auslösen, ist die E-Mail-Zuverlässigkeit Ihres Shops wichtiger denn je, bringen Sie die zugrunde liegende Zustellung in PrestaShop-E-Mail-Konfiguration: SMTP, Gmail und transaktionale E-Mails sauber in Ordnung.

Häufig gestellte Fragen

Gibt es eine offizielle PrestaShop-App bei Zapier oder Make?

Bei Make gibt es einen nativen PrestaShop-Connector, aber es ist Makes eigene App, nicht von PrestaShop SA gepflegt. Bei Zapier gibt es überhaupt keine offizielle PrestaShop-App; Sie verbinden sich über die integrierte Webservice API und Zapiers generische Webhooks-Schritte. Dieser Unterschied ist der Hauptgrund, warum Make für einen typischen Shop die einfachere Standardwahl ist.

Warum ist mein "automatisierter" Ablauf nicht sofort?

Weil abfragebasierte Auslöser in Intervallen prüfen, statt in dem Moment zu reagieren, in dem etwas passiert, bei Zapier ungefähr alle 1–15 Minuten, bei Make in kostenpflichtigen Tarifen bis zu einmal pro Minute. Für Protokollierung oder Benachrichtigungen ist diese Verzögerung unsichtbar; bei zeitkritischen Aufgaben wie der Rückgewinnung abgebrochener Warenkörbe oder der Vermeidung von Überverkäufen kann sie dazu führen, dass Sie das Zeitfenster verpassen. Solche Aufgaben gehören über einen Webhook oder ein natives Modul an einen PrestaShop-Hook (der sofort feuert), nicht in eine Abfrage.

Zapier oder Make für einen PrestaShop-Shop?

Make ist für die meisten Shops die bessere Standardwahl, vor allem wegen des nativen PrestaShop-Connectors und der günstigeren Abrechnung pro Operation bei steigendem Volumen. Wählen Sie Zapier, wenn die anderen Anwendungen in Ihrem Ablauf einen stärkeren Zapier-Connector haben oder wenn Sie den kürzestmöglichen Weg zu einer funktionierenden Automatisierung wollen und PrestaShop ohnehin über einen einfachen Webhook anbinden.

Wann sollte ich ein natives Modul statt einer Automatisierungsplattform verwenden?

Wenn die Aufgabe hohes Volumen hat, zeitkritisch ist oder tief in PrestaShops Datenmodell steckt, sofortige Bestellbenachrichtigungen, Echtzeitabgleich von Bestand und Kanälen, Timing bei abgebrochenen Warenkörben, Buchhaltung sowie CRM-/E-Mail-Plattform-Verbindungen. Ein natives Modul läuft auf Ihrem Server, ohne Abrechnung pro Task und ohne Internet-Rundweg. Behalten Sie Zapier und Make für niedrigvolumige, wirklich individuelle Verbindungen zu Nischenwerkzeugen, für die niemand ein Modul bauen wird.

Wie halte ich meinen Webservice-Schlüssel sicher, wenn eine Cloud-Plattform ihn speichert?

Beschränken Sie ihn exakt auf die Ressourcen, die die Automatisierung berührt (nie der ganzen API Zugriff gewähren), stellen Sie die API immer über HTTPS bereit, wechseln Sie den Schlüssel nach Zeitplan, und wenn Ihre Plattform statische ausgehende IPs anbietet, setzen Sie diese auf Server- oder Firewall-Ebene auf die Whitelist, damit nur Ihre Automatisierung den Endpunkt erreichen kann. Ein eng begrenzter Schlüssel bedeutet: Wenn er nach außen gelangt, ist der Schaden auf das beschränkt, was Sie angehakt haben, nicht auf Ihre ganze Datenbank.

Weiterführende Lektüre

• PrestaShop und Zapier ohne Code zu schreiben, die praktische Einrichtung, Rezept für Rezept
• PrestaShop mit Ihrer Buchhaltungssoftware verbinden, warum das Hauptbuch zu den Aufgaben gehört, die nicht auf eine generische Plattform sollten
• E-Mail-Konfiguration in PrestaShop, sorgen Sie für solide transaktionale Zustellung, bevor Automatisierungen darauf aufbauen

Bei Automatisierung geht es nicht darum, Urteilsvermögen zu ersetzen, sondern darum, die wiederkehrenden Minuten zu löschen, die sich zu verlorenen Stunden stapeln. Zapier und Make sind das richtige Werkzeug für die individuellen, niedrigvolumigen Randbereiche dieser Arbeit; native PrestaShop-Module sind das richtige Werkzeug für den volumenstarken, zeitkritischen Kern. Zu wissen, was wohin gehört, und jede Verbindung korrekt über den Webservice, einen Webhook oder einen nativen Hook herzustellen. Ist der Unterschied zwischen Automatisierung, die Zeit spart, und einem Geflecht aus Cloud-Scenarios, das selbst wieder Betreuung braucht.