# Preventing webhooks from getting disabled

To reduce stress on our nodes and minimize unwanted downtimes, Digital River automatically disables [webhooks ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/webhooks)that repeatedly time out, fail to respond, or return errors.

To prevent a webhook from being deactivated, we recommend that you:

* [Configure it to deliver an immediate response](#respond-immediately)
* [Deselect problematic events](#deselect-problematic-events)
* [Provide descriptive error messages](#provide-informative-error-messages)
* [Keep your endpoints available](#keep-endpoints-available)
* [Correctly map test environments](#map-test-environments)

## Respond immediately

Make sure your [webhooks ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) of `202 Accepted`. Once the operation is complete, you can process the [event](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/events).

## Deselect problematic events

If you have a [webhook ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/webhooks)that frequently fails or experiences timeouts, it might be subscribed to an [event ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/events)containing JSON keys that it can't process. Either deselect the problematic event by [editing the webhook in the Digital River Dashboard](https://docs.digitalriver.com/digital-river-api/administration/dashboard/developers/webhooks/editing-a-webhook) 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.

## Provide informative error messages

If the [`data.object`](https://docs.digitalriver.com/digital-river-api/order-management/events-1#event-data) of an [event ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/events)is not what you expected, perhaps because it's missing a key or a value is incorrectly formatted, respond with an [HTTP status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) 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.

## Keep endpoints available

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](https://docs.digitalriver.com/digital-river-api/administration/dashboard/developers/webhooks/editing-a-webhook) or by submitting a [webhook patch request](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/webhooks#webhooks-id-2) 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](https://app.gitbook.com/s/ZrhMyLX5esFYS64lNWVW/digital-river-api-reference-guide/api-structure#test-and-production-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 [webhook ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/webhooks)endpoint that handles the same event and is all [saved to the same Digital River test account](https://docs.digitalriver.com/digital-river-api/administration/dashboard/developers/webhooks/creating-a-webhook), 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](https://dashboard.digitalriver.com/login) account. All are configured to listen for the [event ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/events)`order.accepted`. If you create an [order ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/orders)in A and its `state` changes to `accepted`, the webhook handler in that environment will likely succeed. However, because that [order ](https://app.gitbook.com/s/x8fSFzVR3sg0TsNWwwVz/orders)doesn't exist in B and C, the handlers in those environments will likely return an error.

{% hint style="success" %}
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.
{% endhint %}

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](https://docs.digitalriver.com/digital-river-api/order-management/events-1#event-data) with JSON keys with values in your environment, thereby reducing the probability of returning an error.