Issue with Inventory not syncing with what's in the Item Library

Hi there,

I have a merchant running into an issue with our Inventory integration, specifically they have a single item variation that won’t update inventory when attempting to set it in the Square Item Library via an “Inventory re-count” stock action. When querying the Retrieve Inventory Count API (GET /v2/inventory/{catalog_object_id} - Square API Reference), this item variation shows no results, yet other item variations for the same item do. Interestingly, querying the Catalog API we see this:

 "location_overrides":
[
     {
        "location_id": "L10HN4B7TGA45",
        "track_inventory": true,
        "sold_out": true
    }
]

Any insight as to what’s going wrong here? I can provide more info as needed, the Catalog Object ID is EYJYJZKH5MNK45KYZB3V2DHQ.

:wave: This is the correct API response since it’s sold out. Do you have any additional information to what the customer was running into? I was able to go to the item in the Dashboard and see that adjusting the inventory is working as expected. Did they get any errors?

Hi Bryan,

Apparently the item has stock in their Square Dashboard Item Library, but no webhook has triggered to pass that information on our integration, and when you query Square’s Inventory API (https://connect.squareup.com/v2/inventory/EYJYJZKH5MNK45KYZB3V2DHQ), the response is completely empty. Shouldn’t there be something here?

Looking at the item in the Seller Dashboard there isn’t any stock for that item variation for that location so the empty response is expected.

Hi Bryan, yup exactly - so the question is why is this merchant able to perform inventory adjustments in the Square Dashboard for this item variation, but the API response is empty?

Which item variation are they updating? The one in this example hasn’t been updated at all on either the Dashboard or API. Is there a different variation that they are updating?

I’m not sure - supposedly the one mentioned above (EYJYJZKH5MNK45KYZB3V2DHQ), but I don’t have a way to verify that besides what we’re told…

There are other variations of that item that have inventory counts however that item variation doesn’t have any recent updates.

Yup, that’s what I mentioned in the original post - other variations of this item have inventory data but this item variation doesn’t for some reason, and supposedly the merchant is updating all of the inventory information in the Square Dashboard the same way. So either they are updating the wrong item variation (I’m guessing unlikely) or something is going wrong on Square’s end. If it’s the former, how can we verify that they are in fact updating the right item?

Yeah, but you mention they updated it in the Dashboard and currently in the Dashboard that item variation has no stock. Could you ask them to update the inventory in the Dashboard to where it’s showing stock for that item variation? Once it has stock then we can call the API to try and replicate this. Currently the API is reporting the same inventory count that is showing in Dashboard.

The merchant has already told us that they’ve tried that many times already - that’s why posted this originally. I sent them exact screenshots for the steps I use to update inventory and they said they’re doing the exact same thing! They’re performing the same “Inventory re-count” method that they usually do, and but for some reason that’s not propagating into the Square Dashboard/API/etc as we’d normally expect.

Would you mind having the merchant reach out to our Customer Success if they aren’t able to update the item on the Dashboard? You or I unfortunately can’t take actions on this merchants account to try to replicate the issue.

Hi Bryan, so I followed up with the merchant and they were able to get it to the expected state after some steps. They were originally expecting 0 stock, so the inventory re-count they were applying was 0. But apparently this wasn’t updating/propagating through under the hood, so they changed the inventory via a re-count action to 1 then back to 0. That triggered the webhook event as necessary for our integration.

That’s great that you figured it out. :slightly_smiling_face: