Skip to main content
This is the canonical write flow: create a restock plan, then add an item. The same shape applies to other plan types (rebalance, etc.) — only the paths and fields differ.
This creates real data in your organization. Use a token with the right write permission, and test against a non-production organization first if you can.

1. Create the plan

POST /api/restock-plans with name (and optionally brandId, collectionId, description). It returns the new plan’s id and status (DRAFT).
curl -X POST https://app.solya.app/api/restock-plans \
  -H "Authorization: Bearer solya_sa_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Adidas FW25 Restock Wave 1",
    "brandId": "brand-uuid-adidas",
    "collectionId": "coll-uuid-fw25",
    "description": "First restock order for Adidas FW25"
  }'
Response:
{ "id": "rop-uuid-001", "brandId": "brand-uuid-adidas", "collectionId": "coll-uuid-fw25", "status": "DRAFT" }

2. Add an item

POST /api/restock-plans/{planId}/items with variantId, sizeId, shopId, quantity. It returns { "success": true, "itemId": "…" }.
curl -X POST https://app.solya.app/api/restock-plans/rop-uuid-001/items \
  -H "Authorization: Bearer solya_sa_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "variantId": "var-uuid-adidas-stan", "sizeId": "sz-uuid-43", "shopId": "shop-uuid-paris-opera", "quantity": 12 }'

Handle the response

Adding items runs through business rules, so plan for these outcomes:
  • Success{ "success": true, "itemId": "…" }.
  • Blocked by a rulesuccess: false with errorCode: "BUSINESS_RULE_VIOLATION"; read the message and adjust.
  • ValidationerrorCode: "VARIANT_REQUIRED", "QUANTITY_INVALID", etc. Fix the payload.
  • Auth401 UNAUTHORIZED (bad/expired token) or 403 FORBIDDEN (missing permission).
See Error codes for the full mapping.
Other plan types follow the same pattern — e.g. rebalance is POST /api/rebalance-plans then POST /api/rebalance-plans/{id}/items. Browse the exact fields per endpoint in the API Reference tab.