Duplicate Orders Served to API Software
tpbola
Posts: 9Member
in Development
Hello! I'm wondering if anyone has seen this issue. We have an API that sends our orders to Postmates for delivery. It seems that Lightspeed is sending duplicate orders to the software. Our developers have suggested creating a database to assign unique identifiers and reject the second copy.
I'm wondering if there isn't a simpler answer though Lightspeed. I tried toggling some of the email notifications but it that piece doesn't appear to interact with this problem.
I'm wondering if there isn't a simpler answer though Lightspeed. I tried toggling some of the email notifications but it that piece doesn't appear to interact with this problem.
Tags:
Answers
There are a large number number of things your developer could be experiencing, it's best get them to join the forums and explain here themselves.
We built a piece of middleware that listens for the webhook from Lightspeed when a submitted order with the shipping method selected as Postmates is marked as paid. Once received we post the order to Postmates - the problem is that the webhook is sending the order details a 2nd time once the order is marked as complete and our middleware has no way of differentiating between a new order and a duplicate, unless we add a database that stores the unique order id so we know not to send the same order twice. This option will cost a bit more for the client as we have to build that database and the logic, for obvious reasons, he is trying to avoid this.
The order webhook you've implemented must be listening for all events For orders there are 5 events you can subscribe to. These are:
Created
Updated
Deleted
Paid
Shipped
If you want to only listen for the paid event then I would suggest only subscribing to the "paid" event to avoid getting that same data sent to you from the "updated" event.
We experience something simluar: we use multi-shop and webhooks to trigger additional functionality. The webhook (in this case for updated variant) however seems to trigger multiple times and more-or-less randomly when we expect only one trigger. Webhooks even get triggered during nighttime when it is highly unlikely anyone is updating a variant. See screenshots.
Can you enlighten us on how many times a webhook gets triggered for one action? Any batch runs we don't know off?
It's hard to diagnose the root of these issues without having a more intimate knowledge of how your code engages with our software.
In the next instance you get a duplicate payload via a webhook, could you both send those payloads along with your shopID in my inbox and I will try my best to track these elements.
If this persists, I'd be happy to file a bug but if we can't reproduce, then we can't fix.
Regarding the @DocUnid, I've been able to reproduce duplicate webhooks fires just by hitting the save button in the backoffice for the updated variant event because the timeStamp is updated. In addition, the variant would be updated based upon a sale.
From the time stamps provided it doesn't seem unreasonable for someone to place order/make some meta changes and or just hit the save button at those times to cause that webhook to fire
I had a situation where I inserted an invalid webhook into my webhook endpoint (was a typo) and naturally I didn't receive any data for the configured event.
However when I fixed my URL and then triggered another event, it sent me the payload from the event and then about a minute later it sent two other payloads from those previous failed attempts of webhook reception.
To use webhooks and be on the safe side I would suggest you persist a version of the time stamp and payload and potentially compare to the previous timestamp you have against the ID of the variant/sale etc.
Add some business logic which removes the data but keeps the IDs for checking purposes. Something like MongoDB, Redis or Memecache might be useful for this.
Below is my log (UTC timestamps). Account ID is 176625. Hope this helps!