Webhook-Driven Call Event Automation for Outbound Operations

The Case for Event-Driven Telephony Architecture

A polling architecture for call events has a fundamental problem: latency is a function of your polling interval. If you poll for new CDRs every 30 seconds, your system's maximum resolution is 30 seconds. That means a supervisor dashboard showing "current" call counts is actually showing the state of the world as it was up to 30 seconds ago. For real-time floor operations, that lag is significant.

A webhook architecture pushes the event to your endpoint within seconds of occurrence. The practical gap between a call completing and your system knowing about it goes from 5–30 seconds (polling) to 1–3 seconds (webhook). That difference is the gap between catching a caller ID reputation problem on the same campaign run versus catching it in the next morning's report.

The Call Lifecycle Events Worth Automating

Not every SIP event needs a webhook. The events that drive meaningful automation are:

Call initiated. A dial was sent. Useful for tracking total attempt volume in real time and for triggering pre-call CRM enrichment (if you haven't pulled the contact record yet).

Call answered. The destination picked up. This is the moment to update your CRM's "last contacted" timestamp, start your conversation quality monitoring, and begin any real-time transcription service. Time-sensitive: process this in under 500ms or the agent is already two sentences in.

Call completed. The call ended. Full CDR data including duration, disposition, SIP response codes, and media event flags. This is the richest event and drives the most automation: CDR write to analytics DB, CRM disposition update, DID performance counter update, abandon rate recalculation, agent schedule-adherence logging.

Call failed. INVITE sent but the call never connected — SIP 486, 480, 503, or similar. Useful for tracking carrier-side failure rates per route and triggering automatic failover if failure rate exceeds a threshold.

Voicemail detected. If your stack includes answering machine detection, a detection event allows your system to drop a pre-recorded voicemail and release the agent instantly — rather than having the agent sit through the voicemail greeting and manually leave a message.

Building a Webhook Receiver That Does Not Fall Over

A webhook receiver is a small HTTP server. Its only job is to accept the POST, validate the payload signature, write the event to a queue, and return 200 OK in under 200ms. Nothing else.

The processing logic goes in a worker that consumes from the queue. This decouples receipt from processing. If your CRM is slow, your analytics DB write takes 800ms, or your alerting system spikes — none of that affects your ability to acknowledge incoming webhooks. A slow receiver that times out causes the sender to retry, and retry storms compound the problem.

The UnlimCall webhook system signs every payload with an HMAC-SHA256 signature using your endpoint secret. Validate the signature before doing anything with the payload — drop unsigned or incorrectly signed requests immediately with a 401, not a 200.

Practical Automation Recipes

Recipe 1: Real-time DID burn detection. On every call.completed event, increment a per-DID answer counter in Redis. Calculate a rolling 100-call answer rate per DID. When a DID's rate drops below your campaign baseline by more than 15 percentage points, fire an alert to Slack and suppress that DID from the outgoing pool. Total latency from event to suppression: under 5 seconds.

Recipe 2: CRM disposition sync. On call.completed with outcome "Connected-RPC," post a disposition update to your CRM API with the call timestamp, duration, and agent ID. On "No Answer," increment a callback counter. At callback count 3, move the record to a "callback exhausted" segment and remove it from active dialing. Keeps your list clean without a nightly batch job.

Recipe 3: Abandon rate alarm. Maintain a sliding window of the last 500 calls per campaign in Redis. On each call.completed event, push the outcome (connected vs. abandoned) and pop the oldest. Calculate the rolling abandon rate. When it crosses 2.5 %, push a notification to the supervisor. When it crosses 3.0 %, call your dialer's API to reduce the pacing ratio automatically. No human in the loop required for the first intervention.

Recipe 4: International routing validation. On call.initiated for a destination outside US/CA, validate that the caller ID being used is a number provisioned for that country. Across 33 markets on a flat-rate outbound network, you need caller IDs appropriate for the destination. If the wrong country DID is about to go out, intercept before INVITE and substitute the correct number. The caller ID on demand system handles provisioning; the webhook validates usage.

Idempotency and Replay Handling

Webhook delivery is at-least-once. Network hiccups, endpoint restarts, and retry logic mean the same event can arrive twice. Every automation that mutates state must be idempotent: processing the same event twice should produce the same result as processing it once.

Use the event's unique ID as an idempotency key. Check Redis or your DB for a record of that ID before processing. If found, return 200 without reprocessing. If not found, process and write the key with a 48-hour TTL.