Editing the Request

The original body was small and promising:

{"storeNumber":"...","upc":"..."}

Once translated into Python and replayed, the response came back with all the fields a stock checker actually needed: product identity, retail pricing, image URLs, and a size list with per-SKU quantities.

{
  "description": "DUNK LOW RETRO",
  "displayName": "Nike Dunk Low Retro Casual Shoes",
  "currentRetail": 110.0,
  "skus": [
    { "size": "6.0", "quantity": 0 },
    { "size": "6.5", "quantity": 2 }
  ]
}

At that point the API was already useful, but it still depended on UPCs, which are not always convenient to source in bulk.

Going a Step Further

A better interface would use style and color instead of UPC. To find out whether those fields existed, I decompiled the Android app with JADX and searched for the endpoint in the source.

The request model exposed optional parameters including style and color. That was the breakthrough, because style-color identifiers are much easier to obtain than UPCs in the sneaker ecosystem.

{"storeNumber":"...","style":"...","color":"..."}

Replaying the request with those fields returned the same inventory structure, which made the endpoint materially more useful in production.

Conclusion

With the improved parameter set, the mobile app endpoint could be folded into a real stock monitoring pipeline. That turned a manual reverse engineering exercise into something much closer to a product surface.

This article is for educational purposes only. I do not condone using this information maliciously.