--- title: "Shopware API: OAuth, Bestand, Webhooks | JustAutomate" description: "Technische Ebene der Shopware-Anbindung: OAuth-Token, Admin- und Store-API, Bestandsabgleich, Bestellstatus, Webhooks. Umsetzung in 2 bis 4 Wochen." url: "https://justautomate.ai/de/api/shopware/" lang: de --- Integrationen über Schnittstellen # Shopware API Bestand, Preis und Bestellstatus Diese Seite beschreibt die technische Ebene: OAuth-Token der Admin-API und seine kurze Gültigkeit, Trennung von Admin-API und Store-API, Schreiben von Bestand und Preis, Statuswechsel über die Zustandsmaschine, Webhooks und Massenläufe in Paketen. Hier geht es darum, wie man einen Shop anbindet, ohne dass er falsche Bestände zeigt. Kostenloses Erstgespräch [So läuft der Workshop ab](https://justautomate.ai/de/ki-beratung/) - 10 Minutenso lange gilt ein Zugangstoken der Admin-API, deshalb holt der Ablauf ihn bei Bedarf neu, statt ihn dauerhaft abzulegen - 15 bis 25 Sekundenvon der Bestellung im Shop bis zum Beleg im Rechnungswesen und zum Statuswechsel, in einem Ablauf ohne Freigabeschritt - 2 bis 4 Wochenvom Workshop bis zur produktiven Integration, geprüft an Ihren Bestellungen und Artikeldaten aus dem letzten Monat Das Problem ## Warum zeigt der Shop einen anderen Bestand als das Lager? Der Bestandsabgleich läuft im Takt, alle paar Minuten oder einmal in der Nacht. Zwischen zwei Läufen verkauft der Shop weiter, das Ladengeschäft verkauft auch, und der letzte Artikel geht zweimal raus. Der Kunde bekommt eine Absage, die Bestellung wird storniert, und im Lager sucht jemand nach einer Ware, die es nicht mehr gibt. Das liegt nicht an Shopware, sondern daran, dass es keine Regel dafür gibt, welches System beim Bestand recht behält. Der zweite Fehler ist leiser. Der Zugangstoken der Admin-API gilt nur kurz. Ein Skript, das ihn einmal holt und danach weiterverwendet, läuft eine Weile und hört dann ohne Ankündigung auf zu schreiben. Preise und Bestände bleiben stehen, im Shop sieht alles normal aus, und es fällt erst auf, wenn ein Kunde einen alten Preis bezahlt. Die Antwort mit dem abgelaufenen Token steht in einem Protokoll, das niemand ansieht. Die dritte Stelle ist der Massenlauf. Ein Import von mehreren tausend Artikeln in einem Schuss belastet die Datenbank und die Indexierung des Shops. Bei eigenem Hosting entscheidet Ihre Serverkonfiguration darüber, wie viele Anfragen pro Minute durchgehen, bei Shopware Cloud entscheidet der Anbieter. Ohne Warteschlange und ohne Paketgröße bricht der Lauf in der Mitte ab, und niemand weiß, welche Artikel schon aktualisiert sind. - Der letzte Artikel wird zweimal verkauft, weil der Abgleich im Takt läuft - Ein abgelaufener Token stoppt das Schreiben, ohne dass jemand es merkt - Der Massenimport bricht in der Mitte ab, der Stand ist danach unklar - Der Bestellstatus wird von Hand im Panel geklickt, einmal pro Bestellung - Ein Webhook kommt zweimal an und legt zwei Belege für dieselbe Bestellung an - Preise pflegt jemand parallel in Shopware und in der Tabelle des Einkaufs Warum jetzt ## Was macht Shopware selbst und was muss die Integration machen? Auf der Seite von Shopware steckt mehr, als eine erste Anbindung üblicherweise nutzt. Shopware 6 trennt zwei Schnittstellen: die Admin-API für alles, was sonst im Backend passiert, also Artikel, Preise, Bestände, Bestellungen, Kunden und Kategorien, und die Store-API für das Frontend, also Warenkorb, Suche und Kasse, auch für ein eigenes Frontend oder eine App. Dazu kommen Verkaufskanäle, Kundengruppen, Staffelpreise, der Rule Builder für Bedingungen und der Flow Builder, der auf Ereignisse im Shop reagiert. Der Rest liegt bei uns, und dort sitzt das Risiko: Auslöser, Feldzuordnung, Erneuerung des Tokens, Paketgröße für Massenläufe, Wiederholungen mit wachsendem Abstand, eine Warteschlange für abgelehnte Datensätze und Monitoring. Die Anmeldung läuft über OAuth 2.0 mit Client Credentials, also über einen Zugangsschlüssel aus dem Backend, der aus Client-ID und Geheimnis besteht. Die Rechte dieses Schlüssels, die verfügbaren Vorgänge und die Grenzen des Hostings prüfen wir in der [offiziellen Dokumentation der Shopware-API](https://developer.shopware.com/docs/resources/references/api-reference/) und auf Ihrer Installation, statt sie aus dem Gedächtnis zu setzen. Diese Seite ist technisch. Warum sich die Anbindung von Shop, Lager und Rechnungswesen überhaupt lohnt, steht auf der Seite zur [Prozessautomatisierung](https://justautomate.ai/de/prozessautomatisierung/), und wie wir Projekte insgesamt aufsetzen, auf der Seite zur [KI-Agentur](https://justautomate.ai/de/ki-agentur/). Hier sprechen wir über einzelne Vorgänge: was rausgeht, was zurückkommt und was passiert, wenn nichts zurückkommt. Dazu kommt der KI-Agent. BOND, unser Firmen-KI-Agent, liest die Daten über dieselbe Schnittstelle und antwortet in 5 bis 10 Sekunden, etwa auf die Frage, welche Artikel seit zwei Wochen ohne Bestand im Verkaufskanal stehen. Für die Integration ist ein Punkt wichtig: der Agent belastet denselben Shop. Lesende Zugriffe für Auswertungen holen wir deshalb aus dem Data Warehouse und nicht jedes Mal direkt aus Shopware. Was sich ändert ## Was hat die Person davon, die den Shop später betreut? - ### Ein Bestand, eine Quelle der Wahrheit Wir legen vor der Umsetzung fest, welches System beim Bestand recht behält, meist das ERP oder das Lager. Shopware bekommt den Wert geschrieben und rechnet ihn nicht selbst gegen. Reservierungen aus offenen Bestellungen ziehen wir vor dem Schreiben ab, damit der letzte Artikel nicht zweimal verkauft wird. Eine schriftliche Regel, welches System gewinnt, statt zweier Zahlen nebeneinander - ### Der Token läuft nicht heimlich ab Der Zugangstoken der Admin-API gilt nur wenige Minuten. Der Ablauf holt ihn bei Bedarf neu und wiederholt die Anfrage einmal, wenn die Antwort ihn als abgelaufen meldet. Client-ID und Geheimnis liegen im Secret-Speicher, nicht im Text des Szenarios und nicht in einer Testkopie. Erneuerung im Ablauf statt eines Skripts, das nach Wochen still stehen bleibt - ### Statuswechsel über die Zustandsmaschine Der Bestellstatus in Shopware ist kein Feld, das man überschreibt, sondern ein Übergang in einer Zustandsmaschine für Bestellung, Zahlung und Lieferung. Wir schreiben die erlaubten Übergänge auf und halten jeden Wechsel an, der in der aktuellen Lage nicht vorgesehen ist. Drei getrennte Zustände für Bestellung, Zahlung und Lieferung, nicht ein Statusfeld - ### Das Ereignis kommt an oder es meldet sich jemand Webhooks aus Shopware nehmen wir mit Prüfung der Signatur an und bestätigen den Empfang sofort. Die Verarbeitung läuft danach in einer Warteschlange. Dieselbe Bestellung kann zweimal gemeldet werden, deshalb prüfen wir vor dem Anlegen, ob es zu dieser Bestellnummer schon einen Beleg gibt. Prüfung vor dem Anlegen, damit ein doppeltes Ereignis keinen zweiten Beleg erzeugt - ### Massenläufe in Paketen, nicht in einem Schuss Preis- und Bestandsläufe schneiden wir in Pakete und schreiben sie über den Sync-Vorgang der Admin-API. Die Paketgröße legen wir im Piloten auf Ihrer Installation fest. Ein abgebrochener Lauf setzt an der Stelle fort, an der er stehen geblieben ist, statt von vorn zu beginnen. Fortsetzen statt Neubeginn, weil der Stand jedes Pakets gespeichert wird - ### Cloud und eigenes Hosting nach denselben Regeln Bei Shopware Cloud laufen Erweiterungen als Apps, bei eigenem Hosting kommen Plugins dazu. Die Integration bauen wir so, dass sie in beiden Fällen über die Schnittstelle arbeitet. Ein Wechsel des Hostings zwingt Sie dann nicht dazu, die Anbindung neu zu schreiben. Anbindung über die Schnittstelle statt über Code, der nur auf einem Server lebt Beleg ## Arbeiten Sie selbst so über Schnittstellen? Ja, und es sind die einzigen Belege, die wir ohne die Zustimmung eines Kunden zur Veröffentlichung seiner Zahlen zeigen können. Zwei KI-Agenten im Produktivbetrieb in den Unternehmen unserer Gründer, beide im März 2026 gestartet. Unten stehen die Zahlen samt dem, was sie NICHT belegen. Bei uns selbst umgesetzt. Das sind keine Kundenprojekte, sondern Umsetzungen in den eigenen Unternehmen der Gründer. Wir sagen das offen, denn ein Beleg, den man nicht prüfen kann, ist keiner. - ![JustIdea Agency](https://justautomate.ai/klienci/justidea.png)![JustBot](https://justautomate.ai/agenci/justbot-80.webp)JustBotihr Agent JustIdea Agency, Performance-Marketing-Agentur mit rund 30 Personen 23 Personen aus der Firma arbeiten mit dem Agenten 38 dauerhaft angebundene Systeme 112 Prozesse laufen ohne Menschen 475 Tausend Zeilen Agenten-Code Ein Agent, verbunden mit dem CRM, den Formularen auf der Website, den Werbesystemen, Slack und dem Data Warehouse, ausschließlich über Schnittstellen. Authentifizierung über Token, Schreiben über die Schnittstelle, Ereignisse werden Sekunden nach dem Auslösen verarbeitet. 8 von 38 Systemen, in denen er arbeitet - Google Ads - Meta Ads - HubSpot - ActiveCollab - Ahrefs - GA4 - Search Console - BigQuery Vorher Datensätze entstanden von Hand, es gab also nichts zu protokollieren: niemand wusste, wie viele Operationen täglich durchlaufen, wie viele scheitern und woran. Nachher Jede Operation läuft über die Schnittstelle und hinterlässt einen Eintrag im Log, mit Art des Aufrufs und Ergebnis. Erst das erlaubte es, Limits, Fehler und den Anteil ohne Menschen zu zählen. 64.903 Werkzeugaufrufe in 30 Tagen, davon 29.854 ohne Menschen, darunter 3.432 Operationen auf Leads und 1.301 auf Formularanfragen - ![Surf Inc.](https://justautomate.ai/klienci/surf-inc.svg)![SurfBot](https://justautomate.ai/agenci/surfbot-80.webp)SurfBotihr Agent Surf Inc., Premium-Bekleidungsmarke mit Onlineshop und zwei stationären Geschäften 16 Personen aus der Firma arbeiten mit dem Agenten 21 dauerhaft angebundene Systeme 89 Prozesse laufen ohne Menschen 323 Tausend Zeilen Agenten-Code Ein Agent, verbunden mit dem Bestellsystem, dem ERP, dem Shop, dem Data Warehouse und den Werbesystemen. Start im März 2026, voller Betrieb ab Mai. Sechzehn Personen nutzen ihn, Lager und Ladenpersonal eingeschlossen. 8 von 21 Systemen, in denen er arbeitet - PrestaShop - BaseLinker - Comarch Optima - BigQuery - Google Ads - Meta Ads - GA4 - Zalando Vorher Von Februar bis August 2025 kam jede Einheit Werbebudget als 3,53 Online-Umsatz zurück, und Werbung verschlang 28,3 Prozent dieses Umsatzes. Nachher In denselben Monaten 2026 liegt die Kennzahl bei 4,19, und der Werbeanteil am Umsatz sank auf 23,9 Prozent. Das Werbebudget ist 6,9 Prozent niedriger bei 10,3 Prozent höherem Umsatz. Werbe-Rendite von 3,53 auf 4,19, also 18,5 Prozent höher, bei einem um 6,9 Prozent niedrigeren Budget Und bei Ihnen ## Was, wenn wir die Shopware-Anbindung selbst bauen? Vier Sätze hören wir von technischen Ansprechpartnern am häufigsten, und das ist unsere Antwort darauf. Wenn Ihrer anders lautet, sagen Sie ihn im Erstgespräch: schneller lässt sich nicht klären, ob es hier überhaupt etwas zu besprechen gibt. Kunden- und Bestelldaten verarbeiten wir nach der [Verordnung 2016/679](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679). In den Orchestrator gehen deshalb nur die Felder, die der jeweilige Vorgang braucht, und für Auswertungen arbeiten wir mit Bestell- und Artikelnummern statt mit Namen und Adressen. - Wir haben ein Plugin, das den Bestand schreibt, das läuft seit einem Jahr. Dann schreiben wir es nicht neu. Wir prüfen vier Dinge daran: ob es den Token erneuert, ob es nach einem Fehler wiederholt und mit welchem Abstand, ob es Reservierungen aus offenen Bestellungen abzieht und ob jemand merkt, wenn es aufhört zu schreiben. Was diese Liste besteht, bleibt. Meistens fehlt die letzte Antwort, denn Monitoring baut niemand für ein Plugin, das ja läuft. - Wir geben keiner externen Firma Zugang zu unserem Shop. Müssen Sie auch nicht. Den Zugangsschlüssel legen Sie selbst im Backend an, mit einer Rolle, die nur die Rechte hat, die der Vorgang braucht, und entziehen ihn mit einem Klick. Während der Umsetzung arbeiten wir auf einer getrennten Installation oder einem Testverkaufskanal. Den produktiven Schlüssel legen Sie selbst in den Secret-Speicher, ohne ihn uns per E-Mail zu schicken. - Unsere Agentur betreut den Shop, die macht das mit. Oft stimmt das, und wir sagen es offen. Dann endet der Workshop mit einer Spezifikation, die Ihre Agentur ohne uns umsetzt: Liste der Vorgänge, Zuordnung der Felder, Regeln für Bestand und Preis, erlaubte Statusübergänge, Plan für Fehler und Testfälle. Wir bleiben höchstens für die Durchsicht und die Einrichtung der Überwachung. - Wir sind auf Shopware Cloud, da geht so etwas doch gar nicht. Die Schnittstelle gibt es in beiden Betriebsarten. Der Unterschied liegt woanders: bei eigenem Hosting können Sie Plugins installieren und die Serverkonfiguration ändern, in der Cloud arbeiten Erweiterungen als Apps und der Anbieter setzt die Grenzen. Wir bauen die Logik deshalb außerhalb des Shops, in n8n, Make oder eigenem Code, und der Shop bleibt der Ort für Artikel und Bestellungen. Shopware-Schnittstellen Admin-API, Store-API, Sync-Vorgang für Massenschreiben, Webhooks, Flow Builder, Rule Builder Shop-Objekte Artikel und Varianten, Bestände, Preise und Staffelpreise, Kategorien, Kunden, Kundengruppen, Bestellungen, Verkaufskanäle Warenwirtschaft und Rechnungswesen Xentral, JTL, DATEV, sevDesk, lexoffice, SAP Business One CRM, Zahlung und Versand HubSpot, Pipedrive, Salesforce, Stripe, Mollie, DHL, DPD, GLS Automatisierungsschicht n8n, Make, Zapier, eigene Anbindungen in Node.js oder Python Daten und Überwachung BigQuery, SQL-Datenbanken, Google Sheets, Power BI, Meldungen in Slack und Microsoft Teams ## Vorgänge an der Shopware-API: wie wir sie umsetzen und worauf wir achten Sieben Vorgänge, aus denen die meisten Shop-Integrationen bestehen. Die dritte Spalte nennt die Stellen, an denen solche Anbindungen am häufigsten brechen, damit ein Projekt nicht mit dem eigenen doppelt verkauften Artikel anfängt. | Vorgang | Wie wir es umsetzen | Worauf wir achten | | --------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Anmeldung | OAuth 2.0 mit Client Credentials, Zugangsschlüssel aus dem Shopware-Backend | der Token gilt nur Minuten, der Ablauf erneuert ihn selbst; Client-ID und Geheimnis liegen im Secret-Speicher | | Artikel lesen | Suche über Kriterien mit Filter, Sortierung und ausdrücklicher Feldliste | verknüpfte Daten wie Preise und Bestände kommen nur mit, wenn sie angefordert werden; die Feldliste gehört zum Datenvertrag | | Bestand und Preis schreiben | gezieltes Aktualisieren einzelner Felder, Massenläufe über den Sync-Vorgang | die Kennung eines Datensatzes ist ein Hexadezimalwert und keine Artikelnummer; der Abgleich läuft über die Artikelnummer aus dem ERP | | Bestellung lesen | Bestellung mit Positionen, Kunde, Lieferung und Zahlung in einem Vorgang holen | die Umsatzsteuer-Identifikationsnummer entscheidet über Geschäfts- oder Privatkunde und muss vor dem Beleg geprüft werden | | Bestellstatus | Übergang in der Zustandsmaschine, getrennt für Bestellung, Zahlung und Lieferung | ein nicht vorgesehener Übergang wird abgelehnt; die erlaubten Wege schreiben wir vor der Umsetzung auf | | Ereignisse | Webhook auf Bestellung, Artikel und Kunde, mit Prüfung der Signatur und sofortiger Bestätigung | die Reihenfolge ist nicht garantiert und dasselbe Ereignis kann zweimal kommen; verarbeitet wird in einer Warteschlange | | Massenlauf und Limits | Pakete fester Größe, Abstand zwischen den Anfragen, Wiederholung mit wachsender Pause | die Grenze setzt Ihr Hosting oder der Cloud-Anbieter, nicht eine Zahl aus einem Forenbeitrag; wir messen sie im Piloten | Wie viele Anfragen pro Minute Ihre Installation verträgt, hängt bei eigenem Hosting von Server und Datenbank ab und bei Shopware Cloud vom Anbieter. Wir übernehmen dafür keine Zahl aus zweiter Hand, sondern messen sie im Piloten und bauen die Warteschlange auf das Ergebnis. Die verfügbaren Vorgänge und die Struktur der Anfragen nehmen wir aus developer.shopware.com. Wie wir arbeiten ## Fünf Schritte von der ersten Anfrage bis zur produktiven Integration Jeder Schritt endet mit etwas, das Sie beurteilen können, bevor Sie über den nächsten entscheiden. Erst der Prozess. Dann die Werkzeuge. 1. ### Workshop und Durchsicht der Schnittstelle Wir halten fest, welches System beim Bestand und beim Preis recht behält, was einen Statuswechsel auslöst, welche Felder in die Anfrage gehen und welche Fälle keine eindeutige Regel haben: Vorbestellung, Set aus mehreren Artikeln, Rücksendung nach zwei Monaten, Verkauf ins Ausland ohne Umsatzsteuer-Identifikationsnummer. Technisch prüfen wir die Rechte des Zugangsschlüssels, die Betriebsart und die Grenzen des Hostings. 2. ### Feldzuordnung und Entwurf der Absicherung Wir legen die Zuordnung von Artikelnummer, Bestand, Preis und Bestellung fest, dazu die erlaubten Statusübergänge, den Schlüssel für die Prüfung vor dem Anlegen und den Ort für das Verzeichnis der Paare aus Bestellung und Beleg. Dazu kommen die Regeln für Wiederholungen und die Liste der Vorgänge, die kein Automat allein ausführt. Diese Liste entsteht vor der Wahl des Werkzeugs, nicht danach. 3. ### Pilot auf einer getrennten Installation Der Ablauf läuft neben der bisherigen Arbeitsweise, mit den Bestellungen und Artikeldaten des letzten Monats, auf einer Testinstallation oder in einem Testverkaufskanal mit eigenem Zugangsschlüssel. Wir prüfen die schweren Fälle, nicht die leichten: doppeltes Ereignis, abgelaufener Token, abgebrochener Massenlauf, nicht erlaubter Statusübergang, letzter Artikel bei gleichzeitiger Bestellung. 4. ### Produktion, Monitoring und Übergabe Wir schalten produktiv, mit Alarm auf abgelehnte Datensätze und auf jede Anfrage, die nach drei Wiederholungen keine Antwort bekommt. Den produktiven Zugangsschlüssel legen Sie selbst in den Secret-Speicher. Bei Ihnen bleiben der Ablauf, die Beschreibung der Felder, die Liste der Statusübergänge und eine Anleitung für den Fehlerfall, damit Sie einen weiteren Verkaufskanal ohne uns anschließen. 5. ### Messung nach 30 und 90 Tagen Wir sehen uns vier Zahlen an: wie viele Bestellungen ohne Menschen durchgelaufen sind, wie viele Datensätze in der Warteschlange zur Prüfung landeten, wie viele Anfragen eine Wiederholung brauchten und wie oft der Bestand im Shop vom Lager abwich. Die letzte Zahl soll gegen null gehen. Erst auf dieser Grundlage sprechen wir über den nächsten Umfang. Vorher und nachher ## Wie sich die Woche der Person ändert, die den Shop betreut ### Vorher - Morgens die Laufhistorie durchsehen und nach abgebrochenen Läufen suchen - Nach der Beschwerde eines Kunden herausfinden, warum ein Artikel doppelt verkauft wurde - Den Bestellstatus im Backend von Hand klicken, einmal je Bestellung - Preise parallel in Shopware und in der Tabelle des Einkaufs pflegen ### Nachher - Ein abgelehnter Datensatz kommt als Meldung mit Fehlertext und Artikelnummer - Der Bestand kommt aus einem System, Reservierungen sind vor dem Schreiben abgezogen - Der Statuswechsel läuft aus dem Lager oder aus dem Rechnungswesen zurück in den Shop - Ein abgebrochener Massenlauf setzt am letzten bestätigten Paket fort Die ersten Bestellungen ohne Menschen sehen Sie am Tag der Umschaltung. Die Zahl der Meldungen in der Warteschlange und die Abweichung zwischen Shop und Lager beurteilen wir nach 30 Tagen, die Stabilität der Integration nach 90. Für die entscheidende Person ## Was die Person davon hat, die für Shop und Systeme verantwortlich ist Sie bekommen eine Integration, die eine Beschreibung hat und nicht nur einen Autor. Feldzuordnung, Regel für den Bestand, erlaubte Statusübergänge und die Regeln für Wiederholungen sind schriftlich festgehalten, damit die nächste Person die Logik nicht aus der Ansicht eines Szenarios rekonstruieren muss. Jeder Vorgang, der ohne Menschen läuft, hinterlässt eine Spur: was ihn ausgelöst hat, welcher Datensatz betroffen war und was die Antwort des Shops war. Der zweite Punkt betrifft das Risiko Ihrer Unterschrift. Den Zugangsschlüssel legen Sie selbst an und entziehen ihn selbst, die Tests laufen auf einer getrennten Installation, und der Pilot läuft neben der bisherigen Arbeitsweise, sodass der alte Weg bis zum Ende der Prüfung funktioniert. Der Umfang ist eng, eine Integration, also ist die erste Entscheidung klein und umkehrbar. - Feldzuordnung und erlaubte Statusübergänge schriftlich, nicht im Szenario versteckt - Zugangsschlüssel bei Ihnen angelegt, im Secret-Speicher, mit einem Klick entzogen - Pilot auf Testinstallation oder Testverkaufskanal, der produktive Shop bleibt unberührt - Alarm auf abgelehnte Datensätze und ausbleibende Antworten ab dem ersten Tag Kosten ## Der Workshop hat einen offenen Preis, die Umsetzung ein Angebot danach Der Prozess-Workshop kostet **3.500 EUR netto pro Woche** und dauert 1 bis 7 Wochen. Bei einer einzelnen Shop-Integration reicht meist eine Woche, weil der Umfang eng ist, aber die Ausnahmen gehören trotzdem aufgeschrieben: Sets und Varianten, Vorbestellungen, Rücksendungen, mehrere Verkaufskanäle, Verkauf ins Ausland. Die Integration selbst kalkulieren wir nach dem Workshop, wenn feststeht, wie viele Auslöser im Umfang liegen und in welchem Zustand die Artikeldaten sind. Mehr zum Ablauf steht auf der Seite zur [KI-Beratung](https://justautomate.ai/de/ki-beratung/). Die Lizenz für Shopware und die Betriebskosten des Ablaufs zahlen Sie direkt beim Anbieter, etwa bei n8n oder Make, oder gar nicht, wenn der Ablauf auf Ihrer Infrastruktur läuft. Beim KI-Agenten kommt der Verbrauch der Sprachmodelle dazu, beim Anbieter üblicherweise 0,005 bis 0,07 EUR pro Anfrage. Ohne Aufschlag von uns und ohne Weiterverkauf von Lizenzen. - ### Prozess-Workshop 3.500 EUR netto pro Woche, bei einer Shop-Integration reicht meist eine Woche Abgeschlossene Einheit. Endet mit einem technischen Dokument, das Sie selbst umsetzen oder einem anderen Dienstleister geben können. - Liste der Vorgänge und Zuordnung der Felder zwischen Shop, Lager und Rechnungswesen - Regel für Bestand und Preis: welches System behält recht und was passiert bei Abweichung - Erlaubte Statusübergänge, Behandlung doppelter Ereignisse und Plan für Massenläufe - Liste der Vorgänge, die beim Menschen bleiben, mit Begründung je Fall Mit dem Workshop anfangen - Am häufigsten gewählt ### Workshop und Integration Angebot nach dem Workshop der Umfang ergibt sich aus der Zahl der Auslöser und dem Zustand der Artikeldaten Die am häufigsten gewählte Variante. Laufende Integration in 2 bis 4 Wochen nach dem Workshop, geprüft an Ihren Bestellungen. - Alles aus dem Workshop - Ablauf in n8n, Make oder eigenem Code, verbunden mit Shopware, Lager und Rechnungswesen - Bestandsabgleich, Preisläufe in Paketen und Statuswechsel über die Zustandsmaschine - Webhooks mit Signaturprüfung, Warteschlange für abgelehnte Datensätze, Wiederholungen - Pilot auf Testinstallation, Umschaltung mit Monitoring, Übergabe der Beschreibung Über die Umsetzung sprechen - ### Integration und KI-Agent Angebot nach dem Workshop für Händler, die mehrmals täglich nach Beständen, Margen und Bestellungen fragen Alles aus der Integration und dazu BOND, der Firmen-KI-Agent, der Fragen zum Shop in normalen Sätzen beantwortet. - Alles aus der Shopware-Integration - Befüllung des Data Warehouse einmal täglich, damit Lesezugriffe den Shop nicht belasten - Antwort in 5 bis 10 Sekunden: was ohne Bestand steht, was liegen bleibt, was zurückkommt - Rund 2 Monate bis zum produktiven Betrieb des Agenten, unabhängig von der Integration Nach dem Agenten fragen Der Workshop endet mit einem Dokument, das ohne uns Bestand hat: Liste der Vorgänge, Zuordnung der Felder und Regeln für Bestand, Preis und Status. Stellt sich heraus, dass eine Korrektur an Ihrem vorhandenen Ablauf reicht, sagen wir das und zeigen die Stelle, statt eine Umsetzung von null zu verkaufen. ## Häufige Fragen Wie authentifiziert sich eine Integration an der Shopware Admin-API? Über OAuth 2.0 mit Client Credentials. Im Backend legen Sie unter den Einstellungen eine Integration an und bekommen einen Zugangsschlüssel aus Client-ID und Geheimnis. Damit holt der Ablauf einen Zugangstoken, der nur wenige Minuten gilt und danach erneuert werden muss. Genau das übersehen Skripte am häufigsten: sie holen den Token einmal und hören nach seinem Ablauf still auf zu schreiben. Client-ID und Geheimnis legen wir in den Secret-Speicher, nicht in den Text des Szenarios. Was ist der Unterschied zwischen Admin-API und Store-API? Die Admin-API bedient alles, was sonst im Backend passiert: Artikel, Varianten, Preise, Bestände, Kategorien, Kunden und Bestellungen. Die Store-API bedient das Frontend, also Warenkorb, Produktsuche und Kasse, und wird für ein eigenes Frontend oder eine App genutzt. Für die Anbindung an Lager, Rechnungswesen und CRM arbeiten wir fast immer mit der Admin-API. Die Store-API kommt ins Spiel, wenn der Shop ein eigenes Frontend bekommt oder ein anderes System im Namen des Kunden bestellt. Gibt es Webhooks in Shopware und wie sichern wir sie ab? Ja. Shopware kann bei Ereignissen im Shop eine Anfrage an eine Adresse senden, etwa bei einer neuen Bestellung oder einer Änderung am Artikel, und der Flow Builder kann solche Abläufe zusätzlich steuern. Wir prüfen bei jeder eingehenden Anfrage die Signatur, bestätigen den Empfang sofort und verarbeiten danach in einer Warteschlange. Die Reihenfolge ist nicht garantiert und dasselbe Ereignis kann zweimal kommen, deshalb prüfen wir vor dem Anlegen eines Belegs, ob es ihn zu dieser Bestellnummer schon gibt. Wie ändert die Integration den Bestellstatus? Nicht durch Überschreiben eines Feldes. Shopware führt getrennte Zustände für Bestellung, Zahlung und Lieferung, und jeder Wechsel ist ein Übergang in einer Zustandsmaschine. Ein Übergang, der in der aktuellen Lage nicht vorgesehen ist, wird abgelehnt. Wir schreiben die erlaubten Wege vor der Umsetzung auf und halten jeden Wechsel an, der nicht darauf steht, statt ihn zu erzwingen. Der Statuswechsel läuft dann aus dem Lager oder aus dem Rechnungswesen zurück in den Shop. Wie aktualisieren wir mehrere tausend Artikel, ohne den Shop zu bremsen? In Paketen und über den Sync-Vorgang der Admin-API, der mehrere Datensätze in einer Anfrage schreibt. Die Paketgröße legen wir im Piloten auf Ihrer Installation fest, denn sie hängt von Server, Datenbank und der Indexierung des Shops ab. Zwischen den Paketen liegt ein Abstand, nach einem Fehler wiederholt der Ablauf mit wachsender Pause, und der Stand jedes bestätigten Pakets wird gespeichert. Ein abgebrochener Lauf setzt damit fort, statt von vorn zu beginnen. Wie viele Anfragen pro Minute verträgt die Shopware-API? Das hängt von Ihrer Installation ab und nicht von einer allgemeinen Zahl. Bei eigenem Hosting entscheiden Server, Datenbank und die Einstellungen Ihres Betriebs, bei Shopware Cloud setzt der Anbieter die Grenzen. Wir übernehmen deshalb keinen Wert aus zweiter Hand, sondern messen im Piloten, wie viel durchgeht, ohne dass die Antwortzeiten des Shops steigen. Auf dieses Ergebnis hin bauen wir die Warteschlange, und Massenläufe legen wir außerhalb der Verkaufsspitzen. Funktioniert das auch mit Shopware Cloud statt mit eigenem Hosting? Ja, die Schnittstelle gibt es in beiden Betriebsarten. Der Unterschied liegt bei den Erweiterungen und bei den Grenzen: in der Cloud arbeiten Erweiterungen als Apps und der Anbieter bestimmt, was möglich ist, bei eigenem Hosting kommen Plugins und die eigene Serverkonfiguration dazu. Wir bauen die Logik deshalb außerhalb des Shops, in n8n, Make oder eigenem Code. Ein Wechsel des Hostings zwingt Sie dann nicht dazu, die Anbindung neu zu schreiben. Brauchen wir dafür ein eigenes Plugin oder eine App? Meistens nicht. Bestandsabgleich, Preisläufe, Bestellexport und Statuswechsel laufen über die Admin-API, also ohne Code im Shop. Eine App oder ein Plugin lohnt sich erst, wenn etwas im Shop selbst anders aussehen oder rechnen soll, etwa eine eigene Anzeige im Backend oder eine Preislogik im Warenkorb. Diese Grenze ziehen wir im Workshop, denn Code im Shop bindet Sie an eine Version und an denjenigen, der ihn geschrieben hat. ## Prüfen wir, ob Ihr Shop den letzten Artikel zweimal verkaufen kann Das Erstgespräch dauert 30 Minuten und ist kostenlos. Sie beschreiben, welches System heute den Bestand führt, womit der Abgleich gebaut ist und wer den Bestellstatus setzt. Sie gehen mit einer Antwort auf drei Fragen heraus: ob ein doppeltes Ereignis zwei Belege erzeugen kann, was passiert, wenn der Token abläuft, und wer es merkt, wenn der Abgleich stehen bleibt. Einen Zugang zu einem System brauchen wir dafür nicht. Wir führen höchstens 2 Umsetzungen gleichzeitig, damit bei jeder tatsächlich jemand sitzt. [Kostenloses Erstgespräch](https://justautomate.ai/de/kontakt/) **PS.** Wenn Ihr Bestandsabgleich im Takt läuft und Reservierungen aus offenen Bestellungen nicht abzieht, dann ist genau das der Punkt. Ein doppelt verkaufter Artikel kostet eine Stornierung, eine Entschuldigung und einen Kunden, der beim nächsten Mal woanders bestellt. ## Verwandt - [Xentral API](https://justautomate.ai/de/api/xentral/) - [sevDesk API](https://justautomate.ai/de/api/sevdesk/) - [Lexoffice API](https://justautomate.ai/de/api/lexoffice/) - [HubSpot API](https://justautomate.ai/de/api/hubspot/) - [Prozessautomatisierung](https://justautomate.ai/de/prozessautomatisierung/) - [KI-Beratung mit Umsetzung](https://justautomate.ai/de/ki-beratung/) --- **JustAutomate** · Kontakt: contact@justautomate.ai · Formular: https://justautomate.ai/de/kontakt/