Preventing webhooks from getting disabled
Gain a better understanding of what causes a webhook to get disabled and how to prevent it from happening
To reduce stress on our nodes and minimize unwanted downtimes, Digital River automatically disables webhooks that repeatedly time out, fail to respond, or return errors.
To prevent a webhook from being deactivated, we recommend that you:
Respond immediately
Make sure your webhooks 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 event on your end.
Deselect problematic events
If you have a webhook that frequently fails or experiences timeouts, it might be subscribed to an event containing JSON keys that it can't process. To solve this, either deselect the problematic event by editing the webhook in the Dashboard or modify your handler’s logic. Additionally, ensure that the webhook only subscribes to events required by your application and deselect any that are not.
Provide informative error messages
If the data.object of an event 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 is able to better identify and resolve the problem.
Keep endpoints available
Your webhook endpoints should always be up and running. If you plan on terminating an endpoint after your testing is complete, first disable the webhook that it belongs to. You can do this in Dashboard or by submitting a webhook patch request with enabled set to false.
Map test environments
Your Digital River account gives you access to two of Digital River's environments, test and production. 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 webhook endpoint that handles the same event and they're all saved to the same Digital River test account, you're likely to 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 event order.accepted. If you create an order in A and its state changes to accepted, the webhook handler in that environment will likely succeed. However, because that order doesn't exist in B and C, the handlers in those environments will likely return an error.
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 that have values which exist in your environment, thereby reducing the probability of returning an error.
Last updated