Hallo Morimus,
hier die Antwort von unserer IT:
# JTL-WAWI API (OnPrem) — 403 bei /customers und /deliveryNotes
**Server-Version (aus dem OpenAPI-`info`-Block):** JTL-Wawi **2.0.5+Sha.e539cce**
(`x-application-version: 2.0.5.0`, OpenAPI-`version: 1.2`), Kestrel, Mount `/api/eazybusiness`,
Version in der Route (`/v1/...`). Auth-Schema: `securitySchemes.Wawi = { type: apiKey,
name: Authorization, in: header }`.
## Gemeinsame Header beider Requests (Secrets maskiert)
```
Authorization: Wawi <redacted>
x-appid: horologica-1
x-appversion: 1.1
x-challengecode: XXXXX-XXX-XXXX (auskommentiert)
Accept: application/json
```
(kein `api-version`-Header — Version steckt in der Route. `x-runas` NICHT gesetzt.)
## Fall 1 — GET /api/eazybusiness/v1/customers?pageSize=1 → 403
```
HTTP 403 | server: Kestrel | date: Thu, 09 Jul 2026 13:48:04 GMT
(kein WWW-Authenticate, kein x-error-Header) | Body: leer (0 bytes)
```
Von der Spec geforderte Scopes für **GET /customers**:
```
["customer.querycustomers", "all.read", "cusomters.read"]
```
→ enthält den **Typo `cusomters.read`**, NICHT `customers.read`.
## Fall 2 — GET /api/eazybusiness/v1/deliveryNotes?pageSize=1 → 403
```
HTTP 403 | server: Kestrel | date: Thu, 09 Jul 2026 13:48:04 GMT
(kein WWW-Authenticate, kein x-error-Header) | Body: leer (0 bytes)
```
Von der Spec geforderte Scopes für **GET /deliveryNotes**:
```
["deliverynote.querydeliverynotes", "all.read", "deliverynotes.read"]
```
→ fordert `deliverynotes.read`, NICHT `deliveries.read`.
## GrantedScopes unserer App
Die direkte Granted-Liste ist nicht mehr abrufbar: `GET /v1/authentication/{registrationId}` zu
unserer ursprünglichen registrationId liefert inzwischen **404** (Registrierung abgeschlossen).
Daher **aus dem Live-Verhalten abgeleitet** (ein 200 beweist, dass mind. einer der vom Endpunkt
ODER-verknüpft geforderten Scopes granted ist):
| Endpunkt (GET) | HTTP | von der Spec geforderte Scopes (ODER-verknüpft) |
|----------------|------|--------------------------------------------------|
| /v1/items | **200** | item.queryitems, all.read, **items.read** |
| /v1/salesOrders | **200** | salesorder.querysalesorders, all.read, **salesorders.read** |
| /v1/customerGroups | **200** | customergroup.querycustomergroups, all.read, **customers.read** |
| /v1/customerCategories | **200** | customercategory.querycustomercategories, all.read, **customers.read** |
| /v1/shippingMethods | **200** | shippingmethod.queryshippingmethods, all.read, **deliveries.read** |
| /v1/customers | **403** | customer.querycustomers, all.read, **cusomters.read** |
| /v1/deliveryNotes | **403** | deliverynote.querydeliverynotes, all.read, **deliverynotes.read** |
**Belegbar granted** (weil je ein 200-Endpunkt genau diesen Scope fordert):
`customers.read`, `deliveries.read`, `items.read`, `salesorders.read`.
## Kern-Befund /customers — der Typo hängt NUR an der Collection
In unserer 2.0.5 fordern **alle anderen** customer-Endpunkte bereits den **korrigierten**
`customers.read` — z. B.:
```
GET /customers/{id}/contacts -> ["customer.querycustomercontacts", "customers.read"]
GET /customers/{id}/bankaccounts -> ["customer.querycustomerbankaccounts", "customers.read"]
GET /customers/customfields -> ["customer.querycustomercustomfields", "customers.read"]
GET /customers/workflowEvents -> ["customer.querycustomerworkflowevents", "customers.read"]
GET /customerGroups, /customerCategories -> [..., "customers.read"] (liefern bei uns 200)
```
**Einzig** die Haupt-Collection **GET /customers** trägt noch den Typo `cusomters.read`.
Beide Scope-Namen existieren in der Spec-Gesamtliste (`cusomters.read` UND `customers.read`).
→ Euer früherer Hinweis („Typo in einer Version gefixt, korrigierten zusätzlich bereitgestellt;
Scopes sind ODER-verknüpft, nie UND") bezog sich noch auf unsere **damaligen Versuche mit API 1.1**.
**Wir sind inzwischen auf Wawi 2.0.5 / OpenAPI 1.2** — und in DIESER aktuellen Version hängt der Typo
`cusomters.read` an der `/customers`-Collection **weiterhin**, während alle Sub-Endpunkte bereits den
korrigierten `customers.read` fordern. Da ODER-verknüpft, greift unser (granted) `customers.read`
überall — **außer an GET /customers selbst**, weil dort der korrigierte Scope in der Accept-Liste
dieses einen Endpunkts noch fehlt (nur `cusomters.read`). Der Collection-Fix scheint also selbst in
2.0.5 noch nicht angekommen zu sein.
## Kern-Befund /deliveryNotes — zwei getrennte Scope-Familien
Die Spec führt `deliveries.*` und `deliverynote(s).*` als **getrennte** Familien
(`deliveries.read` vs. `deliverynotes.read`) — deckt sich mit dem Hinweis, dass `deliveries` die
reine Versand-API ist und hier „2 getrennte Namings statt einem aggregierenden" existieren.
Wir haben `deliveries.read` (→ /shippingMethods = 200), aber `/deliveryNotes` fordert
`deliverynotes.read` → 403.
## Fragen
Kontext: Ein Typo-Fix-Hinweis bezog von Marc Völker/JTL sich auf unsere **früheren Versuche mit API 1.1**. Wir laufen
jetzt auf **Wawi 2.0.5 / OpenAPI 1.2** und melden den Stand DIESER Version.
1. **/customers:** In 2.0.5 trägt GET /customers (Collection) noch den Typo `cusomters.read`, während
alle Sub-Endpunkte bereits `customers.read` nutzen. Ist der Collection-Fix in einer Version **> 2.0.5**
enthalten (ab welcher)? Oder sollen wir bis dahin `cusomters.read` zusätzlich mitregistrieren,
damit GET /customers greift?
2. **/deliveryNotes:** Bestätigt ihr, dass wir zusätzlich `deliverynotes.read` (statt/neben
`deliveries.read`) registrieren müssen?
3. (Randnotiz 401 vs. 403: bei uns kommt in 2.0.5 durchgängig **403** bei Scope-Fehlern — passt zu
eurer Erwartung.)
