JTL-Wawi API Dokumentation

Kunden auflisten mit optionaler Suche, Sortierung und Paginierung.

Einzelnen Kunden nach Kundennummer abrufen.

Aufträge auflisten mit Filtern nach Kunde, Status und Zeitraum.

Welche Felder deine Antwort trägt, hängt von deiner Einrichtung ab. Der Assistent legt beim Erkennen fest, welche Spalten ausgeliefert werden. Das Beispiel zeigt deshalb eine typische Antwort, nicht die einzig mögliche. Felder, die bei dir fehlen, sind kein Fehler.

Felder mit dem Präfix CF_ sind deine eigenen Felder aus der Wawi. Wie viele es sind und wie sie heißen, ist bei jeder Anlage anders.

S2R_CanaryRevOrders22 trägt die Revisionsnummer deiner Datenbanksichten. Für die Auswertung deiner Aufträge kannst du es ignorieren.

Ein fehlender Wert kommt in zwei Formen zurück, und beide bedeuten dasselbe: null und leerer Text. In den Adressen steht etwa CompanyName als leerer Text da, wo keine Firma hinterlegt ist, Phone dagegen als null.

Die Liste liefert die Datensätze in data, dazu total, limit und offset für den Seitenlauf. Der Einzelabruf liefert nur data mit einem einzelnen Datensatz, ohne diese drei Angaben. Der Datensatz selbst sieht in beiden Fällen gleich aus.

Einzelnen Auftrag nach Auftragsnummer abrufen.

Positionen eines Auftrags abrufen.

Drei Endpunkte für Retouren (RMA): Kopfdaten auflisten, eine einzelne Retoure abrufen und die Positionen einer Retoure abrufen.

Retouren auflisten mit Filtern nach Kunde, Status, RMA-Nummer und Zeitraum. Standardmäßig nach Retourendatum absteigend sortiert (neueste zuerst).

Einzelne Retoure nach RMA-Nummer abrufen.

Positionen einer Retoure abrufen.

Rechnungen auflisten mit Filtern nach Kunde, Status und Zeitraum.

Mit dem Parameter ?order= können alle Rechnungen zu einem bestimmten Auftrag abgerufen werden:

Mahnstufen

Gefiltert wird ab einer Stufe, nicht auf eine genaue. Die Stufen gehören zu einer Mahngruppe, und die Gruppen sind unterschiedlich tief: ein exakter Vergleich ließe ausgerechnet die am härtesten angemahnten Kunden weg. Die Antwort führt DunningLevel und DunningLevelName. Bau die Bezeichnung nie aus der Zahl: die Zahl ist der Bezeichnung einen Schritt voraus, Stufe 3 heißt „2. Mahnung". Nicht angemahnt ist null, nie 0. OpenAmount wird bei Rechnungskorrekturen negativ.

Die Mahnfelder sind auf den meisten Anlagen leer, weil dort gar nicht gemahnt wird. null heißt also nicht, dass eine Rechnung offen ist.

OpenAmount kann negativ werden, etwa bei einer Rechnungskorrektur. Wenn du Summen über offene Beträge bildest, filtere vorher auf Werte größer als null, sonst rechnest du dir die Summe klein.

Rechnungs-PDF nach Rechnungsnummer herunterladen. Standardmäßig deaktiviert; kann im Setup-Wizard oder in config.ini aktiviert werden.

Die Suche extrahiert den numerischen Teil der Rechnungsnummer (RE-12345 → 12345) und sucht rekursiv in allen konfigurierten Ordnern und Unterordnern. Bei mehreren Treffern wird die neueste Datei verwendet.

Gibt die PDF-Datei direkt als Download zurück (Content-Type: application/pdf). Bei nicht gefundener Rechnung: 404.

Konfiguration

Es reicht, den Hauptordner anzugeben - Unterordner wie Jahres- oder Monatsverzeichnisse werden automatisch durchsucht:

InvoicePdfPath = \\SERVER\Buchhaltung\Rechnungsausgang
; Findet auch: \2026\04\RE-12345.pdf

Gutschriften abrufen wie Rechnungen: Nummer, Datum, Betrag, Status, Kunde, zugehörige Rechnung und Mitarbeiter.

Felder je Gutschrift

Die Zuordnung zum Auftrag läuft über die Rechnung. Hängen mehrere Aufträge an einer Rechnung, nennt OrderNumber den ersten davon und OrderCount sagt, wie viele es sind, damit eine 1 zu n nicht als 1 zu 1 gelesen wird.

Du bekommst den Gesamtbetrag je Gutschrift, nicht die einzelnen Artikelzeilen. Welche Artikel in welcher Menge gutgeschrieben wurden, kommt in einer späteren Version.

Artikel auflisten mit optionaler Suche.

Einzelnen Artikel nach Artikelnummer (SKU) abrufen.

Felder der /products-Antwort

Die folgende Tabelle listet alle Felder, die der /products-Endpunkt zurückgeben kann.

* TaricCode und CountryOfOrigin sind optionale Felder und müssen im Setup-Wizard (Feldauswahl) aktiviert werden, damit sie von der API und dem MCP zurückgegeben werden. Standardmäßig sind sie deaktiviert.

SQL2REST erkennt JTL-Merkmale (standardisierte Varianten-Beschreibungen wie Farbe, Größe, Material) und stellt sie über drei Wege zur Verfügung: einen Katalog-Endpunkt, eingebettete Werte auf Artikeln und einen Filter-Parameter.

Alle Merkmal-Definitionen mit ihren möglichen Werten, gruppiert nach Name.

JTL-IDs für Write-Back

Jede Position führt bereits die internen JTL-IDs mit: id auf dem Attribut (kMerkmal) und id auf jedem Wert (kMerkmalWert). Nützlich für Write-Back über die offizielle JTL-API.

Attribute ausblenden

Über den Abschnitt [MERKMALE] in der config.ini können einzelne Attribute aus allen Antworten ausgeblendet werden (Komma-getrennt, Groß-/Kleinschreibung wird ignoriert). Versuche, diese Namen als Filter zu nutzen, liefern HTTP 400.

[MERKMALE]
Disabled = InternalCode, LegacyFlag

Der Endpunkt /products/{sku} liefert immer ein attributes-Objekt, gruppiert nach Attributname. Bei /products opt-in über ?include=attributes, um N+1 zu vermeiden.

Der Parameter ?attribute[name]=wert filtert Artikel. Attributnamen sind die deutschen JTL-Originalnamen (kleingeschrieben). Mehrere Filter werden mit UND verknüpft.

Lagerbestand auflisten mit optionalem SKU-Filter. Jede Zeile enthält: SKU, AvailableStock, ReservedStock, IncomingStock, BlockedStock und StockLevel. JTL_ProductId ist advanced/opt-in.

Lagerbestand eines Artikels aufgeteilt nach Lager abrufen. Eine Zeile pro Lager mit WarehouseId, WarehouseName, WarehouseActive und StockInWarehouse.

Lagerbestand aller Artikel aufgeteilt nach Lager (Sammelabruf für den Bestandsabgleich). Eine Zeile je Artikel und Lager mit SKU, WarehouseId, WarehouseName, WarehouseActive, StockInWarehouse und AvailableInWarehouse. Seitenweise über limit und offset.

Lieferungen auflisten mit Filtern nach Auftrag, Versanddienstleister und Zeitraum.

Lieferscheine auflisten mit optionaler Suche und Datumsfilter.

Einzelnen Lieferschein nach Lieferscheinnummer abrufen, Positionen werden automatisch eingeschlossen.

Lieferscheine mit Positionen in einem Aufruf abrufen.

Drei Endpunkte für Einkaufsprozesse: Wareneingänge (stock movements), Lieferanten (suppliers) und Lieferantenbestellungen (purchase orders). Standardmäßig deaktiviert, im Setup-Wizard unter Schritt 3 "Einkauf / Wareneingang" aktivieren. Wenn aus, geben die Endpunkte 404 zurück.

Wareneingänge auflisten (Buchungen auf Lagerplätzen). Lieferant und Bestellung sind nur für Buchungsart 10 (Wareneingang aus Bestellung) befüllt; andere Buchungsarten liefern NULL für diese Spalten.

Einzelnen Wareneingang nach JTL-ID (kWarenLagerEingang) abrufen.

Lieferanten auflisten mit Suche, Aktiv-Filter und Adress- und Konditions-Spalten.

Einzelnen Lieferanten nach JTL-ID (kLieferant) abrufen.

Lieferantenbestellungen als flache Header+Position-Zeilen. Eine Zeile pro Bestellposition. Für Soll-Ist-Reporting open_only=true verwenden.

Einzelne Bestellung mit verschachtelten Positionen unter positions abrufen.

Beantwortet "wie oft wurde dieser Artikel verkauft" in einer Abfrage. Die Summierung passiert in der Datenbank, nicht durch das Durchblättern aller Aufträge. Mehrere Artikelnummern lassen sich mit Komma trennen.

Zwei Zahlen, nicht eine

Bestellt (order) zählt die Positionen nicht stornierter Verkaufsaufträge im Zeitraum, also dieselbe Abgrenzung wie "verkauft pro Tag" in der Wawi. Noch nicht versendete Mengen sind enthalten, und der Netto-Umsatz kommt mit. Ausgeliefert (delivery) zählt die Lieferscheinpositionen, also was das Lager verlassen hat. Dort gibt es keinen Umsatz, weil Lieferscheinpositionen keinen Preis führen; ein aus dem Auftrag geborgter Wert würde am falschen Ereignis hängen. Jede Antwort nennt die verwendete Basis mit, damit die beiden Zahlen nicht verwechselt werden.

Felder je Artikel

Die Artikelzeilen stehen unter results, nicht unter data. Die Antwort führt zusätzlich sku, from_date, to_date, date_basis und mandant auf oberster Ebene.

Beantwortet „was hat jeder verkauft" in einer Abfrage. Die Summierung passiert in der Datenbank, nicht durch das Durchblättern tausender Aufträge.

Wem der Umsatz zugerechnet wird

Derselbe Auftrag zählt je nach Wahl auf eine andere Person, deshalb ist das eine Frage und kein Detail. created_by ist der Ersteller, je Auftrag festgeschrieben und damit die einzige Angabe, deren Bedeutung unstrittig ist: daher der Standard. sales_employee ist der Mitarbeiter am Auftrag, auftragsseitig, aber in der Wawi je Auftrag umsetzbar. account_manager ist der Betreuer am Kundenstamm und damit eine Momentaufnahme: ordnest du einen Kunden neu zu, ändert sich die Zahl auch für seine alten Aufträge. Jede Antwort nennt die verwendete Zurechnung mit.

Felder je Mitarbeiter

Stornos werden getrennt ausgewiesen statt weggelassen. Umsatz und Stornos zusammen sind alle Aufträge, die durch die Filter kamen, damit nichts unangekündigt aus der Summe fällt.

Der Rohertrag rechnet mit dem heutigen Einkaufspreis aus dem Artikelstamm, nicht mit dem zum Verkaufszeitpunkt. Bei alten Aufträgen oder geänderten Einkaufspreisen weicht der Wert deshalb ab. Die Antwort schreibt das als cost_basis dazu.

Die Mitarbeiterzeilen stehen unter results, nicht unter data.

Das Mitarbeiterverzeichnis aus der Wawi: Name, Abteilung und ob die Person noch aktiv ist. Damit lassen sich die Mitarbeiter-IDs auflösen, die an Aufträgen, Rechnungen und Gutschriften hängen.

Im Chat heißen dieselben Werkzeuge list_employees und get_employee.

Einzelnen Mitarbeiter nach ID abrufen: GET /employees/{id}.

Felder je Mitarbeiter

Ausgeschiedene Mitarbeiter bleiben auffindbar. Das ist der Zweck des Verzeichnisses: eine Auswertung über das letzte Jahr bleibt richtig, auch wenn jemand das Unternehmen inzwischen verlassen hat.

Das Verzeichnis kommt vollständig, ohne limit und offset. Eine Belegschaft ist keine Datenmenge, durch die man blättert.

Die Protokolleinträge deiner JTL-Workflows: wann welcher Workflow gelaufen ist, was er gemeldet hat und wo er abgebrochen ist. Filterbar nach Schweregrad, Workflow, Objekt und Zeitraum, dazu eine Volltextsuche über die Meldung.

Eigene Berechtigung. Die Workflow-Protokolle liegen seit 1.4.7 in der Berechtigung Workflows und hängen an keinem anderen Bereich. Im Chat heißt das Werkzeug list_workflow_logs.

Alle Felder, die Schweregrade und die Beispiele stehen auf der eigenen Seite Workflow-Log.

Das Workflow-Protokoll sagt, was passiert ist. Die Workflow-Definitionen sagen, warum: bei welchem Ereignis ein Workflow startet, welche Bedingungen er prüft und welche Aktionen er ausführt. Rein lesend wie alles hier: In die Wawi wird nichts geschrieben, und es wird kein Workflow ausgelöst.

WorkflowId ist derselbe Wert wie im Workflow-Protokoll. Darüber werden aus zwei Listen eine Antwort: Der Protokolleintrag nennt den Abbruch, der Workflow dahinter nennt den Grund. Keine Übersetzungstabelle, kein Suchen über den Namen.

Keine neue Berechtigung nötig. Die Workflow-Definitionen liegen in derselben Berechtigung wie die Workflow-Protokolle, denn es ist dieselbe Sache aus zwei Blickwinkeln. Wer die Protokolle schon freigegeben hat, bekommt sie mit dem Update, ohne etwas anzuhaken.

Im Chat heißen die Werkzeuge list_workflow_definitions und get_workflow_definition. Das zweite liefert Kopf, Bedingungen und Aktionen eines Workflows in einer einzigen Antwort.

ObjectType und EventType stehen immer, EventLabel nicht: Die Bezeichnung kommt aus dem Ereigniskatalog der Wawi, und der ist dort oft nur teilweise gefüllt. Filtere deshalb über die Codes, und baue keine Anzeige, die ohne die Bezeichnung bricht.

Ob ein Workflow aktiv ist, steht nicht in den Daten: Dieses Feld führt die Wawi nicht. Ob er läuft, zeigt das Workflow-Protokoll.

Die Bedingungen eines Workflows in ihrer Reihenfolge: die geprüfte Eigenschaft, der Operator im Klartext und der Wert, gegen den verglichen wird.

Ein Beispiel. Im Protokoll steht, ein Auslieferungs-Workflow sei an der Bedingung Auftragspositionen.KomplettLieferbarAusLager abgebrochen. Dieselbe Bedingung findest du hier wieder, aber unter dem Namen GruppePositionen.KomplettLieferbarAusLager. Warum sie anders heißt, steht gleich unter der Tabelle.

So ist eine Bedingung aufgebaut

Eine Bedingung besteht aus drei Angaben. Am Beispiel von oben:

Eine Regel kann mehrere Bedingungen haben. Jede Bedingung hat genau einen Pfad. Ein Pfad besteht aus Teilen. Die Teile bekommst du einzeln in PropertyParts, jeweils mit der Angabe, woher sie stammen. Zusammengesetzt mit Punkten ergeben sie den PropertyPath.

Felder je Bedingung

Jede Angabe trägt ihre Herkunft mit. OperatorLabel ist die deutsche Formulierung, die du aus der Wawi kennst, und OperatorProvenance sagt, worauf sie steht. Einen Operator, den wir noch nicht benennen können, bekommst du mit seiner Zahl und ohne Bezeichnung: Die Bedingung verschwindet nie, sie bleibt nur unbenannt.

Die Wawi zeigt andere Namen an, als die API liefert, weil die API den gespeicherten Bezeichner zurückgibt und die Wawi daraus einen Anzeigenamen macht. Gemeint ist dasselbe:

Zurückrechnen kannst du das nicht. Umlaute und Sonderzeichen fallen beim Speichern weg, und aus EnthaeltStandardLager lässt sich Enthält_Standard-Lager nicht wiederherstellen. Vergleiche den Pfad deshalb nicht Zeichen für Zeichen mit dem, was am Bildschirm steht.

Wie viele Teile ein Pfad hat, ist nicht festgelegt. Baue also nichts, was eine bestimmte Anzahl voraussetzt.

Auch der Aufbau kann sich unterscheiden, obwohl dieselbe Frage gemeint ist. Mal steht die Antwort im Pfad selbst, etwa …EnthaeltStandardLager verglichen gegen True. Mal steht sie im Vergleichswert:

BrowsePK am Ende des Pfades heißt: Hier wurde ein Datensatz über einen Auswahldialog gewählt. Der Vergleichswert ist dann dessen Nummer. Zeigt er auf ein Lager, steht der Name daneben in ComparisonValueLabel. Eines siehst du hier allerdings nicht: ob jemand die Auswahl in der Wawi offen gelassen hat. Eine unfertige Regel sieht in den Daten aus wie eine fertige.

Der Vergleichswert ist immer Text. Und zwar so, wie die Wawi ihn gespeichert hat, nicht so, wie er eingetippt wurde. Aus einer eingetippten 3 wird 3,0000, mit Komma. Wenn du damit rechnest, ersetze das Komma vorher durch einen Punkt. Manche Operatoren haben gar keinen Wert, etwa ist leer. Ob einer zu erwarten ist, sagt dir OperatorTakesOperand.

Was ein Workflow tut, sobald seine Bedingungen zutreffen: die Aktionen in ihrer Reihenfolge, jede mit ihrer Art und ihrem Parametersatz.

Felder je Aktion

Die Aktionsparameter sind eine feste Auswahl. Was nicht dazugehört, wird nicht ausgeliefert, und eine Aktionsart, die wir noch nicht auflösen, erscheint mit ihrer Bezeichnung und mit leerem Parameters. Ein leerer Parametersatz heißt also: diese Art lösen wir noch nicht auf. Er heißt nie, dass die Aktion nichts tut.

Was dieser Endpunkt nicht auflöst

Einen Namen bekommst du nur für Warenlager. Bei jedem anderen Verweis bekommst du die Nummer. Worauf sie zeigt, sagt dir der PropertyParentType des letzten Pfadteils: eine Zahlungsart, ein Shop, eine Kundengruppe. Sag also „Zahlungsart Nr. 9" statt „ist gleich 9".

Ein Vergleichswert kann mehrere Nummern enthalten, getrennt durch Semikolon, etwa 16;17. Das ist eine Mehrfachauswahl und keine große Zahl. Für solche Werte kommt nie ein Name.

Zwei Dinge sind ausdrücklich keine Lücke. Alle Operatoren, die die Wawi kennt, sind benannt. Und die Aktionsparameter sind eine feste Auswahl: Eine Aktionsart, die wir noch nicht auflösen, behält ihre Bezeichnung und kommt ohne Parameter. Ein leerer Parametersatz heißt „diese Art lösen wir noch nicht auf", nie „diese Aktion tut nichts".

Die Form der Antwort steht fest. Was heute nicht aufgelöst wird, füllt später ein Feld, das jetzt null ist. Es fällt nichts weg und nichts wird umbenannt. Du kannst also darauf bauen.

Die Felder mit JTL_-Präfix sind Schlüsselwerte aus Ihrer JTL-Datenbank. Sie sind im Wizard standardmäßig deaktiviert (siehe Abschnitt "Erweitert" im Setup) und werden nur benötigt, wenn Sie zusätzlich zur read-only API von SQL2REST auch über die offizielle JTL-API in JTL schreiben (zum Beispiel Auftragsstatus aktualisieren). Reine Leseintegrationen können diese Felder ignorieren.

Vorverbundene Endpunkte für CRM-Integrationen. Liefern Daten aus mehreren Tabellen in einem Aufruf.

Aufträge mit Kunden-, Rechnungs- und Versanddaten in einem Aufruf.

Batch-Kundensynchronisation mit höherem Limit (bis zu 1000).

Firma, Name, Kontakt und Adresse stammen aus der Standardadresse des Kunden.