Line limit examples for the inventory reservation and availability APIs

In Sterling Intelligent Promising, a line limit is imposed for the availability, availability by date, and reservation API requests. To optimize the availability response time, refer to the examples for breakup availability requests and to use distribution group availability rather than node availability to avoid long lists of node locations. For the reservation API request, a fixed action limit is provided across all reservation requests to optimize the load between the availability and the reservation request.

Optimizing the response time of the availability API request

The API action is the number of individual item-node lines in the API Call. API action is defined as each item-node provided in the request input. These API actions may include, but are not limited to, inquiries or updates invoked through inventory lookup, promising, availability, reservations, supply or demand adjustments, or events that publish to external systems. For example, if there are 3 item-node lines in supply sync, that counts as 3 inventory action. However, even if the item-node are the same, each line counts as one action.

To achieve consistency across the availability response time, you must ensure that your availability request actions are kept under 100 actions per API invocation. If the total action exceeds the 100 limit, your application breaks up the request into multiple API invocations or you receive an API error. By adhering to this guideline that uses a distributive computing of real-time availability approach, you achieve improved storefront NPS®.

API Call is the number of request made to Sterling Intelligent Promising. A request can consist one or more API actions.

The Availability API consists of an Item (SKU) and a list of shipping locations, such as a node or distribution group. An action is measured by the number of unique SKU-Location combinations. For example, an availability request for the SKU1 with Node1 and Node2 results in two actions called SKU1-Node1 and SKU1-Node2. Following is a sample response message in case of response code - 400 bad request. 
{
   "error_message": "Number of actions in input (310) is greater than the tenant limit of 100."
}
The following availability request results in two actions per API invocation:
  1. Node availability with two actions on a single line: Mouse-Node01, Mouse-Node02
    {
  "lines": [{
  "lineId": "1", "itemId": "Mouse", "deliveryMethod": "SHP",
  "shipNodes": ["Node01","Node02"]
  }]
}
  2. Node availability with two actions on separate lines: Mouse-Node01, Mouse-Node02
    {
"lines": [
  {
    "lineId": "1", "itemId": "Mouse", "deliveryMethod": "SHP",
    "shipNodes": ["Node01"]
  },
  {
    "lineId": "2", "itemId": "Mouse", "deliveryMethod": "SHP",
    "shipNodes": ["Node02"]
  }
 ]
}

Similarly, the following API results in 10 actions:

{
  "lines": [{
  "lineId": "1", "itemId": "Mouse", "deliveryMethod": "SHP",
  "shipNodes": ["Node01","Node02","Node03","Node04","Node05","Node06","Node07","Node08","Node09","Node10"]
 }]
}

Use the network availability request for large number of nodes

In Sterling Intelligent Promising, to eliminate the requirement to specify a long list of node locations, you can use the distribution group availability instead of node availability. For example, the previous API request with 10 actions is simplified into the following format:

{
  "distributionGroupId": "DG_Node1-to-Node10",
  "lines": [{
  "lineId": "1", "itemId": "Mouse", "deliveryMethod": "SHP"}]
}

This request results in 1 availability action instead of 10 as in the node availability request.

Splitting Availability request examples

If an availability action exceeds the action limit, you must break up the API request logically by using the following steps:
  1. By Cart or Order Line (Single SKU, Multiple Node)

    For example, the e-commerce application needs to find availability for SKU01, across all 300 nodes. The API request might look like this:

    • Request1: SKU01 [Node001 to Node100]
    • Request2: SKU01 [Node100 to Node200]
    • Request3: SKU01 [Node200 to Node300]
  2. By Node (Multiple SKU, Single Node)
    Use this scenario when you have many SKU on the cart or an order greater than the limit. You must break up the request that is sorted by node.
    For example, if you have a large order with 200 SKU and there are 100 nodes, your request breakup might look like this:
    • Request1: SKU001 [Node001-Node100]
    • Request2: SKU002 [Node001-Node100]
    • Request3: SKU200 [Node001-Node100]

Optimizing the response time for the reservation API request

The reservation API accepts a maximum of 500 actions per API request to reserve cart-line or order lines quickly. By keeping a fixed action across all reservation requests, you can optimize the load between the ongoing availability and the reservation call across all requests that are made by your e-commerce application. The application might return an error response if the action count is beyond the 500 action limit per API.

You measure a reservation action by the number of SKU and location combinations. The location can either be node or a distribution group. The following reservation requests result in 2 reservation actions per API.

Example 1: Network reservation
{
"reference": "CART1",
"lines": [
{"lineId": "1", "itemId": "SKU01", "deliveryMethod": "SHP","distributionGroup": "NA_Group", "quantity": 3}
{"lineId": "2", "itemId": "SKU02", "deliveryMethod": "SHP","distributionGroup": "NA_Group", "quantity": 5}
]
}
Example 2: Node reservation
{
  "reference": "CART1",
  "lines": [
  {
     "lineId": "1", "itemId": "SKU01", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 3}
     {
        "lineId": "2", "itemId": "SKU02", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 5}
  ]
}

Splitting the reservation request example

If you have a large request for a reservation with over 500 lines, in this scenario you must break up the reservation into multiple API requests to stay within the 500 action limit. For example, if you have 1000 reservation lines for an order, you might have multiple requests:

Reservation request 1
{
   "reference": "CART1",
   "lines": [
   {"lineId": "1", "itemId": "SKU001", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 3}
     {"lineId": "2", "itemId": "SKU002", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 5}
     ....
       {"lineId": "3", "itemId": "SKU500", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 5}
   ]
}
Reservation request 2
{
  "reference": "CART1",
  "lines": [
  {"lineId": "1", "itemId": "SKU500", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 3}
    {"lineId": "2", "itemId": "SKU501", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 5}
    ....
      {"lineId": "3", "itemId": "SKU1000", "deliveryMethod": "SHP","shipNode": "Node01", "quantity": 5}
  ]
}