GET /api/product_inventory/ _very_ slow

markguertin

Hi folks.  Most other things return at fairly reasonably speeds.  Things like GET /api/products returns approx 25k products in ~10 seconds.  But when calling GET /api/product_inventory/ on the same server and data set I'm seeing more like 8-10 minutes.

Is this expected or is something not indexed that should be?  This seems like something might be wrong behind the scenes so wanted to check in.

jamesratcliffe

@markguertin
I ran some tests on different databases, and the product_invenotory call is consistently much longer. The call is just a lot more intensive.

I'd recommend breaking the call into multiple pages:

GET /api/product_inventory/?count=100
GET /api/product_inventory/?count=100&offset=100
GET /api/product_inventory/?count=100&offset=200
...

markguertin

Hi James, thanks for the info but not sure that's really a great approach.  While I'm talking about 25k items here (so with your method that's 250 calls) I also have to do this a dozen times over (multiple stores), so that's taking 12 API calls and turning it into 3000 API calls.  There also doesn't seem to be a way for me to figure out the number of items that I would need to loop to (i.e. I can't call /api/product_inventory/ and have it just tell me how many items I need to deal with).  Also worth pointing out is that I'm seeing inconsistent numbers between calling /api/products/ and /api/product_inventory/ in terms of total number of items.  

At that point instead of having to do guesswork and manage thousands of calls I'll just stick with 12 and take the medicine and wait 10 minutes per call and hope they don't time out too often.

It really does sound like something on the backend is not indexed that should be IMHO.

jamesratcliffe

It's normal that the total number of items will be different on those 2 endpoints; the product endpoint includes non-inventoried items.

Do you need to pull all products from product_inventory on a regular basis? If you want to look for changes to inventory, you can use the /api/products/search/ endpoint and filter by inventory_version. The inventory_version is a sequence that's incremented with every inventory change in the OnSite database. The product whose inventory version changed is assigned the current value of the sequence.

To use this, keep track of the highest inventory version value that you've seen on your end. Then when you want to check for inventory changes, you just have to find all products whose inventory version is higher than that number.

The filter in your search payload would look like this:

<filters>lsserver.search.filters.inventory_version &gt; 220</filters>

Where you would replace 220 with the last value you have saved.

The product search endpoint is explained more in this tutorial:

https://www.lightspeedhq.com/onsite-docs/external_api/tutorials/products.html#search-by-description


I'll bring up the response time with the Development team. I think you are right that there's no reason it should be that much longer.

markguertin

Thanks James, I will check that out and see if it's suitable for our needs.  And yes we will need to be tracking inventory changes very often, likely once a day at minimum.  I'm not sure that this will be a great solution either but it's worth looking at to see how it will work for us.

I'm happy to work with anyone on the dev team if desired as well, ping me anytime and thanks for forwarding this along to them.

markguertin

If I'm understanding how this works correctly would I also be able to use this track new products?  I just did a quick test and it seems like this would be possible as new products (even with 0 inventory) seem to get assigned a new (incremented) inventory_version value.

Am I understanding correctly?  If so then this would likely be pretty useful for us (but I will have to rework a bunch of code to make it happen).

jamesratcliffe

Yes, it would work, even for non-inventoried products.

There's also a `created_date` filter that you can use to get newly created products.

You can combine multiple filters:

<filters>
    lsserver.search.filters.inventory_version &gt; 220 OR
    lsserver.search.filters.created_date &gt;= '2018-07-09'
</filters>

markguertin

Thanks, understood.  The inventory_version filter should be good enough to catch everything I need to catch though.  I will probably look at making these changes later this week and see how it works out for me, thanks.

jamesratcliffe

You're welcome.

markguertin

Seems to work well. 

Makes me a bit nervous to run deltas like this though as it doesn't seem like I have any way to reference any information about the details of the last inventory_version to find out when it happened.  Am I correct in assuming there's no way to check an inventory_version from the API to see when it occurred?

jamesratcliffe

No, you can't see the time when the inventory level changed using the API.