Preventing webhooks from getting disabled
Gain a better understanding of what causes a webhook to get disabled and how to prevent it from happening
Last updated
Gain a better understanding of what causes a webhook to get disabled and how to prevent it from happening
Last updated
To reduce stress on our nodes and minimize unwanted downtimes, Digital River automatically disables that repeatedly time out, fail to respond, or return errors.
To prevent a webhook from being deactivated, we recommend that you:
Make sure your respond to Digital River’s callbacks within 3000 milliseconds. Anything longer than that is considered a timeout.
To indicate that a callback will be handled asynchronously, your webhooks should immediately respond with an HTTP status code of 202 Accepted. Once the operation is complete, you can process the .
If you have a that frequently fails or experiences timeouts, it might be subscribed to an containing JSON keys that it can't process. Either deselect the problematic event by editing the webhook in the Digital River Dashboard or modify your handler’s logic to solve this. Additionally, ensure that the webhook only subscribes to events required by your application and deselect any that are not.
If the data.object of an is not what you expected, perhaps because it's missing a key or a value is incorrectly formatted, respond with an HTTP status code of 400 Bad Request. Ensure the error has a descriptive message. By detailing the specific issue (missing field, invalid value, etc.), Digital River can better identify and resolve the problem.
This doesn’t mean your Digital River test account should only contain a single webhook. There are valid reasons for having multiple endpoints. For instance, you might want one to handle order.accepted by initiating product fulfillment and another to handle fulfillment.created by sending an email to customers to let them know their products have shipped.
The recommended solution to this problem is to have a single environment on your end that maps to Digital River’s test environment. This ensures our webhook processor will deliver event payloads with JSON keys with values in your environment, thereby reducing the probability of returning an error.
Your webhook endpoints should always be up and running. If you plan on terminating an endpoint after your testing is complete, disable the webhook to which it belongs. You can do this in the Digital River Dashboard or by submitting a with enabled set to false.
Your Digital River account gives you access to two of Digital River's environments, . Your system, however, may have more than a single test environment. For instance, developers on your team might write code in their local environments and then promote it to dev, where QA runs various tests before advancing it to staging once they're satisfied with it.
However, if each of these environments has a different endpoint that handles the same event and is all saved to the same Digital River test account, you will likely encounter problems.
For instance, suppose you have three testing environments: A, B, and C, each with a unique webhook address within the same Digital River Dashboard account. All are configured to listen for the order.accepted. If you create an in A and its state changes to accepted, the webhook handler in that environment will likely succeed. However, because that doesn't exist in B and C, the handlers in those environments will likely return an error.