App oder Plugin in Shopware
Eine App bekommt Schreib-Webhooks für 11 von 247 Entitäten. Die Zahl ist in 6.6 und 6.7 gleich — der Mechanismus dahinter nicht, und darauf kommt es an.
Die Frage wird meist mit Betriebsargumenten beantwortet: Apps laufen außerhalb, sind cloud-tauglich, brauchen keinen Code im Shop. Das stimmt und reicht nicht, weil es die eine Frage auslässt, an der Projekte scheitern: Kommt die App überhaupt an die Daten, um die es geht?
Dafür gibt es eine Zahl.
Die Zahl
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| DAL-Entitäten insgesamt | 228 | 247 |
| davon mit Schreib-Webhook für Apps | 11 | 11 |
| Business-Events (Flow-Auslöser) | 95 | 96 |
Die elf sind:
product · product_price · category · sales_channel ·
sales_channel_domain · customer · customer_address · order ·
order_address · document · media
Eine App erfährt also von Schreibvorgängen an den Kerndaten des Shops — und an nichts sonst. Keine Bestellposition, keine Zahlungstransaktion, kein Lieferstatus, keine Eigenschaft, kein Regelwerk, nichts aus einer anderen Erweiterung.
Der eigentliche Unterschied liegt nicht in der Zahl
In beiden Versionen sind es elf. Was sich geändert hat, ist der Weg dorthin:
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| Herkunft der Liste | feste Konstante im Kern | DI-Tag shopware.entity.hookable |
| von außen erweiterbar | nein | ja |
In 6.6 ist die Liste geschlossen. Wer eine zwölfte Entität braucht, kann nichts tun — außer den Kern zu ändern.
In 6.7 ist sie ein Tag. Eine Erweiterung kann ihre eigene Entität damit versehen, und die App bekommt Webhooks dafür.
Der Haken: Diesen Tag zu setzen braucht PHP-Code im Shop — also ein Plugin. Die Öffnung hilft damit nicht der App allein, sondern dem Gespann aus App und Plugin. Für eine reine Cloud-Installation ohne Plugins bleibt es bei elf.
Das ist die Nuance, die in dieser Entscheidung am häufigsten fehlt: Ab 6.7 lautet die Frage nicht mehr „App oder Plugin", sondern oft „App mit einem kleinen Plugin oder Plugin allein".
Was eine App sonst deklarieren kann
Die Webhooks sind nur ein Teil. Das App-Manifest kennt daneben unter anderem Verwaltungsmodule und Action Buttons, eigene Zahlungs- und Versandarten, Steuer-Anbieter, Regelbedingungen, Custom-Field-Sets, Cookie-Einträge, CMS-Bausteine, Storefront-Erweiterungen und Gateways für Checkout und Kontext.
Die App-Oberfläche ist also keineswegs schmal — sie ist nur deklarativ. Was im Manifest vorgesehen ist, geht; was nicht vorgesehen ist, geht nicht. Ein Plugin kennt diese Grenze nicht, weil es im selben Prozess läuft wie der Kern.
Die Entscheidung
| Frage | Antwort |
|---|---|
| Zielumgebung ist Shopware Cloud | App — Plugins sind dort nicht installierbar |
| Die Logik braucht Daten außerhalb der elf Entitäten | Plugin, oder App plus kleines Plugin ab 6.7 |
| Es geht um Zahlung, Versand, Steuern, Regelbedingungen | App genügt — dafür gibt es Manifest-Einträge |
| Die Logik muss synchron im Bestellprozess greifen | Plugin — ein Webhook ist asynchron |
| Der Dienst soll mehrere Shops bedienen | App — eine Instanz, viele Shops |
| Es gibt keinen Server für den Betrieb | Plugin — eine App braucht einen |
| Die Erweiterung soll in den Store | beides möglich; die Zielumgebung der Kunden entscheidet |
Die Zeile mit dem Bestellprozess wird am häufigsten unterschätzt. Webhooks sind asynchron. Was eine Bestellung verhindern oder vor dem Abschluss verändern soll, kann kein Webhook leisten. Was Shopware bei Webhooks selbst regelt — Wiederholungen, Abschaltung nach Fehlern —, steht in Webhooks in Shopware 6.
Was wir selbst tun
Pixup baut beides und verkauft Plugins im Shopware Store. Das ist der Grund, warum dieser Text keine Empfehlung für eine der beiden Seiten enthält: Wir würden uns damit selbst widersprechen.
Was wir in Projekten tatsächlich zuerst fragen, ist die eine Zeile oben — liegt die gebrauchte Entität auf der Elferliste. Fällt die Antwort nein aus und soll es ohne Code im Shop gehen, erübrigt sich der Rest der Tabelle.
Nachtrag: der Unterschied beim Entfernen
Ergänzt am 18. September 2026 aus einer Messung des Plugin-Lebenszyklus.
Die Entscheidung oben betrachtet, was beide Wege können. Ein Kriterium fehlte: was passiert, wenn man sie wieder loswird.
Für ein Plugin ist der Ablauf gemessen. Deaktivieren ändert genau ein Feld —
Tabellenzahl, Systemkonfiguration und Produktdaten bleiben unverändert.
Deinstallieren entfernt dagegen Migrationen, Plugintabellen, die gesamte
Plugin-Konfiguration sowie Custom Entities und Custom Fields des Plugins. Der
Standardwert der Option keepUserData ist false, der destruktive Weg also die
Voreinstellung.
Das ist ein Argument, das in der Abwägung selten auftaucht und in Projekten teuer wird: Custom Fields enthalten Händlerdaten, nicht Plugindaten. Wer Felder braucht, die eine Erweiterung überleben sollen, legt sie ohne Erweiterung an.
Grenzen dieser Messung## Grenzen dieser Messung
Gezählt wurden die Entitäten mit Schreib-Webhook, die DAL-Entitäten und die Business-Events zweier Installationen, dazu die Deklarationsmöglichkeiten des Manifests. Nicht gemessen wurden Laufzeit, Zustellzuverlässigkeit oder Betriebsaufwand einer App im Vergleich zu einem Plugin — das sind eigene Fragen und brauchen einen laufenden Dienst, keinen Kernel-Dump.
Wenn Sie vor dieser Entscheidung stehen, gehört sie zu App- und Plugin-Entwicklung.
Häufige Fragen
- Für welche Entitäten bekommt eine App Schreib-Webhooks?
- Für elf: product, product_price, category, sales_channel, sales_channel_domain, customer, customer_address, order, order_address, document und media. Gemessen in 6.6.10.6 und 6.7.13.1, in beiden dieselbe Liste.
- Kann eine App eigene Entitäten hookbar machen?
- Nicht aus sich heraus. Ab 6.7 kann eine Erweiterung eine Entität über einen DI-Tag hookbar machen — das setzt aber ein Plugin voraus, weil es PHP-Code im Shop braucht.
- Läuft eine App im Shop?
- Nein, sie läuft auf einem eigenen Server und wird über Webhooks und die API angesprochen. Genau daraus folgen ihre Vorteile — kein Code im Shop, cloud-tauglich — und ihre Grenzen.
- Was ist mit Shopware Cloud?
- Dort sind Plugins nicht installierbar, Apps schon. Wenn Cloud die Zielumgebung ist, entfällt die Frage weitgehend — dann entscheidet nicht, was besser wäre, sondern was geht.