## TL;DR
DocuSign Connect marks a webhook 'retries exhausted' after it fails to deliver an envelope event to your listener repeatedly. Almost always the listener is at fault: it returned a non-2xx status, took too long to respond, failed the TLS handshake, or blocked DocuSign's IPs. Open the Connect logs in the admin console, replay one failed message, and fix the listener to acknowledge fast (2xx within seconds) while processing asynchronously. Replay, don't rebuild, to recover the missed events.

## The query
```text
DocuSign Connect webhook 'retries exhausted'  -  envelope events never delivered
```

## Use this when
- Connect shows failure status or 'retries exhausted' and envelope events never reached your system
- Your listener works from curl but Connect deliveries keep failing
- Events stopped arriving after a deploy, cert renewal, or firewall change

## Not for
- Connect events that arrive but with missing fields - that is a message-format configuration issue
- Polling the envelopes API instead of webhooks - different mechanism, different fixes
- Events delayed by minutes but eventually delivered - that is normal Connect latency, not a failure

## Steps
### 1. Read the Connect failure logs, not your application logs first
In the DocuSign admin console go to Settings, then Connect, then Logs. Each failed delivery records the HTTP status your listener returned (or the connection error), the response time, and the retry timestamps. The pattern tells you the cause: 4xx means your app rejected it, 5xx or timeouts mean your app died mid-request, connection errors mean network or TLS.
Expected output: a log row per failed event with status code, latency, and the exact error DocuSign saw.

### 2. Replay one failed message from the log
Select a failed delivery and use the replay (acknowledge and republish) action. This resends the identical payload, so you can debug against the real event without waiting for a new envelope to move. Make your handler idempotent first: replays can arrive twice.
Expected output: the replayed event hits your listener and you see the request in your own access logs.

### 3. Make the listener acknowledge fast and process later
Connect expects a 2xx response quickly; doing database writes, PDF downloads, or downstream API calls inside the request handler routinely exceeds the window. Return 200 immediately, enqueue the payload, and process it in a worker. Log the envelopeId with the queue entry so a replay can be matched to the original.
```python
@app.post("/docusign/connect")
def connect():
    queue.enqueue(process_event, request.data)  # fast
    return ("", 200)
```
Expected output: p99 response time under a couple of seconds and no more timeout-driven retries.

### 4. Fix the TLS and network path
Connect requires a publicly trusted TLS certificate with a complete chain - self-signed or expired intermediates fail the handshake. If you use mutual TLS, the client certificate must be current. Also confirm your firewall or WAF allows DocuSign's published IP ranges; a silent drop looks exactly like a timeout in the Connect log.
Expected output: a TLS checker shows a clean chain, and the Connect log shows 200s instead of connection errors.

### 5. Recover the missed events, then watch the next live one
After the listener is healthy, replay the failed messages from the log in chronological order so your system state matches reality. Then trigger a test envelope and watch a live delivery end to end before calling it fixed.
Expected output: the replayed events process cleanly and a fresh envelope's events arrive within minutes.

## Tool compatibility
DocuSign Connect (webhook) on eSignature accounts, all plans that include Connect. Listener can be any HTTPS endpoint. Companion: the Connect log viewer in the DocuSign admin console. Applies equally to the legacy and the current Connect configuration UI.

## Variant phrasings
- DocuSign Connect webhook retries exhausted envelope events not delivered
- DocuSign Connect failures listener not receiving events
- Connect message status failed DocuSign webhook troubleshooting
- DocuSign webhook never delivered retries exhausted how to replay

## Why it happens
Connect is a fire-and-retry delivery system with a limited retry budget per message. It cannot distinguish your app being down from your app being slow, so any slow or failing endpoint burns retries until the message is marked exhausted. The design assumes listeners are thin acknowledgers with async workers behind them; anything heavier turns normal latency into delivery failures.

## Edge cases / pitfalls
- Connect retries use exponential backoff, so the first failures after a deploy may be minutes old before you notice - alert on the failure log, not on missing data downstream.
- Replays deliver the original payload, so a handler that is not idempotent will double-apply events.
- Switching your listener URL does not auto-replay exhausted messages; you must replay them manually.
- Envelope-level and account-level Connect configurations are separate - check you are reading the log for the right one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6DMqC08o05Oy_dOygBXtPQ