PlentyOne — Write-Operations¶
Empirisch validierte Pflichtfelder + Fallstricke für Write-Endpoints. Vor jedem neuen Workflow, der schreibt, hier nachlesen.
Quelle: SUB Retoure (gebaut + getestet am 12.05.2026 gegen Hauptauftrag 370944).
POST /rest/orders — Retoure (oder Auftrag) anlegen¶
Endpoint: POST https://p38991.my.plentysystems.com/rest/orders
Auth: Bearer-Token aus Login PlentyOne-Node → siehe Auth-Patterns.
Pflichtfelder (Body)¶
{
"typeId": 3,
"plentyId": <fromParent>,
"locationId": <fromParent>,
"referrerId": <fromParent>,
"ownerId": 78,
"statusId": 9.01,
"orderReferences": [
{ "referenceType": "parent", "referenceOrderId": <parentId> }
],
"orderItems": [
{
"typeId": 1,
"itemVariationId": <fromParent>,
"quantity": <fromMailOrParent>,
"orderItemName": "...",
"amounts": [ /* OHNE id/orderItemId */ ],
"references": [
{ "referenceType": "parent", "referenceOrderItemId": <parentItemId> }
],
"properties": [
{ "typeId": 35, "value": "1" }
]
}
],
"properties": [
{ "typeId": 7, "value": "<externalOrderId-vom-parent>" },
{ "typeId": 1, "value": "<warehouseId-vom-parent>" },
{ "typeId": 2, "value": "<shippingProfileId-vom-parent>" },
{ "typeId": 995, "value": "<treueprogramm-falls-vorhanden>" }
],
"addressRelations": [
{ "typeId": 1, "addressId": <fromParent> },
{ "typeId": 2, "addressId": <fromParent> }
]
}
Empirisch gefundene Fallstricke¶
addressRelationsist Pflicht — sonst Status1(unvollständig) statt9.01. Kritisch.amounts[]ohne System-IDs (id,orderItemId) — sonst 422. Plenty vergibt die selbst.ownerId: 78(n8n-User) verwenden — sonst läuft die GLS/DHL-Ereignisaktion ggf. falsch.- Item-Filter sinnvoll setzen:
typeId !== 6(Versandkosten raus) unditemVariationId > 0(Phantome raus). Bei Bundles bleibttypeId 2(Master) undtypeId 3(Komponenten) drin. statusId: 9.01ist direkt setzbar wennaddressRelationsmit im Body sind — kein nachgelagertesPUTnötig.- Plenty-Ereignisaktion 496 GLS (oder DHL-Pendant) feuert trotzdem ein Plenty-Label — bewusst akzeptiert, 01 Retouren-Erfassung filtert den Plenty-Auto-Comment per
[n8n Amazon-RSA-Marker.
Retourengrund-Property¶
typeId: 35, Werte siehe Reference: Mokebo Plenty IDs. Default value: "1" = „kein Grund bekannt".
Bundle-Behandlung¶
Master + Komponenten haben dieselbe SKU (Property typeId: 98). Wenn Master matcht, kommen alle Komponenten automatisch mit. Filter im Item-Loop: typeId in [1, 2, 3] und itemVariationId > 0.
POST /rest/comments — Comment an Auftrag posten¶
Endpoint: POST https://p38991.my.plentysystems.com/rest/comments
⚠️ NICHT
POST /rest/comments/order/{id}benutzen — der gibt zwar HTTP 200 zurück, ist aber ein HTML-Redirect (x-location: /index.php), kein API-Schreib-Endpoint.
Pflichtfelder¶
{
"referenceType": "order",
"referenceValue": <orderId-als-Integer>,
"text": "...",
"isVisibleForContact": false,
"userId": 78
}
Fallstricke¶
userIdist Pflicht wennisVisibleForContact: false. Plenty wirft sonst 422 mit Validation-Error"user id muss ausgefüllt sein wenn is visible for contact false ist".userId: 78verwenden (n8n-User). Andere User-IDs (67= apoio,2= System) sind möglich, aber semantisch falsch.referenceValueals Integer, nicht als String.isVisibleForContact: falsefür interne Notizen. Plenty-API-internes Flag — bei mokebo-Setup (Marketplace via Amazon/Shopify) isttrueohnehin irrelevant, der Kunde sieht Plenty eh nicht.- UI-Cache: Plenty-UI cacht stark. Nach POST den Auftrag schließen + neu öffnen, sonst alter Stand sichtbar.
- GET-Verifikation:
GET /rest/comments/order/{id}listet alle Comments — funktioniert auch wenn das UI sie nicht zeigt.
Mokebo-spezifische Comment-Patterns¶
Idempotency-Marker am Hauptauftrag (durch SUB Retoure):
Tracking-Comment am Retoure-Auftrag (durch SUB Retoure, triggert 01-Retouren-Erfassung-Priorisierung):
Der [n8n Amazon-RSA-Prefix ist kritisch — 01 Retouren-Erfassung ignoriert den Plenty-Auto-Comment wenn der Marker vorhanden ist.