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.