weclapp-API in der Praxis: Was mit REST-API und Webhooks geht

Kurz gesagt: weclapp bietet eine dokumentierte REST-API (aktuell Version v2) mit einem benutzerbezogenen API-Token und Webhooks, die bei Anlage, Änderung oder Löschung eines Datensatzes eine URL aufrufen. Feste Rate Limits gibt es laut weclapp nicht; stattdessen werden parallele Anfragen pro Mandant begrenzt und bei Überlast mit HTTP 429 abgelehnt. API-Zugriff ist laut Preisseite ab dem Paket „ERP Dienstleistung“ enthalten, nicht im Starter-Paket. Für den Glasfaser-Provider fiber4net haben wir 2025 damit eine bidirektionale Schnittstelle zwischen weclapp und Shopify gebaut.

Wir von EA Digital Solutions in Graz sind kein weclapp-Vertriebspartner und verkaufen keine Lizenzen. Wir entwickeln Schnittstellen und Erweiterungen rund um ERP-Systeme. Dieser Beitrag fasst zusammen, was die offizielle weclapp-Dokumentation zur API sagt, Stand 28.10.2026, und was wir in einem echten Projekt daraus gemacht haben.

Wann Sie die weclapp-API brauchen

weclapp bringt viele Anbindungen schon mit. Im Paket „ERP Handel“ ist laut Preisseite etwa eine Anbindung an Shops wie Shopware, WooCommerce oder Shopify enthalten, außerdem gibt es einen eigenen BMD-Export für die Steuerberatung. Prüfen Sie daher zuerst, ob der Standard Ihre Anforderungen abdeckt.

Die API wird interessant, wenn:

• Sie Systeme anbinden möchten, für die es keinen fertigen Connector gibt (Branchensoftware, eigene Datenbanken, Portale),
• Ihre Abläufe vom Standard abweichen, etwa bei Produktkonfigurationen, Sonderpreisen oder mehrstufigen Freigaben,
• Sie Dokumente oder Auswertungen erzeugen möchten, die weclapp so nicht anbietet,
• mehrere Systeme in einer bestimmten Reihenfolge zusammenspielen müssen und Sie volle Kontrolle über Fehlerbehandlung und Protokoll brauchen.

Welche Pakete API-Zugriff enthalten

Laut weclapp-Preisseite ist die API-Schnittstelle nur in den Paketen „ERP Dienstleistung“ und „ERP Handel“ enthalten; „ERP Dienstleistung“ führt „API-Zugriff“ ausdrücklich, „ERP Handel“ und „Enterprise“ enthalten jeweils alles aus dem kleineren Paket. Im Paket „ERP Starter“ ist kein API-Zugriff vorgesehen. Wenn Sie also mit Starter beginnen und später eine Schnittstelle planen, kalkulieren Sie den Paketwechsel mit ein.

Authentifizierung: der API-Token

Laut weclapp-Dokumentation authentifizieren Sie sich mit einem API-Token:

• Benutzerbezogen: Jeder Benutzer hat einen eigenen Token, zu finden unter „Meine Einstellungen“. Die API gewährt nur die Rechte des Benutzers, dem der Token gehört. Mit dem Token kann man sich nicht in der Weboberfläche anmelden.
• Übergabe: entweder im Header AuthenticationToken: {api_token} oder per HTTP-Basic-Authentifizierung mit dem Benutzernamen * und dem Token als Passwort.
• Neu erzeugen: Ein Benutzer kann jederzeit einen neuen Token erzeugen; laut API-Dokumentation werden damit alle vorherigen Tokens ungültig.
• Sicherheit: Der Token ist wie ein Passwort zu behandeln und bei Verdacht auf Missbrauch neu zu erzeugen.

Praxistipp: Weil der Token an einen Benutzer gebunden ist, sollte eine Schnittstelle nicht mit dem Token einer Mitarbeiterin laufen. Wenn diese ihren Token neu erzeugt oder das Unternehmen verlässt, steht die Schnittstelle. Klären Sie mit weclapp, ob für einen eigenen technischen Benutzer eine zusätzliche Lizenz nötig ist, und geben Sie diesem Benutzer nur die Rechte, die die Schnittstelle wirklich braucht.

So ist die REST-API aufgebaut

Die Basis-URL lautet laut Dokumentation https://<TENANT>.weclapp.com/webapp/api/v2/, wobei <TENANT> die Adresse Ihrer weclapp-Instanz ist. Jede Instanz hat also eigene Endpunkte.

Alle Ressourcen, etwa Kunden (party), Artikel (article), Aufträge (salesOrder), Rechnungen (salesInvoice) oder Lieferungen (shipment), folgen demselben Muster:

Nicht jede Ressource unterstützt alle Aktionen. Zusätzlich gibt es ressourcenspezifische Operationen, zum Beispiel beim Auftrag das Erzeugen einer Rechnung oder einer Lieferung aus dem Auftrag.

Einige Details aus der Dokumentation, die in Projekten wichtig sind:

• Nur JSON: Bei PUT und POST ist Content-Type: application/json anzugeben, bei allen Anfragen Accept: application/json. Die API arbeitet mit gzip-Kompression; ein User-Agent-Header wird empfohlen.
• Dezimalzahlen als Text: Preise und Mengen werden als JSON-Strings übertragen, damit keine Genauigkeit verloren geht. Datumswerte kommen als Millisekunden seit 1970.
• Seitenweise Abfrage: Standardmäßig liefert eine Abfrage die ersten 100 Datensätze; mit pageSize sind in der Regel bis zu 1.000 möglich, weitere Seiten holen Sie mit page.
• Filtern und Sortieren: Über Abfrageparameter oder Filterausdrücke in einer POST-Abfrage (/<ressource>/query). Mit properties lassen sich nur bestimmte Felder abrufen.
• Optimistisches Sperren: Datensätze haben eine version. Schicken Sie beim Ändern die Version mit, schlägt die Änderung fehl, wenn jemand anderer den Datensatz inzwischen geändert hat. Ohne version wird diese Prüfung übersprungen, was laut weclapp versehentlich fremde Änderungen überschreiben kann.
• Dry-Run: Mit dem Parameter dryRun=true werden POST, PUT und DELETE geprüft, aber nicht ausgeführt. Das ist praktisch, um eine Schnittstelle gegen echte Stammdaten zu testen.
• Fehlermeldungen: Fehler folgen dem Standard RFC 7807 und enthalten bei Validierungsfehlern das betroffene Feld.

Versionen und Änderungen

Neben v2 gibt es noch die ältere Version v1. Laut weclapp bleibt eine bestehende Version mindestens ein Jahr nach Erscheinen einer neuen Version verfügbar. Rückwärtskompatible Erweiterungen erscheinen laufend, Änderungen werden im API-Changelog dokumentiert, und es gibt einen API-Newsletter für geplante Änderungen. Für jede produktive Schnittstelle sollte jemand diesen Newsletter lesen.

Webhooks: weclapp meldet sich von selbst

Statt ständig nachzufragen, ob es neue Aufträge gibt, kann weclapp eine Adresse aufrufen, sobald sich etwas ändert. Laut weclapp-Hilfe richten Sie Webhooks unter „Globale Einstellungen > Integration > Webhooks“ ein:

• Ereignisse: Anlage, Änderung oder Löschung (CREATE, UPDATE, DELETE).
• Ziel: eine URL, die die Nachricht empfängt, und die Entität, für die der Webhook gilt.
• Inhalt: Die Nachricht wird per POST gesendet und enthält ein JSON-Objekt mit entityId, entityName und type. Die eigentlichen Daten stehen also nicht in der Nachricht; Ihr System holt sie danach über die API.
• Wiederholungen: Ist die URL nicht erreichbar, versucht weclapp es nach 1 Minute, 5 Minuten, 30 Minuten, 5 Stunden und 1 Tag erneut. Danach wird der Webhook deaktiviert und in der Liste mit einer Fehlermeldung angezeigt.

Webhooks lassen sich laut API-Spezifikation auch über die API selbst anlegen und verwalten (Ressource webhook).

Was das für die Praxis bedeutet:

• Deaktivierung überwachen: Wenn Ihr Empfänger länger als einen Tag nicht erreichbar ist, schaltet weclapp den Webhook ab. Ohne Überwachung merkt das niemand, bis Aufträge fehlen. Eine Schnittstelle sollte daher regelmäßig prüfen, ob ihre Webhooks noch aktiv sind, und zusätzlich einen gefilterten Abgleich machen (etwa „alle seit gestern geänderten Aufträge“), um Lücken zu schließen.
• Absender prüfen: Eine Signatur der Webhook-Nachrichten wird im Hilfeartikel nicht beschrieben. Weil die Nachricht nur eine ID enthält und die Daten danach mit dem eigenen Token über die API geholt werden, kann eine gefälschte Nachricht höchstens einen unnötigen Abruf auslösen, aber keine falschen Daten einschleusen. Trotzdem sollte die Empfangsadresse schwer zu erraten sein, und der Empfänger sollte nur bekannte Entitäten verarbeiten.
• Doppelte Meldungen einplanen: Wiederholungen bedeuten, dass dieselbe Änderung mehrfach ankommen kann. Die Verarbeitung muss so gebaut sein, dass ein zweiter Durchlauf nichts doppelt anlegt.

Last und Rate Limits

weclapp schreibt in der API-Dokumentation ausdrücklich, dass es keine festen Rate Limits gibt. Stattdessen gilt:

• Pro Mandant ist die Zahl gleichzeitig aktiver Anfragen begrenzt. Anfragen darüber hinaus werden nicht sofort abgelehnt, sondern warten bis zu 30 Sekunden. Danach antwortet die API mit HTTP 429 Too Many Requests.
• Auch dauerhaft hohe Last wird gebremst; als Maßstab dient die effektive Rechenzeit der Anfragen.
• Mit den Headern X-Weclapp-Wait-Timeout-Ms und X-Weclapp-Request-Timeout-Ms kann der Client festlegen, wie lange er höchstens warten möchte. In der Antwort zeigen X-Weclapp-Wait-Ms und X-Weclapp-Wait-Reason, ob und warum eine Anfrage warten musste.

weclapp empfiehlt unter anderem: HTTP 429 mit Wiederholung und exponentiell wachsender Wartezeit behandeln, Timeouts von mindestens einer Minute verwenden, kein ungefiltertes Polling, lieber wenige größere Anfragen (zum Beispiel mit filter=id in[...]) und idealerweise eine ereignisgesteuerte Architektur mit Webhooks.

Aus der Praxis: weclapp und Shopify für fiber4net

Für fiber4net, einen Glasfaser-Provider, haben wir 2025 eine bidirektionale Schnittstelle zwischen weclapp und Shopify gebaut:

• Shopify → weclapp: Bestellungen aus dem Shopify-Shop werden automatisch als Aufträge in weclapp angelegt.
• weclapp → Shopify: Bestellstatus und Tracking-Nummern werden aus weclapp an Shopify zurückgespielt.

Zusätzlich haben wir für fiber4net einen Rechnungsgenerator entwickelt, der an weclapp angebunden ist.

Worauf es bei einer solchen Shop-ERP-Schnittstelle grundsätzlich ankommt:

• Ein führendes System pro Datenart festlegen. Bestellungen entstehen im Shop, Status und Lieferung im ERP. Wenn beide Systeme dasselbe Feld ändern dürfen, entstehen Widersprüche.
• Zuordnung über eindeutige Referenzen. Jede Bestellung braucht eine Referenz, über die sie in beiden Systemen wiedergefunden wird. Nur so lässt sich verhindern, dass bei einer wiederholten Meldung ein Auftrag doppelt angelegt wird.
• Beide Seiten liefern Ereignisse. Auch Shopify bietet Webhooks, etwa für neu angelegte Bestellungen. Laut Shopify-Dokumentation sollen Empfänger die HMAC-Signatur prüfen und doppelte Zustellungen über die Webhook-ID erkennen, und die Zustellung ist nicht immer garantiert. Ein regelmäßiger Abgleich gehört deshalb dazu.
• Fehler sichtbar machen. Wenn eine Bestellung nicht übertragen werden kann, etwa weil ein Artikel in weclapp fehlt, muss jemand davon erfahren, bevor die Kundin nachfragt.

Checkliste für Ihr weclapp-Schnittstellenprojekt

• Ist API-Zugriff in Ihrem Paket enthalten?
• Gibt es für Ihr Zielsystem schon eine Standardanbindung, und reicht sie?
• Welcher Benutzer stellt den Token bereit, und welche Rechte braucht er?
• Welche Daten fließen in welche Richtung, und welches System ist jeweils führend?
• Welche Ereignisse lösen eine Übertragung aus: Webhook, Zeitplan oder beides?
• Wie werden Wiederholungen, doppelte Meldungen und HTTP 429 behandelt?
• Wer bekommt eine Meldung, wenn eine Übertragung fehlschlägt oder ein Webhook deaktiviert wurde?
• Gibt es eine Testinstanz oder zumindest Tests mit dryRun?
• Wer verfolgt Changelog und API-Newsletter?

Wie wir unterstützen

Wir planen und entwickeln weclapp-Schnittstellen zu Shops, Portalen, Branchensoftware und Buchhaltung, inklusive Protokoll, Fehlerbenachrichtigung und Dokumentation. Der Code gehört Ihnen. Mehr dazu auf unseren Seiten weclapp-Integration und ERP-Entwicklung. Wenn Sie noch vor der Systemwahl stehen, hilft unser ERP-Vergleich 2026 für KMU in Österreich. Im kostenlosen Erstgespräch klären wir, ob der weclapp-Standard reicht oder eine eigene Schnittstelle sinnvoll ist.

Quellen (abgerufen am 28.10.2026)

• weclapp API-Dokumentation (v2, OpenAPI)
• weclapp OpenAPI-Spezifikation v2 (YAML)
• weclapp: Gibt es eine API zu weclapp?
• weclapp: Wie binde ich Webhooks in weclapp ein?
• weclapp API-Changelog
• weclapp Preise
• weclapp BMD-Export
• Shopify Webhooks