# Webhook Circuit Breaker As you might already be aware, we have a retry logic (3 attempts) in place for dealing with request failures (Read timeout/ *Bad Request/ Connection time-out)* while making the webhook callback to 3rd party URLs. In order to keep our infra stable and to avoid making repeated retries to those systems whose webhook endpoints are DOWN for prolonged time or throwing the same set of BAD REQUEST, again and again, we have come up with an implementation termed as a - *Webhook Circuit Breaker* (WCB). For the communication of an external system and ours, we have kept a **Connection timeout of 3 seconds** and **Read timeout of 5 seconds**. It is expected that any third party listening to our webhooks data is responded back within this time window. When a 3rd party system URL throws more than 15 request failures within a minute for particular biz, our system detects that breach and automatically disables all the webhook endpoints configured for that biz. At this point, the webhook callback is said to have *tripped* the circuit breaker. The disabled webhook endpoints will be of the same domain originated URLs. When the WCB is tripped, no webhook payloads will be pushed to the particular 3rd party URLs. If even a single webhook callback URL (*say Rider Status Update*) associated with the 3rd party breaches the throttle, then other webhook callbacks associated with the same hostname will also be disabled. Our system checks from which domain/hostname we are receiving the failures and when the failure rate is breached, our system automatically disables all the webhook endpoints associated with that same domain URL. The time for which all webhooks configured for a particular host will be deactivated depends on the number of times the WCB has tripped in the past week for the same host. If there have been >= 5 incidents in the past week, all webhooks will be disabled for 3 mins. If the number of incidents is less than 5, then the webhooks will be disabled for 1 min. For the orders which were not relayed in the timeframe of webhook deactivation, our system tries to push them at once when the webhooks are re-enabled. When we try to re-push the data and at that time if the third-party system is not responding again, the WCB will get triggered again. We have an email notification trigger in place when the WCB gets tripped. Please check with the concerned ACM/OM/Integration PoC to get it configured for the business you on board to our platform and also share the list of email ids to get the notifications. You can also configure your email ids under the **Contact Emails** field in Quint's *Business Profile* page to receive email notifications. The email alert will provide you with the details of: * short information about WCB * which business was impacted * which all URLs got disabled * Count of WCB tripped in last 7 days * Status code The email alert notification will have a subject - *Webhooks disabled: {{**biz\_name**}}*. **Note:** When the webhooks are enabled our system try to push the unsent orders at once to your URLs. In this event, whatever the state of the order present in the Urbanpiper system, the same will be present in the Order Relay payload under the state/order\_state attribute.\ \ For example - At the time of order push in retry attempt, if the state of the order is Acknowledged in our system due to status change happening from aggregator, then in the order relay payload, the state/order\_state attribute will have the *Acknowledged* status instead of *Placed*. Please make sure that you do not expect only a Placed state value to be passed in that attribute. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.