PrestaShop und Zapier: Arbeitsabläufe automatisieren, ohne Code zu schreiben

Zuletzt geprüft im Juni 2026. Das Verzeichnis von Zapier und die JSON-Unterstützung von PrestaShop ändern sich mit der Zeit, prüfen Sie beides für Ihre Version, bevor Sie eine Möglichkeit ausschließen. Backoffice-Pfade wurden für PrestaShop 1.6, 1.7, 8.x und 9.x geprüft.

„Ohne Code zu schreiben“ ist das Versprechen, das die meisten Händler zu Zapier bringt, und im Großen und Ganzen stimmt es auch. Es gibt jedoch eine Tatsache über PrestaShop, die Ihnen am Anfang kaum jemand sagt: Zum Zeitpunkt der Erstellung gibt es im Verzeichnis von Zapier keine von PrestaShop gepflegte App. Suchen Sie in Zapier nach „PrestaShop“, finden Sie nicht den sauberen Connector im Stil von Shopify, den Sie vielleicht erwartet haben (prüfen Sie das Verzeichnis von Zapier auf aktuelle Drittanbieter-Optionen, bevor Sie diese Möglichkeit ausschließen). Das heißt nicht, dass der No-Code-Weg versperrt ist. Es heißt nur, dass der direkte No-Code-Weg in der Regel über die integrierte Webservice-API von PrestaShop und den generischen Schritt Webhooks von Zapier führt. Drittanbieter-Connector-Module oder Middleware sind die andere Route. Genau zu verstehen, wie diese beiden Bausteine zusammenspielen, ist der entscheidende Punkt. Dieser Leitfaden zeigt die tatsächliche No-Code-Verknüpfung in einem echten PrestaShop-Backoffice: die Stellen, an denen wirklich kein Code nötig ist, und die zwei oder drei Stellen, an denen Ihnen jemand stillschweigend ein Snippet gibt und es trotzdem „No-Code“ nennt.

Wenn Sie noch entscheiden, welche Plattform Sie standardisieren möchten, oder wenn Sie erst einen breiten Überblick darüber brauchen, welche Shop-Prozesse sich sinnvoll automatisieren lassen, beginnen Sie mit unserem begleitenden Beitrag, Zapier und Make für PrestaShop, und kommen Sie anschließend hierher zurück, wenn es um die praktische Verbindung geht.

Warum es keine „PrestaShop-App“ gibt, und warum das kein Problem ist

Gehostete Plattformen wie Shopify veröffentlichen und pflegen eine Zapier-App, weil ein Unternehmen eine Codebasis kontrolliert. PrestaShop ist selbst gehostet und Open Source: Ihr Shop läuft auf Ihrem Server, in Ihrer Version (1.6, 1.7, 8.x, 9.x), mit Ihren Modulen. Es gibt keine zentrale Stelle, die einen einzigen Connector für all das veröffentlichen und zertifizieren könnte. Statt einer gebrandeten App stellt PrestaShop deshalb eine Webservice-API bereit, eine standardisierte REST-Schnittstelle im Kernsystem, und Zapier spricht sie so an wie jede andere benutzerdefinierte API: über generische Webhooks by Zapier-Schritte. Sobald Sie das akzeptieren, wird aus dem Problem „keine native App“ keine Sackgasse, sondern eine Einrichtung von etwa fünfzehn Minuten.

Schritt 1, den Webservice aktivieren (wirklich ohne Code)

Das ist die Grundlage, und sie besteht ausschließlich aus Klicks im Backoffice:

• Gehen Sie zu Erweiterte Einstellungen → Webservice (in PrestaShop 1.6 finden Sie ihn unter Erweiterte Einstellungen → Webservice).
• Setzen Sie Webservice von PrestaShop aktivieren auf Ja und speichern Sie.
• Klicken Sie auf Neuen Webservice-Schlüssel hinzufügen. PrestaShop erzeugt einen langen zufälligen Schlüssel. Das sind die Zugangsdaten, die Zapier verwenden wird. Behandeln Sie ihn also wie ein Passwort.
• Vergeben Sie im Berechtigungsraster nur die Ressourcen, die Sie wirklich benötigen. Zum Lesen von Bestellungen aktivieren Sie orders (und meist auch customers, addresses) unter Anzeigen (GET). Für Schreibzugriffe, zum Beispiel zum Aktualisieren des Lagerbestands, aktivieren Sie stock_availables unter Ändern (PUT). Lassen Sie alles andere deaktiviert.

Was bringt Ihnen das? Einen begrenzten Schlüssel, der genau eine Aufgabe erledigen kann und sonst nichts. Falls dieser Schlüssel jemals preisgegeben wird, entspricht der mögliche Schaden genau dem, was Sie angehakt haben, nicht Ihrer gesamten Datenbank. Ein echtes Problem, über das viele bei Shared Hosting oder älterem Hosting stolpern: Der Webservice braucht funktionierendes URL-Rewriting. Wenn Sie ihn aktivieren und Aufrufe mit 404 enden, prüfen Sie, ob Shop-Parameter → Traffic & SEO → Benutzerfreundliche URL aktiv ist und ob Ihr Server tatsächlich umschreibt. Manche Apache-Setups benötigen aktiviertes mod_rewrite sowie die von PrestaShop generierten Rewrite-Regeln in .htaccess (die Regeln, die /api an den Webservice-Dispatcher weiterleiten). Das ist eine Servereinstellung, kein Code, den Sie schreiben.

Schritt 2, die Richtung festlegen: Shop zu Zapier oder Zapier zu Shop

Jede Automatisierung läuft in eine von zwei Richtungen, und PrestaShop behandelt sie sehr unterschiedlich. Diese Unterscheidung richtig zu treffen, entscheidet darüber, ob eine Einrichtung zuverlässig funktioniert oder stillschweigend Bestellungen übersieht.

Schritt 3. Die Trigger-Richtung (wo „Echtzeit“ einen Haken hat)

Sie möchten einen Zap, der startet, sobald eine neue Bestellung eingeht. Dafür gibt es zwei ehrliche Wege, und sie fühlen sich sehr unterschiedlich an.

Der reine No-Code-Weg: geplantes Polling

Verwenden Sie einen Schedule by Zapier-Trigger (zum Beispiel alle 15 Minuten), gefolgt von einem Webhooks by Zapier → GET-Schritt, der Ihren Bestell-Endpunkt aufruft:

• URL: https://yourstore.com/api/orders?display=full&sort=[id_DESC]&limit=5&output_format=JSON
• Authentifizierung: Basic Auth, Benutzername = Ihr Webservice-Schlüssel, Passwort = leer lassen.

Der Parameter display=full ist genauso wichtig wie der Rest der URL: Ohne ihn gibt der Webservice nur Ressourcenverweise zurück (eine Liste von IDs), nicht die Bestellfelder, die Sie zuordnen möchten. Sie fügen also entweder display=full hinzu oder arbeiten mit einem zweistufigen Abruf (IDs auflisten, dann jede Bestellung per GET über ihre id abrufen). Der Parameter output_format=JSON ist das zweite zentrale Element. Standardmäßig gibt der Webservice XML zurück, und die JSON-Ausgabe hängt davon ab, ob Ihre PrestaShop-Version sie unterstützt. Prüfen Sie also, ob Ihr Shop sie wirklich beachtet. Polling wie dieses benötigt außerdem Deduplizierungslogik: Speichern Sie die zuletzt gesehene Bestell-ID oder das Datum und verarbeiten Sie nur Datensätze, die neuer sind. Andernfalls verarbeiten Sie bei jedem Lauf dieselben Bestellungen erneut oder verpassen einen Schub an Bestellungen, der zwischen zwei Abfragen eingeht. Der andere Kompromiss: Polling ist nicht sofort (Sie warten bis zu Ihrem Intervall) und kostet bei jedem Lauf eine Aufgabe, egal ob es eine neue Bestellung gibt oder nicht. Für die meisten kleinen bis mittelgroßen Shops ist das ein fairer Preis für null Entwickleraufwand. Das ist der Weg, mit dem wir Ihnen den Einstieg empfehlen.

Der Echtzeit-Weg: ein Webhook aus Ihrem Shop

Wenn eine Bestellung wirklich in dem Moment bei Zapier landen muss, in dem sie aufgegeben wird, muss der Shop sie pushen. Der PrestaShop-Kern sendet von sich aus keine ausgehenden Webhooks. Daher bedeutet das, ein Webhook-Modul zu installieren, das bei Ereignissen wie Bestellerstellung einen HTTP POST auslöst (intern über actionValidateOrder oder actionOrderStatusPostUpdate) und ihn an eine Catch Hook-URL sendet, die Zapier Ihnen bereitstellt. Die gute Nachricht: Ein gut gebautes Webhook-Modul wird vollständig im Backoffice konfiguriert, Sie fügen die Catch-URL von Zapier in ein Feld ein und wählen aus, welche Ereignisse gesendet werden sollen. Kein Code. Die ehrliche Einschränkung: Sie sind jetzt darauf angewiesen, dass ein Modul mit jeder PrestaShop- und PHP-Version, die Sie betreiben, sauber kompatibel bleibt. Genau diese Art von Kompatibilitätsarbeit nehmen wir sehr ernst, damit Sie sich nicht darum kümmern müssen.

Schritt 4, die Aktionsrichtung (das Sternchen bei „No-Code“)

Zurück in PrestaShop zu schreiben ist der Punkt, an dem das No-Code-Versprechen sein Sternchen bekommt. Der Webservice akzeptiert Änderungen als XML, nicht als freundliche Formularfelder, wie Zapier sie bei nativen Apps zeigt. Um den Lagerbestand eines Produkts zu aktualisieren, ist der korrekte Ablauf: per GET genau die stock_available-Zeile für dieses Produkt abrufen (mit dem richtigen id_product_attribute für Kombinationen und dem korrekten Shop-Kontext bei Multishop), den Wert <quantity> ändern und anschließend den gesamten XML-Block per PUT zurücksenden, wobei jedes erforderliche Feld erhalten bleibt. Das lässt sich leicht beschädigen: PUT ersetzt die gesamte Ressource. Wenn ein Feld fehlt oder nicht passt. Die Kombinations-ID, die Shop-ID, eine Abhängigkeit. Kann der falsche Lagerbestand geschrieben oder die Zeile beschädigt werden. Testen Sie das immer zuerst auf einer Staging-Kopie, bevor Sie es auf Ihren Live-Shop richten. In einem Webhooks-by-Zapier-Schritt fügen Sie eine XML-Vorlage ein und setzen zugeordnete Felder hinein. Das ist keine Programmierung. Es gibt keine Schleifen, Variablen oder Logik, aber es ist mehr als Blöcke zu ziehen. Ein ehrlicher Leitfaden sollte das sagen, statt so zu tun, als wäre alles reines Point-and-Click.

Der XML-Body für dieses Stock-PUT sieht mit den von PrestaShop erwarteten Feldern so aus, beachten Sie, dass Sie die Zeile zuerst per GET abrufen, um die echten IDs zu kennen, und dann nur <quantity> ändern:

<?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>

Was heißt das praktisch? Bei Lese- und Benachrichtigungsautomatisierungen (neue Bestellung → Slack, neuer Kunde → Tabellenblatt) werden Sie XML wahrscheinlich nie anfassen. Bei Automatisierungen, die in den Shop zurückschreiben (Lagerbestand synchronisieren, Bestellstatus ändern, Kunden anlegen), sollten Sie einen Nachmittag einplanen, um die erste Nutzlast korrekt aufzubauen, danach kopieren Sie sie für jeden ähnlichen Zap.

Die Verbindungsoptionen, geordnet danach, wie wenig Sie anfassen müssen

Die Grenzen, vor denen Zapier Sie nicht warnt

No-Code-Automatisierung ist für sehr viele Aufgaben das richtige Werkzeug, und für einige wenige das falsche. Wenn Sie die Grenzen kennen, bevor Sie sie erreichen, ersparen Sie sich später eine schmerzhafte Migration:

• Volumen. Zapier rechnet pro Aufgabe ab. Ein Shop mit 30 Bestellungen pro Tag über vier Automatisierungen ist unproblematisch; ein Shop mit Tausenden Bestellungen pro Tag sieht die Rechnung schnell steigen. Ab diesem Punkt ist eine direkte Integration oder eine ERP-Integration, sobald Ihr Shop aus manueller Arbeit herausgewachsen ist, pro Transaktion günstiger.
• Bidirektionale Synchronisierung mit hohem Volumen. Lagerbestände, Preise und Bestellungen dauerhaft in beide Richtungen zwischen PrestaShop und einem anderen großen System konsistent zu halten, ist nicht der Zweck von Zapier. Die Muster, die in der Praxis belastbar sind, finden Sie in funktionierenden Mustern für ERP-Integrationen.
• Präzision in der Buchhaltung. Sie können Bestellungen über Zapier in eine Buchhaltungssoftware übertragen, aber Steuerregeln, Gutschriften und Rückerstattungen werden schnell kleinteilig; eine speziell dafür gebaute Brücke ist meist vernünftiger, wie wir in PrestaShop mit Ihrer Buchhaltungssoftware verbinden erklären.
• Transaktionale E-Mails. Leiten Sie Bestellbestätigungen nicht über einen Zap, das gehört in das korrekt konfigurierte E-Mail-System von PrestaShop. Siehe E-Mail-Konfiguration in PrestaShop.

Drei Gewohnheiten, damit No-Code-Automatisierungen Ihnen nicht auf die Füße fallen

• Den Schlüssel begrenzen und dann vergessen. Der größte Sicherheitsgewinn ist das Berechtigungsraster in Schritt 1, vergeben Sie nur das Minimum, und ein offengelegter Schlüssel kann nahezu nichts ausrichten.
• Zuerst mit einer Wegwerf-Bestellung testen. Legen Sie eine echte Testbestellung an und beobachten Sie, wie der gesamte Zap von Anfang bis Ende läuft, bevor Sie ihm vertrauen. Eine stille Automatisierung, die jede dritte Bestellung fallen lässt, ist schlimmer als gar keine Automatisierung, weil Sie aufhören zu prüfen. (Wenn dabei die Bestätigung einer Testbestellung verschwindet, ist das ein Problem der E-Mail-Zustellung, nicht von Zapier. Mit Resend Order Confirmation können Sie sie aus der Bestellung heraus erneut auslösen, während Sie die Ursache beheben.)
• Eine Woche lang den Aufgabenverlauf beobachten. Zapier protokolliert jeden Lauf; ein zurückschreibender Zap, der fehlschlägt, weil PrestaShop einen XML-Fehler zurückgegeben hat, bleibt sonst unauffällig liegen. Fünf Minuten am Montag reichen, um es zu bemerken.

Häufig gestellte Fragen

Gibt es wirklich keine PrestaShop-App bei Zapier?

Zum Zeitpunkt der Erstellung gibt es im Verzeichnis von Zapier keine von PrestaShop gepflegte App, weil PrestaShop selbst gehostet wird und über viele Versionen und Module hinweg läuft, gibt es keine einzelne Stelle, die eine solche App veröffentlichen und zertifizieren könnte. Stattdessen verbinden Sie sich über die integrierte Webservice-API von PrestaShop und die generischen Webhooks-by-Zapier-Schritte. Prüfen Sie das Verzeichnis auf aktuelle Drittanbieter-Connectoren, bevor Sie sie ausschließen, aber der Webservice-Weg ist der verlässliche No-Code-Pfad.

Ist die Verbindung von PrestaShop mit Zapier wirklich „No-Code“?

Für Lesen und Benachrichtigen, neue Bestellung an Slack, neuer Kunde in ein Tabellenblatt, ja, es sind nur Klicks: Webservice aktivieren, einen Schlüssel begrenzen und per Webhooks GET abfragen. Beim Zurückschreiben in Ihren Shop (Lagerbestand aktualisieren, Bestellstatus ändern) begegnet Ihnen etwas XML, weil der Webservice Änderungen als XML-Body akzeptiert und nicht als Formularfelder. Es gibt keine Schleifen oder Logik, aber es ist mehr als Blöcke zu ziehen. Das sollten Sie wissen, bevor Sie loslegen.

Wie bekomme ich PrestaShop-Bestellungen in Echtzeit nach Zapier?

Polling kann nie wirklich sofort sein, es prüft nach Ihrem Zeitplan (z. B. alle 15 Minuten). Für Echtzeit muss der Shop pushen: ein Webhook-Modul, das bei Bestellerstellung einen HTTP POST auslöst (über actionValidateOrder) und ihn an eine Zapier-Catch-Hook-URL sendet. Der PrestaShop-Kern hat keinen Sender für ausgehende Webhooks, daher braucht es ein Modul. Ein gutes Modul wird jedoch vollständig im Backoffice konfiguriert, indem Sie die Catch-URL einfügen.

Warum gibt mein Webservice-Aufruf 404 zurück?

Fast immer liegt es am URL-Rewriting. Der /api-Endpunkt des Webservice hängt von benutzerfreundlichen URLs und den Rewrite-Regeln in der von PrestaShop generierten .htaccess ab. Prüfen Sie, ob Shop-Parameter → Traffic & SEO → Benutzerfreundliche URL aktiv ist und ob Ihr Server tatsächlich umschreibt (manche Apache-Setups benötigen aktiviertes mod_rewrite). Das ist eine Servereinstellung, kein Code.

Warum gibt mein Webservice-GET nur ID-Nummern statt Bestelldetails zurück?

Es fehlt display=full. Ohne diesen Parameter gibt der Webservice eine Liste von Ressourcenverweisen zurück (nur IDs), nicht die Felder, die Sie zuordnen möchten. Fügen Sie &display=full zur URL hinzu oder verwenden Sie einen zweistufigen Abruf, erst die IDs auflisten, dann jede Bestellung per GET über ihre id abrufen.

Weiterführende Lektüre

• Zapier und Make für PrestaShop, Plattform auswählen und betreiben, inklusive Make-vs-Zapier-Vergleich
• E-Mail-Konfiguration in PrestaShop, warum Bestellbestätigungen in Ihr E-Mail-System gehören und nicht in einen Zap
• Wenn Ihr Shop aus manueller Arbeit herauswächst, das Signal, vom Klebeprozess zu einer echten Integration zu wechseln

Was das für Sie bedeutet

Das Versprechen „ohne Code zu schreiben“ hält dem Kontakt mit PrestaShop stand. Mit einer ehrlichen Korrektur: Es gibt keine Plug-and-go-App, deshalb verbinden Sie sich über die Webservice-API und die generischen Webhook-Schritte von Zapier. Für das Lesen aus Ihrem Shop und das Auslösen von Benachrichtigungen ist dieser Weg tatsächlich reine Klickarbeit. Beim Zurückschreiben in Ihren Shop werden Sie etwas XML sehen, und das sollten Sie vorher wissen, statt es mitten im Aufbau zu entdecken. Beginnen Sie mit einer einzigen pollingbasierten Leseautomatisierung, testen Sie sie mit einer Testbestellung und bauen Sie von dort aus weiter. Wenn Volumen oder bidirektionale Komplexität über das hinauswachsen, was ein Zap elegant tragen kann, ist das Ihr Signal für eine tiefere Integration. Nicht dafür, dass Sie den No-Code-Teil falsch gemacht haben.