LS System Id and URL

danipdanip Posts: 10Member
What happened? When we update a record, we use the system ID for the URL to post the update but it appears for our client, after ID 5656, the all items are off by 1. Somebody must have deleted a database record to throw off the increment count?
LS SystemID 210000005657 has URL Id of 5656 so when we update, it updates the wrong item. Does this mean we first have to look up the item and get the itemID before we can generate an update URL?

Please advise.


  • danipdanip Posts: 10Member
    Here is a screenshot.
    ??? can you make system ID and itemID match again?

  • Adrian SamuelAdrian Samuel Posts: 400Moderator, Lightspeed Staff moderator
    Hey @danip, thank you for your question! 

    It is possible for the DB to have record changes from UI actions.

    For example if for some reason an item was merged, then the record for that data will disappear, and sometimes you'll find that the itemID next in the list will resync back to take the space of that removed item.

    I would advise you resync your item data using the systemID as the master record. If this is something that occurs often, then periodic resyncs would be recommended.
  • danipdanip Posts: 10Member
    edited October 2018
    Thanks @Adrian Samuel 
    Even if we resync item data, the systemID never changes correct? So if we need to update an item with systemID 210000005657 we need to first make an extra trip to LS API to retrieve the itemID so we can compile the URL /Item/5658.json. Is this correct? I'd hate to have to do an extra trip to get the itemID. It does not allow to make an update call on /item.json?systemSku=210000005657
  • Adrian SamuelAdrian Samuel Posts: 400Moderator, Lightspeed Staff moderator
    @danip that's correct, the systemID never changes. 

    You're correct, you would have to do an extra trip since the method isn't available with the systemID parameter, however GETs cost only 1 point in your bucket and runs very fast.
  • danipdanip Posts: 10Member
    @Adrian Samuel , thank you.
    GET's might only cost 1 point but in our client's situation we can't do an extra trip. We update several thousand items throughout the day and have had a ton of problems with 429. API limits on LS has been one of our biggest development nightmare.
    Since the "itemID" is more crucial than "SystemID" in terms of API usage in URL's, would it be possible to add the itemID to the export function of inventory, so we can import it into the client's system for faster mapping and lookup?

  • Adrian SamuelAdrian Samuel Posts: 400Moderator, Lightspeed Staff moderator
    edited October 2018
    @danip ;Ahh I see, PUT requests will really slow things down a lot. How are you currently handling rate limiting? As long as you check the response headers per request you should be able to let your app pause requests periodically.

    I understand the aim, but since the itemID isn't used for anything outside of third party development it's unlikely it's going to be added to the UI where the majority of our customers wouldn't have any benefits.
    Saying that, I do encourage you to put your ideas in our suggestions channel:

    Our development team periodically review this
  • danipdanip Posts: 10Member
    @Adrian Samuel, yes we are using all the available features such as bucket size and drip rate and have a system in place to pause the script etc etc but with as many records as our client updates, the LS rate limiting has been killing us. I have discussed this before elsewhere on here but it's okay. Thanks for your input.

    I am however, very confused on the LS System ID. If the systemSKU never changes and is the true Id and if it's possible for an itemID to change in a delete or merge event, why is itemID used for API URL calls? /API/Account/{accountID}/Item/{itemID}  Shouldn't an item call be made on an unique, never changing ID? {itemID} should be {systemSKU} in my opinion.. 
  • Adrian SamuelAdrian Samuel Posts: 400Moderator, Lightspeed Staff moderator
    Thank you for sharing these concerns with us @Danip, I understand how this can prove to be difficult if you have a high amount of write requests. There are conversations being had to explore options expose methods that will enable API hungry apps to more efficiently integrate with our app.

    Regarding the latter point, the itemID is the master key but due to how our app is configured, the itemID under this specific condition of merging makes the itemID subject to change whereas the systemID isn't. I do understand your frustration though
Sign In or Register to comment.