It’s possible that the relevant sites haven’t had any relevant activity that would trigger webhooks. The easiest way to begin troubleshooting this is to call a related List or Query endpoint for a relevant site. For example, if you haven’t received an Event Guest Created webhook in 24 hours, you can call the Query Event Guests endpoint, sorted by created date, and compare the returned data with the data on your server.
If the returned data includes guests that your app didn’t receive webhooks for, Wix recommends the following:
Duplicate webhooks are generally sent when Wix believes that the webhook was not received - so make sure you are sending a 200 success response so Wix knows the webhook was received. Otherwise Wix will continue to send duplicates.
For various reasons, inclding any delays from Wix's servers or when a delivery attempt fails, Wix will make additional attempts to send the webhook. See the webhook resend policy for details.
This might mean that you'll receive webhooks out of order, or, occasionally receive duplicates, so make sure your app can handle these scenarios.
Duplicate webhooks will always include the same data, even if the entity has been updated since. Chances are that you aren’t sending the expected 200 status, so Wix is continuing to send retries. The webhook data won’t update between retries.
Most of Wix’s webhooks include the full entity that was created or updated, but in some cases, (generally legacy webhooks) it won’t return all the data stored for the entity. In these cases, if you need the data that isn’t returned in a webhook, you can call the relevant Get endpoint with the entity ID returned in the webhook to get the full entity.
For example, the legacy Wix Stores Product Changed webhook only returns the fields that were updated in a flat list, and not according to the object structure returned in the calls.
Alternatively, you might find that data that is documented as returned in a specific webhook isn’t being returned. This means that those specific parameters aren’t required, and in this instance we don’t have any data for it.
Sometimes, when your app uses advanced OAuth, a site owner that has installed your app will duplicate their site, and your app will automatically be initialized for that app. Because they didn’t actively install, your app won’t have access and refresh tokens to make calls for the site, but you may automatically be signed up for webhooks for that site.
Here's what you can do:
originInstanceId, which is the app instance ID from the original site, so you’ll know which user the site is associated with.Wix's infrastructure is eventually-consistent. In some rare cases your server may receive a webhook while some of the database replicas are still behind. Most webhooks include the full entity that was created or updated, so whenever possible you should use the webhook response rather than making a GET call for the latest state of the entity. If your webhook handler tries to get data from the API, and fails with 404 (not found), you should retry the call after a few seconds.
Webhook eventTime timestamps are sent in ISO-8601 format and UTC time. For example: 2020-04-26T13:57:50.699Z