OnPremise API: Keine Daten aus API-Anbindung mittels externer APP

[martin_mm]

Liebe Community,

erster Post - und dann gleich etwas sehr spezielles. Leider konnte mit der Support nicht helfen.
Steinigt mich, aber wir entwickeln Inhouse mittels AI (Lovable & Claude) ein Tool, das uns KPIs - auch außerhalb von JTL - in einem Dashboard liefern soll. Das läuft so weit auch gut, aber es fehlt noch ein Quäntchen zum vollen Erfolg.

Aufbau: --> Schnittstelle/abfragende Instanz = Dashbaord im Cloud-Hosting von Lovable. Anfragen über VPS-Bridge (wegen statischer IP für die Anfragen) an unseren WaWi-Server (eCom-Data). JTL-API läuft auf WaWi-Server, Verbindung von Cloud <-> WaWi-Server steht und funktioniert.
Problem: WaWi-Server gibt keine/ungenügende Daten zurück

Problem: JTL-Wawi App-API --> 401 trotz gültiger Registrierung & freigegebener Scopes

## Fragen :

1. Warum liefert `/v1/info` mit unserem Header-Set 200, aber `/v1/items`, `/v1/customers`, `/v1/salesOrders` dann 401 bei gültiger App-Registrierung, freigegebenen Scopes und Admin-User per `x-runas`?
2. Erwartet die App-API für datenführende Endpunkte einen anderen Header-Namen/Wert als `x-runas` (z. B. `X-runas`, oder Wawi-Username vs. interne User-ID)?
3. Müssen `items.read` / `customers.read` / `salesorders.read` zusätzlich serverseitig (User-Berechtigungen, Benutzergruppe) explizit aktiviert werden, oder reicht die Freigabe im App-Wizard?
4. Gibt es serverseitig ein Auth-Log, das den genauen Ablehnungsgrund nennt (Scope fehlt? runas unbekannt? Challenge ungültig?)?

## Was wir bereits ausgeschlossen haben

- Falscher ApiKey --> /v1/info` antwortet mit demselben Key sauber
- Fehlender `x-challengecode` --> wird mitgeschickt (derselbe Wert wie bei Registrierung)
- Falsche `api-version` : sowohl `1.0` als auch `2.0` getestet, beide 401
- IP-Mismatch & Registrierung und API-Calls kommen von derselben festen IP
- Scope `all.read` als Umbrella: wurde testweise entfernt und einzeln aufgeführt, gleiches Ergebnis
- `x-runas` fehlt -> wurde ergänzt (`api-dashboard`, Admin-Berechtigung), gleiches Ergebnis

gesetze Scopes:

cusomters.read
customers.read
items.read
offers.read
orders.read
returns.read
saleschannels.read
salesorders.read
deliveries.read
deliverynotes.read
inventories.read
picklists.read
warehouse.read
accountings.read
invoices.read
salesinvoicecorrections.read
taxes.read
suppliers.read
all.read
application.runas
system.config.read
system.read
system.worker.read
wawiapp.all
resources.read

**Wawi-Version:** 1.11.10 (Tenant `eazybusiness`)
**App:** `eigeneapp` Version `2.3.1`
**Wawi-User (runas):** `api-dashboard` (temporär Admin-Rechte in Testumgebung, alle App-Scopes im Wizard freigegeben)

---

## Symptom

- `GET /api/eazybusiness/v1/info` --> **200 OK**, liefert echtes JSON:
```json
{ "Version": "1.11.10", "Timestamp": "2026-06-03T17:16:22+02:00", "Tenant": "eazybusiness", "Type": "WAWI-Api" }
```
- `GET /api/eazybusiness/v1/items?pageSize=1` --> **401**
- `GET /api/eazybusiness/v1/customers?pageSize=1` --> **401**
- `GET /api/eazybusiness/v1/salesOrders?pageSize=1` --> **401**

Body bei allen 401:
```json
{ "Message": "Authorization has been denied for this request." }
```

Heißt: Authentifizierung greift grundsätzlich (`/v1/info` antwortet sauber mit App-Auth), aber jeder datenführende Endpoint wird abgelehnt.

---

## Request-Header (identisch für alle vier Calls)

```
Authorization: Wawi <ApiKey aus jtl_registration.api_key>
x-appid: eigeneapp/2.3.1
x-appversion: 2.3.1
api-version: 2.0
x-challengecode: 111111111 (derselbe Wert wie bei Registrierung)
x-runas: api-dashboard
```

Anfragen laufen über unseren Bridge-VPS mit fester IP `123.123.123.123` (derselben, mit der die Registrierung erfolgte --> kein IP-Mismatch).

---

## Registrierungs-Details

App-Registrierung war erfolgreich (`ApiKey` wurde geliefert, ohne `RegChallengeIpMismatch`).
Body der POST-Registrierung (PascalCase, `api-version: 2.0`):

```json
{
"AppId": "eigeneapp",
"Version": "2.3.1",
"DisplayName": "KPI Dashboard",
"Description": "KPI Dashboard für JTL-Wawi (via Bridge).",
"ProviderName": "TolleFirma",
"ProviderWebsite": "https://unseredomain.com",
"MandatoryApiScopes": [
"cusomters.read", "customers.read", "items.read", "offers.read",
"orders.read", "returns.read", "saleschannels.read", "salesorders.read",
"deliveries.read", "deliverynotes.read", "inventories.read",
"picklists.read", "warehouse.read", "accountings.read", "invoices.read",
"salesinvoicecorrections.read", "taxes.read", "suppliers.read",
"all.read", "application.runas", "system.config.read", "system.read",
"system.worker.read", "wawiapp.all"
],
"OptionalApiScopes": [],
"AppIcon": "<base64 PNG>"
}


Kann uns irgendwer helfen da herauszufinden, wo genau das Problem liegen könnte? Diese 401er loszuwerden wäre wirklich supertoll

Danke vorab und allen schon mal ein schönes Wochenende!

Martin

 

[Morimus]

x-runas: api-dashboard

Vermutlich liegt hier der Fehler.
Bei x-runas wird nicht der Benutzername erwartet, sondern die interne Wawi-User-ID beziehungsweise UUID des Benutzers.

Zusätzlich würde ich die grantedScopes aus der Registrierungsantwort prüfen.
Entscheidend ist, welche Scopes tatsächlich gewährt wurden, nicht nur welche angefordert wurden.

edit:
Die neue Cloud API wäre für so ein externes Dashboard vermutlich die sauberere Lösung, sofern die benötigten Endpunkte dort verfügbar sind.

 

[martin_mm]

Danke dir für deine Hilfe! Das probieren wir mal aus.

JA - das wäre sie sicherlich. Hätten wir auch lieber gemacht - wollen dafür aber noch nicht auf die 2er-Version gehen

 

[martin_mm]

Test	Status
/v1/info	✅ 200
/v1/items mit allen 8 x-runas-Varianten (kein, kBenutzer, GUID upper/lower, X-RunAs, cLogin, x-wawiuser, x-user)	❌ alle 401 identisch

Hier mal die Ergebnisse:

1. /v1/info antwortet 200 mit demselben Key, aber /v1/items, /v1/customers, /v1/salesOrders geben jede Anfrage 401.

2. Die App-Registrierung war erfolgreich, GrantedApiScopes der Antwort enthält alle 24 angeforderten Scopes (inkl. items.read, customers.read, salesorders.read, application.runas, wawiapp.all).

3. In der DB-Tabelle dbo.tBenutzer wird beim App-Registrierungs-Handshake zwar ein neuer User WawiApiApp_21 (kBenutzer=60, nType=10, nAktiv=1) angelegt, aber cApiToken bleibt NULL und dLastLogin auch. Diverse x-runas-Varianten (Username, kBenutzer-ID, GUID upper/lower, Header-Case-Varianten) führen alle zum identischen 401.

Hast Du zufällig noch eine Idee?

 

[Morimus]

Okay, das ist komisch.
Nein, so langsam gehen mir die Ideen aus.

Bei der OnPremise API wird die Version über den Header api-version gesetzt.
Die Base-URL ist dabei /api/eazybusiness/.
Ich würde daher einmal exakt gegen den Endpoint testen, der zur verwendeten api-version passt, und nicht /v1 im Pfad mit api-version: 2.0 mischen.

Also testweise:

GET /api/eazybusiness/items?pageSize=1
api-version: 2.0

bzw. 1.0 Falls ihr wirklich v1 nutzen wollt.
Jeweils erst einmal ohne x-runas.

Ich weiß nicht, ob JTL an dieser Stelle eine solche Prüfung macht, aber du bist für die API-Beta beziehungsweise den REST-API-Zugriff freigeschaltet, oder?
Nicht, dass /info grundsätzlich funktioniert, die datenführenden Endpunkte wie /items, /customers oder /salesOrders aber eine echte Freischaltung benötigen.

 

[EW Hamburg]

Wir haben ein ähnliches resp. Das gleiche Problem, Fehlerbeschreibung anbei, der JTL Support wurde per Ticket mehrfach diesbezüglich kontaktiert, ist damit aber überfordert, hat uns auf das Entwicklerteam verwiesen, was dafür Support leisten "sollte/würde/könnte", null Feedback, unsere Tickets noch unsere Rückfragen werden weder vom Support noch vom Entwicklerteam beantwortet.

Sehr frustrierend, wenn man bedenkt, dass die Wawi nicht mehr kostenlos ist, sondern wir ~ € 2.400 (Advanced Nutzungsgebühren jährlich zahlen.

 

[Morimus]

Auf die schnelle ist mir folgendes aufgefallen.

In deiner Headerliste fehlt x-challengecode.
Laut aktueller JTL-Doku ist der Header auch bei späteren OnPremise-Requests erforderlich.
Falls er wirklich nicht gesendet wird, wäre das mein erster verdacht.

x-appid passt irgendwie nicht zur registrierten App-ID.
Registriert ist horologica-servicedesk-final, gesendet wird aber Horologica/1.1.
Ich würde testweise exakt die registrierte AppId verwenden, also x-appid: horologica-servicedesk-final/1.1 plus x-appversion: 1.1.

Teste /info einmal ohne Authorization oder mit falschem Key.
Wenn das ebenfalls 200 liefert, beweist /info nur Routing/API-Verfügbarkeit, aber keine erfolgreiche Autorisierung für Daten-Endpunkte.

Minimaltest daher:
GET /api/eazybusiness/items?pageSize=1
api-version: 1.0
Authorization: Wawi ApiKey
x-appid: horologica-servicedesk-final/1.1
x-appversion: 1.1
x-challengecode: derselbe Wert wie bei Registrierung
Accept: application/json

Und auch hier noch einmal die Info zur JTL-Cloud-API.
Solltet ihr eure Tools produktiv einsetzen wollen, lohnt es sich schon jetzt, euch mit der neuen Cloud-API vertraut zu machen.
Ich habe auch nach 10 Cloud-Apps nicht ansatzweise solche Probleme gehabt wie mit der ERP-API.

 

[martin_mm]

@EW Hamburg: Ich hatte den Tipp bekommen, dass die Dienste der JTL-Administrator-App (also der API-Dienst) unter einem Benutzer mit Administrationsrechten laufen soll. Hat bei uns allerdings noch nicht final geholfen. Vielleicht aber bei dir?
Ansonsten habe ich ähnliche Erfahrungen mit den Entwicklern - nun aber proaktiv einen Termin mit dem API-Support am kommenden Montag und dann schauen wir mal, was bei rumkommt.

@Morimus: Ja - glaub ich. Das ist sicher besser, aber wir laufen - auf Empfehlung unseres Dienstleisters - nun immer noch auf einer 1.11.XX-Version. Und da sollte es ja auch laufen...

Sonniges Wochenende Allen -)

 

[Morimus]

Minimaltest daher:

@EW Hamburg: Ich habe es nochmal getestet und so klappt es bei mir.

GET /api/eazybusiness/items?pageSize=1
api-version: 1.2
Authorization: Wawi <ApiKey>
x-appid: horologica-servicedesk-final/1.1
x-appversion: 1.1
x-challengecode: <derselbe Wert wie bei Registrierung>
x-runas: <Wawi-User oder testweise weglassen>
Accept: application/json

@martin_mm:
Ich erinnere mich! Das hattest du erwähnt.
Ja, wirklich schade, dass es ab einem gewissen Punkt nicht mehr so einfach ist, Updates einzuspielen.
Aber du hast natürlich recht, die ERP-API ist live und sollte auch laufen.

 

[EW Hamburg]

@ Morimus: Vielen Dank für die Hilfe, das werden wir natürlich gleich ausprobieren.
@martin_mm: Ich bin der gleichen Meinung, unabhängig ob eine etwas ältere Version, wenn JTL Features veröffentlicht, sollten sie funktionieren. Ansonsten wäre es Banana-Software.

 

[EW Hamburg]

@Morimus: Wir sind jetzt ein ganzes Stück weiter, es verbleiben aber noch drei Unsicherheiten/Fragen, die unser Entwickler im angehängten Dokument formuliert hat. Wäre super, wenn Du nochmal dar überschauen könntest.

 

[Morimus]

Ja, gerne. Ich habe das schon grob überflogen.
Ich komme allerdings erst am Nachmittag dazu, mir das detailliert anzuschauen.

OnPremise Datenzugriffe laufen weiterhin über den App Registrierungsflow mit permanentem API-Key.
In deinem Log hast du Authorization: Bearer <SessionId> es muss aber Authorization: Wawi <API-Key> sein.

Ich würde eine komplette Neuregistrierung ohne /v1-Pfad machen und danach exakt mit dem neuen API-Key testen.
GET /api/eazybusiness/salesOrders?pageSize=1
api-version: 1.1
Authorization: Wawi <neuer API-Key>
x-appid: <registrierte AppId>/1.1
x-appversion: 1.1
x-challengecode: <derselbe Code wie bei Registrierung>
Accept: application/json

Danach denselben Test mit /items?pageNumber=1&pageSize=1.
Wenn das weiterhin 401 oder leerer 200 ist, wäre das für mich ein JTL-seitiges Problem in Registrierung/Scope/API-Service.

Edit
Leere 200: Der Login-Flow erzeugt zwar eine Session, aber diese Session ersetzt nicht die App-Registrierung/API-Key-Autorisierung.
Scopes: Ja, müssen gekoppelt werden. Die Scopes hängen laut Doku an der App-Registrierung und am daraus erzeugten API-Key.
API Version: Versionslose Pfade sind richtig. /api/eazybusiness/items, nicht /v1/items.

 

[EW Hamburg]

Hallo Morimus,

wir haben die App komplett neu registriert, immer noch 401-Fehler, Befund anbei.

 

[Morimus]

Das sieht nun soweit alles gut aus.
Zumindest gehen mir damit dann auch die Ideen aus.

Zwei Dinge würde ich noch testen, bevor ich es endgültig als JTL-seitigen Fehler einstufe.

1. x-appid exakt wie registriert senden.

Ihr schreibt, registrierte AppId ist horologica-1, gesendet wird aber horologica-1/1.1.
Dass ohne x-appid ein 400 AppIdHeaderMissing kommt, zeigt nur, dass der Header vorhanden ist, nicht dass die AppId zur Registrierung passt.

Bitte daher einmal testen
x-appid: horologica-1
x-appversion: 1.1

2. Optional testweise x-runas mitsenden.

Mein OnPremise-Testclient sendet neben Authorization: Wawi <ApiKey>, api-version, x-appid, x-appversion und x-challengecode auch X-RunAs.
Falls eure Registrierung an den Benutzer horologica gebunden ist, würde ich einmal mit x-runas: horologica bzw. der internen User-ID testen.
Falls dafür application.runas nötig ist, müsste dieser Scope mit registriert sein.


Minimaltest wäre also

GET /api/eazybusiness/salesOrders?pageSize=1
api-version: 1.1
Authorization: Wawi <neuer API-Key>
x-appid: horologica-1
x-appversion: 1.1
x-challengecode: <Registrierungs-Code>
Accept: application/json

Optional zusätzlich

x-runas: horologica

Wenn auch das weiterhin 401 liefert, sehe ich clientseitig kaum noch einen plausiblen Fehler.
Dann ist die Frage an JTL, warum erzeugt eine akzeptierte OnPremise-App-Registrierung mit GrantedScopes einen API-Key, der bei geschützten Datenendpunkten in der Autorisierung abgelehnt wird? 🤷

 

[EW Hamburg]

Hallo Morimus,

vielen Dank – der entscheidende Hinweis war goldrichtig: Das Problem war tatsächlich die x-appid. Sobald wir sie OHNE Versions-Suffix senden, also exakt die registrierte AppId

x-appid: horologica-1 (statt vorher horologica-1/1.1)
x-appversion: 1.1

liefern die Endpunkte echte Daten. Verifiziert:

GET /api/eazybusiness/v1/salesOrders?pageSize=1 -> 200, TotalItems 194611
GET /api/eazybusiness/v1/items?pageSize=1 -> 200, TotalItems 71518

Auch der Hinweis zur Versionierung in der Route (statt api-version-Header) ist umgesetzt. x-runas ist bei uns nicht nötig.

Es bleiben zwei Endpunkte, die trotz vergebener Scopes weiterhin 401 liefern – dazu zwei Rückfragen:

1) /v1/deliveryNotes — Wir hatten deliveries.read registriert. Laut Spec fordert /deliveryNotes aber deliverynotes.read. Müssen wir schlicht mit deliverynotes.read neu registrieren? (Wofür gilt dann deliveries.read?)

2) /v1/customers (der interessante Fall) — Hier ist customers.read registriert und steht in den GrantedScopes, trotzdem 401. Auffällig: der /customers-Endpunkt führt in seinem security-Block einen vertippten Scope cusomters.read (Buchstabendreher) neben dem korrekten customers.read. Verdacht: der Server prüft intern gegen das vertippte cusomters.read, das man regulär nicht registrieren kann. Zum Vergleich: /customerGroups und /customerCategories funktionieren mit unserem customers.read (200).

Viele Grüße