Suggested ways to handle different webhook scenarios.
In this section, we talk about ways to handle different scenarios when working with webhooks and suggest ways to ensure your webhooks work seamlessly with your integrations.
Built-in Retries
To mark a webhook as delivered, ZWITCH expects an HTTP 200 response code from your endpoint within 5 seconds. We consider any other response code, or no response code, a failed delivery. When this happens, we retry the delivery.
- In live mode, webhook delivery is retried every 30 minutes for 3 hours. After 3 hours, we retry it every 6 hours for the next 7 days.
- In sandbox mode, webhook delivery is not retried.
Retries to Deleted or Disabled Endpoints
ZWITCH stops retrying the delivery of an event if you delete or disable your webhook endpoint when the event is being retried.
In such scenarios, you can use the Retrieve Events API to get a list of all webhook events triggered by you.
Duplicate Payloads
Your webhook endpoint may receive the same webhook more than once. This could be due to webhooks retries, network delays, or other technical reasons.
To ensure you do log the same event multiple times in your system, we recommend making your event processing idempotent. You can do this using the webhook event id that is sent as part of all webhooks.
The webhook event id is in the format evl_sMRKnPcb82tGfmpqmNgQyquRn.
One way to make your event processing idempotent is to store webhook event ids in a persistent store. When you get a new event, check if the event id is already logged in the persistent store. If the webhook event id is present, it is a duplicate and you can ignore it.
ZWITCH retries webhooks for 7 days. You can safely purge the webhooks event ids after 7 days.
Order of Events
While webhooks are triggered in a particular order, it is not necessary that they reach you in the same order. This could be due to webhook retries, network delays, or other technical reasons.
For example, you might get the transfer.updated event before the transfer.created event.
Ensure you configure your webhook endpoint URL to handle these scenarios.
Poll APIs for Status
We recommend polling our API to get the status of an event.
Do not rely on webhook to get the status of an event.