Re: Webhook for order status changes (Ready for delivery) on a Local Delivery

Webhook for order status changes (Ready for delivery) on a Local Delivery

rodrigo5
Tourist
4 0 3

I'm attempting to get a webhook notification when a local delivery order changes status to "Ready for delivery". I'm subscribed to the "ORDERS_UPDATED" webhook, however no events come in for that action. Am I missing something?

Replies 9 (9)

aqoraan
Tourist
10 0 2

Hello Rodrigo,

I'm looking for same webhook, I'm trying to customize it as well. Did you manage to trigger that events?

AlbertoVromo
Tourist
4 0 0

same problem here

chrisgraeme
Tourist
3 0 0

same here - anybody worked this out yet?

chrisgraeme
Tourist
3 0 0

heya did you work this out?

aqoraan
Tourist
10 0 2

Hi,

In my case I did a workaround. I've used "product update webhook":

- When the product is ready for pickup, I add a tag called "ready-for-pickup"

- The webhook get triggered on every product updated, but only send to shipping company order details if the product has this tag.

I know this the not the best way to do it, but I couldn't find any alternatives.

AlbertoVromo
Tourist
4 0 0

Hi ! thanks for the update.

I tested the product_update webhook, however, I didnt receive anything when the order state changed to "ready to be delivered" .

Am I missing something? thanks in advance

aqoraan
Tourist
10 0 2

My bad, I meant order-update webhook. Sorry for the confusion. 

  • None of the available webhooks will be triggered by state changes to "ready to be delivered". I've used google scrip app to act as a middleware and check for the needed tag exist in current "order" json, if it exist then pass this order to shipping service.
AlbertoVromo
Tourist
4 0 0

sounds interesting, however, I still dont fully understand it. Would it be possible that I could get a copy of that script? thanks in advance

rodrigo5
Tourist
4 0 3

Hey, I did not manage to make it work, for now we created a separate button on our app that the merchant can click on to let us know it's ready, and we update the status in reverse from our end, however it's not ideal since they have to manage two separate workflows. Still waiting for them to implement it...maybe now that the issue got some traction