Skip to main content
C’est le flux canonical d’écriture : créer un plan de réassort, puis ajouter un article. La même forme s’applique aux autres types de plans (réassort, etc.) — seuls les chemins et champs diffèrent.
Cela crée des données réelles dans votre organisation. Utilisez un token avec la bonne permission d’écriture et testez d’abord contre une organisation non-production si vous le pouvez.

1. Créer le plan

POST /api/restock-plans avec name (et optionnellement brandId, collectionId, description). Il retourne l’id du nouveau plan et le status (DRAFT).
Réponse :

2. Ajouter un article

POST /api/restock-plans/{planId}/items avec variantId, sizeId, shopId, quantity. Il retourne { "success": true, "itemId": "…" }.

Gérer la réponse

Ajouter des articles passe par des règles métier, alors préparez-vous à ces résultats :
  • Succès{ "success": true, "itemId": "…" }.
  • Bloqué par une règlesuccess: false avec errorCode: "BUSINESS_RULE_VIOLATION"; lisez le message et ajustez.
  • ValidationerrorCode: "VARIANT_REQUIRED", "QUANTITY_INVALID", etc. Corrigez la charge utile.
  • Authentification401 UNAUTHORIZED (token mauvais/expiré) ou 403 FORBIDDEN (permission manquante).
Voir Codes d’erreur pour le mapping complet.
Les autres types de plans suivent le même motif — par ex. réassort est POST /api/rebalance-plans puis POST /api/rebalance-plans/{id}/items. Consultez les champs exacts par endpoint dans l’onglet Référence API.