Webhooks.

Status: planned, not implemented. Today we don't push events to your URL. We've documented the design here so you can tell us which events you'd need first, and offer a polling alternative that works right now.

If you have a concrete integration that needs push-style events before we ship this, email hello@callfunnel.ai with the use case and we'll prioritise accordingly. Until then:

Every event we'd push is already derivable from a read endpoint. Poll on a cadence that matches your latency tolerance (typically 30s–5min):

• call.completed / call.failed / workflow.run.started / workflow.run.ended → GET /api/workflows/{id}/runs — diff against your last-seen run_id + status
• approval.requested → GET /api/approvals?status=pending — new ids since your last fetch
• approval.resolved → GET /api/approvals?status=approved&decided_after=…
• message.sent / message.delivered / message.replied → GET /api/timeline?phone=…&before=… — narrative includes all turns across channels
• wallet.low / wallet.exhausted → GET /billing/balance — compare against your threshold

Polling uses the same API key you already mint at /api-keys. When outbound webhooks land, the same data will arrive pushed instead of pulled.

The event types we expect to publish:

• call.completed — outbound or inbound call finished. Disposition, duration, cost, transcript URL.
• call.failed — call failed (busy, no-answer, provider error).
• message.sent / .delivered / .replied — WA / TG / email.
• approval.requested / .resolved — concession ladder.
• workflow.run.started / .ended — campaign lifecycle.
• wallet.low / .exhausted — balance signals.
• tenant.suspended — admin action or compliance trigger.

Security contract once shipped: HMAC-SHA256 signature in X-CF-Signature: t=…,v1=…, dedup key in X-CF-Event-Id, retries 1m → 5m → 30m → 2h → 12h → 24h on 5xx/timeout, permanent fail on 4xx (except 408/429), 5-minute replay window. Early integrators get a say in the payload shape — email us if you want to influence it.

These are configured automatically when you provision numbers, or set up payments. Listed here for reference — you don't usually need to touch them.

• Inbound call → /voice/twilio/incoming?tenant_id={id}
• Status callback → /api/twilio/status?tenant_id={id}

Signature verification: X-Twilio-Signature validated against your tenant's stored Twilio auth token.

Configured at the ExoPhone level via the orchestrator. Inbound call → /voice/exotel/incoming?tenant_id={id}.

HMAC-SHA256 signature verified with replay-window protection. Idempotent on the processor's event id. See API reference for the endpoint.