API of the Day: Checking IKEA Availability and Warehouse Locations

It’s 2015 and AJAX is everywhere, making our daily web browsing more enjoyable (most of the time). A nice side-effect from the more responsive web front-ends are the numerous APIs that have become available and that can often be accessed in an isolated way to retrieve raw data. While their documentations are usually not available to the public, we can still do some reverse engineering to understand their functionality and even embed them into some totally new usage scenarios.

A word of caution: these private APIs are subject to sudden change and the authors usually don’t want you playing with it — let alone put them to productive use. So while I think that they are fascinating areas for exploration and for understanding how companies work, I would like to urge you to think before running into trouble. Thanks!

Today, our API of the Day is provided by IKEA and allows us to check the availability of just about every IKEA article in just about every store. To do so, GET the following URL:

http://www.ikea.com/us/en/iows/catalog/availability/12345678

There are some parameters in here that we can modify:

  • us/en is the country to be queried and the language to be queried in. You may e.g. substitute de/de to check German stores only.
  • 12345678 is a placeholder for the product ID to be checked. Make sure to grab it from the URL to the product page (might contain a leading letter), not from the product page itself.

Let’s try an example and check the availability of a pair of AINA curtains in the US, article number 102.842.01 by GETting the following URL:

http://www.ikea.com/us/en/iows/catalog/availability/10284201

The result is impressive:

First thing we notice: the IKEA API (at least this very endpoint) is responding in XML, not in JSON — nothing we really appreciate, but also nothing we could not handle. Content, however, is a lot more likable:

Within the <availability> section, we notice notice multiple <localStore> blocks (I have removed all but one from the gist above for better readability). The property buCode helps you with identifying the store you are looking for (check this gist for store IDs in Germany and the US as of November 2015). Each of these <localStore> blocks contains a <stock> section, which then provides the real treasure:

  • The partNumber is just the article number we already know.
  • isMultiProduct is true for products that contain multiple products themselves (e.g. for combined book/TV shelves).
  • isSoldInStore let’s us know if the product belongs to the store’s portfolio.
  • I couldn’t yet figure out the meaning of isInStoreRange — help appreciated.
  • availableStock is the number of units currently available.
  • inStockProbabilityCode is the probability of being able to obtain a unit of this product in case you visit the store now.
  • validDate is the date the response has been generated.

On top, each <store> section contains a <forecasts> block with multiple <forcast> [sic!] sections, providing estimated stocks for the next days.

The <findItList> section finally show the exact physical location of the articles you are looking for. If they are stored within a shelf in the warehouse, you will be provided with the exact shelf and box number (<type> will be BOX_SHELF in this case). Otherwise, the API will provide a <type> of CONTACT_STAFF.

I am still looking for additional API endpoints that may help us find store IDs programatically (I just copied them out of an HTML document) and to search article IDs based on their names. In case you stumble across something, please make sure to let me know!

  • 2016–08–30: Fixed demo API link thanks to a hint from Coty Beasley. Thanks!

Venture Lead at day, iOS Indie Developer at night.

Venture Lead at day, iOS Indie Developer at night.