It’s related to backend development.
Goki tries to deliver the third-party webhooks 100 times for up to three days.
On each day, if there were any failures - the endpoint has been disabled or deleted when Goki attempts - Goki will send an email to notify you that the webhook has an issue and you need to fix it.
We will notify you after 1 day and disable the webhook on day 3.
However, if the app owner disables and then re-enables a webhook endpoint before we’re able to retry, you can still expect to see future retry attempts.
After fixing, you can enable the webhook, or let us know to enable it for you.
Notes:
Goki will attempt to notify the app owner of a misconfigured webhook endpoint via email if the endpoint has not responded with a
2xxHTTP status code for multiple days in a row.The email also states when the endpoint will be automatically disabled.
After 1 day in case of failure, we will send an “Endpoint issue” email to notify the app owner about it, and if it remains after day 3, we will send a “Webhook is disabled” email.
Webhook endpoints might occasionally receive the same event more than once. Goki advises the app owners to guard against duplicated event receipts by making the event processing idempotent. One way of doing this is logging the events they’ve processed, and then not processing already-logged events.
Limitation
If the endpoint is disabled or delete, Goki does not guarantee the delivery of events in the order in which you are generated. The app owner’s endpoint should not expect delivery of these events in any order and should handle this accordingly.