Skip to main content

Webhook Dispatcher — AI Integration

Status: populated Owner: Platform Engineering Last updated: 2026-04-18

1. Current AI Usage​

The Webhook Dispatcher does not use AI/ML models in its core delivery pipeline. All logic is deterministic (retry backoff, HMAC signing, HTTP delivery).

2. Planned / Future AI Enhancements​

2.1 Intelligent Retry Backoff Optimisation​

Problem: Fixed exponential backoff may be suboptimal for customers whose endpoints have predictable maintenance windows (e.g., nightly restarts at 03:00 UTC). Approach: Per-webhook learning model that adjusts retry intervals based on historical delivery success patterns. Simple time-series classifier (low-dimensional features: hour-of-day, day-of-week, recent failure rate). Constraint: Must fall back to default schedule if model unavailable. Model inference < 5 ms per webhook.

2.2 Anomaly Detection for Endpoint Health​

Problem: Dead-letter events alert after 5 failures (~10.5 hours delay). Earlier detection of endpoint degradation improves customer notification speed. Approach: CUSUM (cumulative sum) control chart on per-webhook http_status_code and latency time series. Alert when degradation score exceeds threshold — independent of retry exhaustion. Owner: SRE / Platform Engineering (future epic EP-HOOK-06).

2.3 Webhook Payload Summarisation for Support​

Problem: Customer support engineers investigating dead-letter events must manually parse payload_snapshot and response_body_preview fields. Approach: Internal LLM-assisted incident summary: given the last 5 delivery_attempts rows for a dead-lettered delivery, generate a human-readable incident summary. Constraint: Internal tooling only; no customer PII sent to external LLM APIs; phone numbers redacted before summarisation.

3. Integration Constraints​

  • No AI inference in the synchronous HTTP delivery path.
  • All AI features are observability/operations enhancements; degraded gracefully when unavailable.
  • Phone numbers (to field) never sent to external AI endpoints.