// stack · schnittstelle
weclapp ist ein Cloud-ERP mit CRM aus Deutschland — Artikel, Preise, Kunden und Aufträge liegen dort in einem System. Für siteway ist das der Anfang einer geraden Linie: Der Katalog kommt über die REST-API auf die Website, und die Anfrage von der Website geht denselben Weg zurück. Diese Seite beschreibt, wie wir diese Verbindung bauen — und warum die Website die Daten spiegelt, statt sie durchzureichen.
// definition
weclapp ist ein cloudbasiertes ERP-System der weclapp SE mit Sitz in Marburg. Es läuft im Browser, ohne Installation, und bündelt in einer Oberfläche, was in vielen Betrieben auf drei oder vier Programme verteilt ist: CRM, Einkauf und Disposition, Lagermanagement, die Auftragsverwaltung von der Anfrage bis zur Abrechnung, Produktion, E-Commerce, Finanzbuchhaltung, Projektmanagement und E-Rechnung. Erweiterungen wie Helpdesk, Vertragsmanagement, eine mobile Lager-App und eine Kassensoftware kommen dazu.
Angesprochen sind kleine und mittlere Unternehmen — Handel, Fertigung, Dienstleistung —, die eine Software wollen, die ohne eigenen Server auskommt. Als Speicherort nennt weclapp ein nach ISO 27001 und PCI DSS zertifiziertes Rechenzentrum in Frankfurt am Main, dazu eine Mindestverfügbarkeit von 99,5 Prozent und eine durchgehend verschlüsselte Übertragung. Für Unternehmen mit klaren Vorgaben zum Datenstandort ist das oft das Argument, das den Ausschlag gibt.
Für eine Website zählt jedoch etwas anderes: Es gibt eine dokumentierte Schnittstelle nach draußen. weclapp stellt eine REST-API bereit, die JSON spricht, dazu Webhooks, die melden, wenn sich ein Datensatz ändert. Damit ist der Artikelstamm keine Excel-Liste mehr, die jemand einmal im Quartal exportiert, sondern eine Schnittstelle, an der man bauen kann.
// praxis
spiegeln · nicht durchreichen
Die wichtigste Entscheidung fällt vor der ersten Zeile Code: Die Website fragt das ERP nicht bei jedem Seitenaufruf. Wir spiegeln die Artikel im festen Takt in das Datenmodell des CMS — als eigene Inhaltsart mit eigenen Feldern, eigener URL und eigener Sortierung. Ausgeliefert wird danach aus dem eigenen Bestand. Das hält die Seite schnell, macht sie unabhängig von der Erreichbarkeit des ERP und sorgt dafür, dass eine Wartung beim Anbieter keinen leeren Produktkatalog produziert. Live geht nur, was live sein muss.
Dann kommt das Feld-Mapping. Ein Artikel in weclapp trägt sehr viele Eigenschaften; eine Website braucht davon einen bewussten Ausschnitt. Wir legen fest, welches ERP-Feld auf welches Website-Feld geht, was Pflicht ist, was optional bleibt und was das Haus gar nicht erst verlässt — Einkaufspreise, Kalkulationen, Lieferantenzuordnungen und interne Notizen gehören nicht in ein öffentliches JSON. Dieselbe Sorgfalt gilt für die Artikelnummer: Sie ist der Schlüssel, über den der zweite Lauf den Artikel wiedererkennt und aktualisiert, statt eine Dublette anzulegen.
Bilder und Dokumente ziehen wir beim Abgleich auf den eigenen Server, statt sie live aus dem ERP zu verlinken. Danach laufen sie durch dieselbe Bildpipeline wie der Rest der Website: skaliert, als AVIF und WebP ausgespielt, mit Maßen im Markup. Ein Datenblatt als PDF liegt danach auf der eigenen Domain — auffindbar, verlinkbar, unabhängig von einem fremden System.
Aktualisiert wird zweigleisig: ein geplanter Abgleich als Grundsicherung plus Webhooks für den schnellen Weg. weclapp meldet dabei nur, dass sich etwas geändert hat — Kennung des Datensatzes, Name der Entität, Art des Ereignisses. Den Datensatz selbst holen wir anschließend gezielt über die API nach. Das ist die saubere Reihenfolge: Der Webhook ist der Auslöser, die API bleibt die Datenquelle. Danach nehmen wir nur die betroffene Detailseite und die betroffenen Listen aus dem Cache, statt die ganze Website zu leeren.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die API nicht oder unvollständig, bleibt der letzte gute Stand stehen, der Lauf wird protokolliert und mit Abstand erneut versucht. Ein abgebrochener Abgleich darf nie den Katalog leeren. Genauso behandeln wir den Rückweg: Geht eine Anfrage nicht durch, ist sie trotzdem gesichert und geht zusätzlich per E-Mail raus — Details dazu in der Leistung Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus den öffentlichen Angaben von weclapp — Zugangsweg, Bereiche der Schnittstelle und Ereignisnamen im Original. Feste Zahlen zu Abfragegrenzen nennt die Doku nicht, deshalb behandeln wir die Schnittstelle als knappe Ressource: bündeln, zwischenspeichern, nur nachladen, was sich geändert hat.
// d-01zugang
Die Schnittstelle liegt pro Mandant unter der eigenen weclapp-Adresse im Pfad webapp/api mit Versionsangabe. Jede Anfrage trägt das API-Token im Header AuthenticationToken. Das Token steht in den eigenen Einstellungen, ist erst nach erneuter Anmeldung sichtbar und lässt sich neu erzeugen. Es gelten genau die Rechte des Benutzers, zu dem es gehört — die Website bekommt einen eigenen Zugang.
zweck: authentifizierung
// d-02katalog
Artikel und Artikelpreise sind in der Schnittstelle eigene Bereiche — der Katalog und die Preisliste lassen sich also getrennt abrufen und getrennt aktualisieren. Praktisch heißt das: Stammdaten laufen im ruhigen Takt, Preise dürfen häufiger nachziehen, ohne dass jedes Mal der ganze Katalog neu durch die Leitung geht.
zweck: produktdaten
// d-03abfrage
Listen kommen seitenweise: Standardmäßig liefert eine Antwort die ersten 100 Datensätze, maximal lassen sich 1.000 pro Seite anfordern, weiter geht es über die Seitenzahl. Dazu kommen Filter auf einzelne Eigenschaften mit Operatoren wie gleich, größer als, enthält oder leer, eine Sortierung und die Möglichkeit, nur bestimmte Felder anzufordern. Genau das macht einen sparsamen Abgleich möglich.
zweck: sparsam abrufen
// d-04aktualität
Angelegt werden Webhooks in den globalen Einstellungen unter Integration: Entität wählen, Ereignisse ankreuzen, Ziel-URL eintragen. weclapp schickt eine POST-Anfrage mit Kennung, Entitätsname und Art des Ereignisses — CREATE, UPDATE oder DELETE. Ist die URL nicht erreichbar, folgen Wiederholungen nach 1, 5 und 30 Minuten, 5 Stunden und einem Tag; danach wird der Webhook deaktiviert.
zweck: ereignisgesteuert
// d-05rückweg
Der Rückweg schreibt, was auf der Website entsteht: einen Kontakt, eine Angebotsanfrage, einen Auftrag. Seit Version 2 der Schnittstelle liegen Kunden, Kontakte, Interessenten und Lieferanten gemeinsam im Bereich party, davor waren es getrennte Bereiche. Angebot und Auftrag bleiben eigene Bereiche. Alle Aufrufe laufen serverseitig, nie aus dem Browser.
zweck: lead ins erp
// d-06versionen
Die Schnittstelle ist versioniert, und weclapp führt ein öffentliches Änderungsprotokoll dazu. Der Sprung auf Version 2 hat sichtbar aufgeräumt: Kunden, Kontakte, Interessenten und Lieferanten wurden zusammengelegt, und mitgelieferte Namensfelder verweisender Datensätze sind entfallen — stattdessen wird über die Kennung nachgeschlagen. Wir binden gegen eine feste Version und prüfen Änderungen im Betrieb.
zweck: stabil bleiben
Aus den gespiegelten Daten wird kein Datenbank-Dump, sondern eine Website. Der Produktkatalog filtert über die Felder, die im Mapping definiert sind — Kategorie, Eigenschaften, Preisspanne — und arbeitet dabei auf dem eigenen Bestand, also ohne Wartezeit auf ein fremdes System. Die Detailseite bekommt eine sprechende, dauerhafte URL, die Bildergalerie, die Eckdaten als Tabelle und das Datenblatt zum Download.
Darunter steht die Anfrage- oder Bestellstrecke — vorbelegt mit der Artikelnummer, damit im ERP sofort klar ist, worum es geht. Ob daraus eine Angebotsanfrage wird oder ein vollständiger Bestellvorgang, entscheidet das Geschäftsmodell, nicht die Technik. Für wiederkehrende Kunden kommt ein Kundenzugang dazu, in dem persönliche Preise, frühere Aufträge und Belege sichtbar werden — hinter Login, serverseitig abgefragt. Für Suchmaschinen ergänzen wir strukturierte Daten aus denselben Feldern und eine Regel für den Fall, dass ein Artikel aus dem Sortiment fällt: umleiten, als Nachfolger ausweisen oder die URL sauber als entfallen kennzeichnen.
Beim Datenschutz laufen zwei Richtungen auseinander. Artikeldaten sind in der Regel unkritisch — Kundendaten sind es nie. Deshalb: Formularfelder auf das Nötige begrenzen, Einwilligung sauber einholen und dokumentieren, Übertragung ausschließlich serverseitig über TLS, Löschfristen benennen. Und weil weclapp die Daten im Auftrag verarbeitet, gehört ein Auftragsverarbeitungsvertrag dazu — genau wie beim Hoster. Mehr dazu im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Die weclapp-Integration bauen wir in jedem System selbst — mit den Bordmitteln, die das CMS dafür mitbringt. Die Kette ist dabei überall dieselbe: Ein geplanter Abruf oder ein eingehender Webhook stößt den Abgleich an, die Artikel landen als Inhalte im CMS, und das Frontend rendert daraus Katalog und Detailseite. Was dafür im CMS liegen muss, ist schnell benannt — eine eigene Inhaltsart „Artikel“ mit genau den Feldern aus dem Mapping, die Bilder in der Medienverwaltung des Systems, und die Artikelnummer aus dem ERP als Schlüssel. Über diesen Schlüssel erkennt der zweite Lauf den Artikel wieder und aktualisiert ihn, statt eine Dublette anzulegen. Erst dadurch werden Produkte aus weclapp auf der Website zu echten Seiten mit dauerhafter URL statt zu einem eingebetteten Fremdinhalt.
Aktualität ist danach eine Frage von Cache und Auslöser. Ausgeliefert wird aus dem eigenen Bestand, also aus Cache oder statisch erzeugten Seiten — schnell und unabhängig davon, ob das ERP gerade erreichbar ist. Meldet weclapp per Webhook eine Änderung, holen wir gezielt diesen einen Artikel nach und nehmen nur seine Detailseite und die betroffenen Listen aus dem Cache, statt die ganze Website zu leeren. Der geplante Lauf im Hintergrund bleibt daneben als Grundsicherung bestehen, falls ein Webhook einmal nicht ankommt. Nur einzelne Werte bleiben außen vor und werden im Moment der Anzeige serverseitig geholt — die Verfügbarkeit etwa, oder ein persönlicher Preis hinter dem Login. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo die Artikel am Ende liegen und was die Redaktion damit tun kann.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler und Fluid alles mit, was eine Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Inhaltsart „Artikel“ mit genau den Feldern aus dem Mapping. Der Abruf der weclapp-Schnittstelle läuft als Scheduler-Task, eingehende Webhooks nimmt eine eigene Route mit passender Middleware entgegen und aktualisiert genau einen Artikel. Die Artikel liegen als Records in einem Systemordner, Bilder und Datenblätter in FAL. Zugangsdaten — Mandantenadresse und Token — stehen in der Extension-Konfiguration und nie im Repository. Sprechende URLs kommen aus dem Site Handling, gerendert wird über Fluid. Die Redaktion sieht die Artikel im Backend, pflegt eigene Texte daneben und platziert Teaser als Content-Element.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen. Die Artikel werden ein Custom Post Type mit eigenen Meta-Feldern für die Artikeldaten und Taxonomien für die Filter, also Kategorie, Serie und Eigenschaften. Ein geplanter Lauf hält den Bestand nach, eine eigene REST-Route nimmt den Webhook entgegen und stößt den Abgleich für genau einen Artikel an. Die Aufrufe der weclapp-Schnittstelle laufen serverseitig über dieselbe Route; der Schlüssel steht als Konstante in der wp-config.php und nie im Frontend. Fürs Frontend kommen Template-Dateien und Blöcke für den Editor dazu, damit die Redaktion Liste, Filter und Teaser dort platziert, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — Inhalte sind Entries in Collections, Bilder Assets in Containern. Weil weclapp eine dokumentierte REST-Schnittstelle mitbringt, lässt sich die Anbindung hier besonders sauber bauen: Ein Blueprint beschreibt das Datenmodell, ein Artisan-Command holt die Artikel und schreibt sie als Entries in eine eigene Collection, der Laravel-Scheduler bestimmt den Takt. Route und Controller nehmen den Webhook entgegen und aktualisieren genau einen Artikel. Der Schlüssel liegt in der .env, Bilder und Datenblätter landen als Assets im eigenen Container. Antlers oder Blade rendern Liste, Filter und Detailseite, Static Caching liefert sie aus. Im Control Panel pflegt die Redaktion Texte und Reihenfolge in Feldern, die der Abgleich nicht anfasst.
// entscheidung
zuordnung statt rangliste
Fast jede Diskussion über eine ERP-Anbindung endet bei dieser einen Frage. Sie hat keine grundsätzliche Antwort, sondern eine pro Feld: Was darf ein paar Minuten alt sein, und was muss im Moment der Anzeige stimmen? An drei Mustern lässt sich das zuordnen.
// e-01spiegeln
Bezeichnung, Beschreibung, Kategorie, Bilder, Datenblätter, Listenpreise: Das sind Inhalte, keine Momentaufnahmen. Sie gehören ins CMS. Die Seite wird dadurch schnell, bleibt bei einer Störung des ERP vollständig lesbar, ist für Suchmaschinen erfassbar und lässt sich redaktionell ergänzen.
inhalt · fester takt
// e-02live
Verfügbarkeit, Lieferzeit, ein kundenspezifischer Preis hinter dem Login: Diese Werte altern in Minuten und werden im Moment der Anzeige serverseitig geholt — mit kurzer Zwischenspeicherung, mit Zeitlimit und mit einer klar definierten Anzeige, falls keine Antwort kommt. Ein Ladebalken ist kein Konzept.
abruf · serverseitig
// e-03kombination
Der Regelfall: Die Seite wird aus dem gespiegelten Bestand gebaut und im Frontend um genau einen Live-Wert ergänzt. Der Webhook hält die Spiegelung frisch, der geplante Lauf fängt Lücken auf. Ein Weg für die Substanz, ein Weg für den Moment.
substanz + moment
Vier Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Wie viele Artikel umfasst das Sortiment, und wie oft ändern sich Stammdaten und Preise? Welche Felder müssen wirklich auf die Website — und welche auf keinen Fall? Soll die Website Anfragen und Aufträge zurückschreiben oder nur anzeigen? Und gibt es Preise oder Belege, die nur angemeldete Kunden sehen dürfen?
Danach steht das Mapping als Dokument, bevor gebaut wird. Dieselbe Logik greift bei anderen Systemen: SAP und Dynamics 365 Business Central bringen eigene Schnittstellen mit, HubSpot deckt die CRM-Seite ab. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
weclapp ist ein cloudbasiertes ERP-System der weclapp SE mit Sitz in Marburg, das im Browser läuft und ohne Installation auskommt. In einer Oberfläche liegen CRM, Einkauf und Disposition, Lagermanagement, die Auftragsverwaltung von der Anfrage bis zur Abrechnung, Produktion, E-Commerce, Finanzbuchhaltung, Projektmanagement und E-Rechnung; dazu kommen Erweiterungen wie Helpdesk, Vertragsmanagement, eine mobile Lager-App und eine Kassensoftware. Adressiert werden kleine und mittlere Unternehmen. Für die Website ist vor allem eines interessant: Artikel, Preise, Kunden und Aufträge liegen im selben System, und dieses System hat eine dokumentierte Schnittstelle nach außen.
Ja. weclapp stellt eine REST-API bereit, die JSON spricht und pro Mandant unter der eigenen weclapp-Adresse erreichbar ist, im Pfad webapp/api mit Versionsangabe. Authentifiziert wird mit einem API-Token, das bei jeder Anfrage im Header AuthenticationToken mitgeht. Das Token findet sich in weclapp unter dem Benutzernamen bei den eigenen Einstellungen im Abschnitt API-Token; weil es sicherheitskritisch ist, muss man sich zum Anzeigen erneut anmelden, und es lässt sich jederzeit neu erzeugen. Wichtig für die Rechtevergabe: Über die API gelten genau die Berechtigungen des Benutzers, zu dem das Token gehört. Die Website bekommt deshalb einen eigenen Zugang mit genau den Rechten, die sie braucht.
In der Regel zwei Richtungen. Nach draußen gehen die Artikeldaten: Bezeichnung, Beschreibung, Nummer, Kategorie, Eigenschaften und Preise; Artikel und Preise sind in der Schnittstelle eigene Bereiche, sodass sich der Katalog und die Preisliste getrennt abrufen lassen. Zurück geht das, was auf der Website entsteht: eine Anfrage als Kontakt, eine Angebotsanfrage oder ein Auftrag. Beides ist bewusst getrennt zu betrachten. Der Weg nach draußen ist eine Frage von Auswahl und Takt, der Weg zurück eine Frage von Datenschutz und Fehlerbehandlung. Was genau übertragen wird, legen wir vorher im Feld-Mapping fest — nicht jedes Feld aus einem ERP gehört auf eine öffentliche Website.
Gespiegelt, als Grundregel. Die Website fragt das ERP nicht bei jedem Seitenaufruf, sondern holt die Artikel im festen Takt ab und legt sie im Datenmodell des CMS ab. Ausgeliefert wird danach aus dem eigenen Bestand. Das hält die Seiten schnell, macht sie unabhängig von der Erreichbarkeit des ERP und sorgt dafür, dass eine Wartung beim Anbieter keinen leeren Produktkatalog produziert. Live abgefragt wird nur, was live sein muss — typischerweise die Verfügbarkeit oder ein kundenspezifischer Preis hinter einem Login. Diese Abfragen laufen serverseitig, mit kurzer Zwischenspeicherung und mit einer definierten Anzeige für den Fall, dass keine Antwort kommt.
Über Webhooks, ergänzt um einen geplanten Abgleich als Grundsicherung. In weclapp werden Webhooks in den globalen Einstellungen unter Integration angelegt: Man wählt die Entität, kreuzt die Ereignisse an — angelegt, geändert, gelöscht — und trägt die Ziel-URL ein. weclapp schickt daraufhin eine POST-Anfrage mit der Kennung des Datensatzes, dem Namen der Entität und der Art des Ereignisses, also CREATE, UPDATE oder DELETE. Die Meldung enthält also den Auslöser, nicht die Nutzdaten: Wir holen den betroffenen Datensatz anschließend gezielt über die API nach und leeren nur die betroffenen Seiten aus dem Cache. Ist die Ziel-URL nicht erreichbar, wiederholt weclapp den Versuch nach 1, 5 und 30 Minuten, nach 5 Stunden und nach einem Tag; bleibt sie unerreichbar, wird der Webhook deaktiviert und in der Liste mit einer Fehlermeldung geführt. Genau deshalb gehört der geplante Lauf als zweites Standbein dazu.
Ja, das ist der Rückweg. Das Formular auf der Website schickt seine Daten serverseitig an die API, und daraus entsteht in weclapp ein Datensatz: ein Kontakt beziehungsweise Kunde, eine Angebotsanfrage oder ein Auftrag. Seit Version 2 der Schnittstelle liegen Kunden, Kontakte, Interessenten und Lieferanten gemeinsam unter dem Bereich party, davor waren es getrennte Bereiche — das ist beim Bau der Anbindung der wichtigste Unterschied zwischen den Versionen. Damit nichts verloren geht, sichern wir die Übermittlung ab: Bleibt die API stumm, wird der Vorgang zwischengespeichert, erneut versucht und geht zusätzlich per E-Mail an das Team. Ein Lead darf nie an einer Zeitüberschreitung scheitern.
Ja — und in Statamic ebenso. Die Anbindung bauen wir in jedem der drei Systeme selbst, mit dessen eigenen Bordmitteln. In TYPO3 entsteht eine eigene Extension: Das TCA beschreibt das Datenmodell, der Abruf läuft als Scheduler-Task, die Artikel liegen als Records in einem Systemordner, gerendert wird über Fluid, und die Zugangsdaten stehen in der Extension-Konfiguration. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type mit Meta-Feldern für die Artikeldaten, ein geplanter Lauf für den Abgleich, eine eigene REST-Route für serverseitige Aufrufe und den Webhook, der Schlüssel in der wp-config.php. In Statamic liegt Laravel darunter: ein Blueprint als Datenmodell, ein Artisan-Command im Scheduler, die Artikel als Entries in einer Collection, der Schlüssel in der .env, gerendert mit Antlers oder Blade. Die Mechanik bleibt in allen drei Fällen dieselbe — nur der Ort, an dem die Artikel liegen, ist ein anderer.
weclapp gibt als Speicherort ein nach ISO 27001 und PCI DSS zertifiziertes Rechenzentrum in Frankfurt am Main an, nennt eine Mindestverfügbarkeit von 99,5 Prozent und eine durchgehend verschlüsselte Übertragung. Das entbindet die Website nicht von ihren eigenen Pflichten. Drei Punkte sind nicht verhandelbar: Das API-Token gehört auf den Server und niemals in den Browser, denn es trägt die Rechte eines echten Benutzers. Aus dem ERP fließen nur die Felder auf die Website, die dort gebraucht werden — interne Kalkulationen, Einkaufspreise und Lieferantendaten bleiben drin. Und für personenbezogene Daten, die von der Website ins ERP laufen, gelten Datensparsamkeit, eine sauber dokumentierte Einwilligung und ein Auftragsverarbeitungsvertrag mit dem Anbieter.
// womit das zusammenhängt
systeme, frontend & leistung
// stack · schnittstelle
Der Schwergewichts-Nachbar: andere Größenordnung, dieselbe Frage — welche Daten gehören auf die Website und in welchem Takt?
zur technik →
// stack · schnittstelle
Das ERP aus dem Microsoft-Umfeld und wie seine Artikel- und Auftragsdaten den Weg auf eine Website finden.
zur technik →
// stack · schnittstelle
Die CRM-Seite ohne Warenwirtschaft: Formulare, Kontakte und Kampagnen — und der Rückkanal von der Website.
zur technik →
// leistung · komponente
Was aus den Artikeldaten im Frontend wird: Liste mit Filter, Detailseite, Datenblatt — auffindbar und schnell.
zur leistung →
// leistung · komponente
Wenn aus der Anfrage eine Bestellung wird: Warenkorb, Checkout und der Auftrag, der zurück ins ERP läuft.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Artikel aus weclapp auf deiner Website?
Projekt anfragen