Zintara webhook delivery failures: best-effort dispatch and recovery boundaries

Define the decision

The reviewed dispatcher attempts subscribed active endpoints and records delivery status. It does not provide a durable outbox, scheduled retry policy or replay guarantee. A successful test also does not prove every later business event will arrive.

Work through the procedure

1. Inspect endpoint status and delivery history alongside receiver logs.
2. Separate DNS, TLS, timeout and non-2xx responses.
3. Fix the receiver or configuration and run a controlled test.
4. Reconcile business state for the affected interval through an approved process.
5. Keep future receiver processing durable and observable.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Endpoint accepted a request but the connection timed out before the response arrived
Sender records an error
Receiver may already have queued work
Recovery: inspect receiver receipt history before manually repeating a side effect

Read the result

This ambiguity is why a retry decision needs evidence. Returning 2xx before persisting anything can also lose work even when the sender reports success.

Check before moving on

1. Alert on receiver queue failures, not only HTTP failures.
2. Distinguish a test.event delivery from a real reply or bounce event.

Limits and next action

The test endpoint can report a delivery-history persistence problem after attempting the HTTP request. Check the receiver before retesting, and do not claim guaranteed delivery from the current implementation.

Source: Zintara product context