POST /Prepacks

GENERAL INFORMATION

Purpose

This endpoint is used for creating prepacks and updating them if they have been modified. The definition of a prepack is a pre-bundled set of products in predetermined size and quantity ratios used for efficient ordering, distribution, and replenishment. Although it is pre-bundled, it is only used for logistics handling, the prepack is never sold to an end consumer.

How the data is used

We use this data to define the prepacks and it’s content, so Wallie knows exactly which SKUs and quantities are inside of a prepack, making it a mandatory dataset for everyone who uses prepacks in replenishment or initial distribution. If you do not use this in your process, this does not need to be implemented.

Best practices

1. Make sure to update the prepacks on a regular basis, recommended minimum once a day, to ensure the prepack information is up to date.

2. When you use prepacks, you need to implement this endpoint, but also add the prepack as a SKU to the item / style it belongs to. Examples and more detailed explanation in the POST /Items documentation page. Make sure the skuId alligns with the skuId in this endpoint (for example below "100001-10-PP1").

3. When the prepack is linked to a specific Purchase Order you can create the link by also sending the purchaseOrderId which needs to align with POST /PurchaseOrders. If there is no link to a purchase order, then leave that field empty, as it is optional.

4. In the “skus” array you can set the SKU’s that are present within the prepack with it’s quantities.

Common pitfalls

1. Do not generated a random id for the id field in the integration, only use system generated id’s that are fixed in the source system, as you need the same id to also be able to be able to update the prepack information.

2. A common pitfall is to forget to assign the prepack as a SKU to the items, as explained in the best practices.

3. Also not being consistent in the id’s you are using across all related endpoints is a common mistake to make.

Example use cases

1. As a merchandiser I want Wallie to propose my initial distribution for my incoming purchase order which is ordered in a variety of different prepacks.

REQUEST

Authentication

Bearer token, information on page POST /Token

Headers

QueryParameters:

Body example:

{
  "prepacks": [
    {
      "id": "7fc0904b-d594-4647-ba6c-4e39728b8d41",
      "purchaseOrderId": "f606fd6a-af05-4925-9680-51d2775e709c",
      "styleId": "100001-10",
      "skuId": "100001-10-PP1",
      "skus": [
        {
          "skuId": "100001-10-S",
          "quantity": 1
        },
        {
          "skuId": "100001-10-M",
          "quantity": 3
        },
        {
          "skuId": ""100001-10-L",
          "quantity": 2
        },
        {
          "skuId": ""100001-10-XL",
          "quantity": 1
        },
        {
          "skuId": "100001-10-XXL",
          "quantity": 1
        }
      ]
    },
    {
      "id": "ed41bf99-affd-4606-8a98-dfddbab7dffc",
      "purchaseOrderId": "f606fd6a-af05-4925-9680-51d2775e709c",
      "styleId": "100001-10",
      "skuId": "100001-10-PP2",
      "skus": [
        {
          "skuId": "100001-10-S",
          "quantity": 1
        },
        {
          "skuId": "100001-10-M",
          "quantity": 1
        },
        {
          "skuId": "100001-10-L",
          "quantity": 1
        },
        {
          "skuId": "100001-10-XL",
          "quantity": 1
        },
        {
          "skuId": "100001-10-XXL",
          "quantity": 1
        }
      ]
    }
  ]
}

Field information:

RESPONSE

StatusCodes:

200 = OK

401 = Unauthorized, which means an expired/missing/invalid token

400 = Bad request, see body of the response to check which validation errors have occured

500 = System error, see body of the response to check which error has occured or contact integration support

Body Example:

No body in the response