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, do not 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 let us know that you're planning on handling a callback asynchronously, your webhooks should immediately acknowledge it by sending an HTTP status code of 202 Accepted. Once that 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 and 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 example, let’s say you have three testing environments: A, B, and C. Each has a unique webhook address within the same Digital River Dashboard account, and all are listening for the event with a type of order.accepted. If you create an order in A and its state moves to accepted, then your webhook handler in that environment is likely to succeed. But since 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