While testing out the webhooks, I encountered a strange sequence of events.
Instead of the normal happy path where I get the ff. events in order: package_delivering → courier_arriving (dropoff) → courier_waiting (dropoff) → package_delivered
I registered an endpoint on the sandbox portal and the endpoint runs on my local machine exposed using ngrok. I initially thought it could be just a network related issue, but I could be wrong since the timestamp on each webhook response is in order.
To provide an update, we have found a bug which seems to be causing the behaviour you are experiencing. We are working on the fix and will update you here of any updates.
Thank you again for raising the issue here, and we apologise for the inconvenience of the issue.
I encountered this issue twice, but when I encountered it for the first time, I was not able to save the JSON response I got back via webhook.
But I can describe the first time it happened: the status of a delivery changed from courier_arriving (pickup) → courier_arriving (dropoff) → courier_arrived (pickup) → courier_arrived (dropoff) → package_delivering → package_delivered
Again, I really appreciate your team’s effort looking into this.
We’re actively working on resolving the issue. Although we don’t have an exact timeline right now, I’d like to mention it has a high priority for us and you can rest assured that we’ll keep you posted on our progress.
Should you have any questions or comments in the meantime, please let us know.
Thank you for your patience, we have identified and resolved the issue with the ‘package_delivering’ webhook events being duplicated.
In regards to the ‘courier_arriving’ webhook events, I was hoping you could verify the ‘occurred_at’ time stamp of each webhook to confirm this was indeed sent in the wrong order and is not a retry mechanism issue?
I can confirm it was sent in the wrong order, i inspected the order of which my webhook received each payload, and it’s courier arriving + pickup → courier arriving + dropoff → package delivering → courier waiting + dropoff
Although, I reviewed the timestamps of the events courier arriving + pickup → courier arriving + dropoff, and both of them have the same timestamp (2023-12-06T06:44:04.918+01:00)
Thanks for this information I will feed this back internally.
Further on this topic, do you have a retry mechanism in place to force the retry of the webhook send?
I can confirm we have applied changes to our V3 webhooks to resolve this fault since our last message before the holidays and after testing this now looks to be correct.
Can you please confirm if you have been experiencing the expected behaviour from our webhooks now or if this issue has persisted?
I can see in this particular job it was not sent due to our sandbox bot courier completing the dropoff tasks early.
I have tested this myself and was not able to replicate the issue and received the “courier_waiting” & “courier_arriving” webhooks for the dropoff task.
May I suggest to also increase the distance in the addresses used for your sandbox jobs as the courier may already be in the dropoff geofence due to the close proximity of your current pickup & drop locations which is why these statuses are skipped.
To add to my point, I would like to refer to the v3 webhook key in our API docs which specifies the “courier_waiting” & “courier_arriving” webhooks are optional events.
I hope this helps & we look forward to your continued testing.