REST API (eazybusiness): POST/PATCH /items/{id}/suppliers lehnt jeden Payload mit HTTP 400 ab

[TomH76]

Hallo zusammen,

seit dem 17.08.2026 können wir über die WAWI-REST-API keine Lieferantenzuordnung mehr zu Artikeln anlegen oder ändern. Betroffen sind sowohl POST /items/{itemId}/suppliers (neue Zuordnung anlegen) als auch PATCH /items/{itemId}/suppliers/{supplierId} (bestehende Zuordnung ändern).

API-Version: 2.0.5+Sha.e539cce (GET /info)

Fehlerbild: Jeder Request wird mit HTTP 400 und folgender Antwort abgelehnt:

{
    "ErrorCode": "ValidationError",
    "ValidationErrors": [],
    "Errors": {
        "TaxRate": ["The field TaxRate must be between 0 and 2147483647."],
        "Stocklevel": ["The field Stocklevel must be between 0 and 2147483647."],
        "DeliveryTime": ["The field DeliveryTime must be between 0 and 2147483647."],
        "PurchasePriceNet": ["The field PurchasePriceNet must be between 0 and 2147483647."],
        "AmountPackagingUnit": ["The field AmountPackagingUnit must be between 0 and 2147483647."],
        "MinimumPurchaseQuantity": ["The field MinimumPurchaseQuantity must be between 0 and 2147483647."],
        "PermissibleOrderQuantity": ["The field PermissibleOrderQuantity must be between 0 and 2147483647."]
    },
    "ErrorMessage": "Validation failed",
    "Stacktrace": null
}

Das Auffällige: Dieselben Validierungsfehler erscheinen unabhängig vom tatsächlich gesendeten Payload — auch wenn:

• nur das laut Swagger-Schema einzige Pflichtfeld (SupplierId) gesendet wird,
• alle betroffenen Felder explizit mit gültigen Werten (z. B. 0) befüllt werden,
• exakt derselbe Payload gesendet wird, der bei älteren, bereits bestehenden Lieferantenzuordnungen nachweislich funktioniert hat.

0 liegt eindeutig im angegebenen Bereich "0 und 2147483647" — die Validierung schlägt also selbst bei unstrittig gültigen Werten fehl.

Weitere Eingrenzung, die wir vorgenommen haben:

• Betrifft sowohl neu angelegte Artikel als auch bereits länger bestehende Artikel, bei denen wir testweise die vorhandene, unveränderte Lieferantenzuordnung per PATCH zurückgeschrieben haben (identischer Fehler).
• Andere Schreibzugriffe über dieselbe REST-API funktionieren im selben Zeitraum weiterhin einwandfrei (z. B. PATCH /items/{id} für Gewichte, PATCH /items/{id}/descriptions/..., POST /items/{id}/images, PATCH /items/{id}/customFields/{id}) — das Problem ist also nicht allgemeiner Natur, sondern isoliert auf /items/{id}/suppliers.
• Auf unserer Seite wurde im relevanten Zeitraum weder an der API-Anbindung noch an den Zugangsdaten/Scopes etwas geändert (per Diff gegen automatische Backups verifiziert).
• Ein Neustart des API-Dienstes hat keine Änderung gebracht (Version/Build davor und danach identisch).
• Zusätzlich zur Sicherheit eine komplett neue App-Registrierung durchgeführt (eigene AppId, eigener Freischaltungs-Vorgang über POST /authentication → Freischaltung in der Wawi → neuer ApiKey über GET /authentication/{registrationId}), inklusive expliziter Prüfung der GrantedScopes — item.createitemsupplier und item.updateitemsupplier sind im neuen Token nachweislich enthalten. Der Request mit diesem brandneuen Token gegen denselben Artikel schlägt identisch fehl (gleiche HTTP-400-Antwort, gleiche Feldliste). Das schließt ein Scope-/Berechtigungsproblem des ursprünglichen Tokens damit aus — der Fehler tritt unabhängig von Token/App-Registrierung auf, die Validierung des Endpunkts selbst ist betroffen.

Frage an die Community/JTL: Ist das ein bekanntes Problem in diesem Build? Gab es serverseitige Änderungen an der Validierung dieses Endpunkts? Wir sind für jeden Hinweis dankbar, auch ob ein Workaround (z. B. über den Wawi-Desktop-Client) aktuell die einzige Option ist.

Danke und viele Grüße,
Thomas

Fehlerbild von KI erstellt, sie kann es einfach besser beschreiben