Skip to main content

Configure Cisco CUBE Call Event Webhooks

Premium

CUBE webhooks send real-time call-state changes from one or more Cisco CUBE gateways to an external JSON endpoint. Use them for CRM screen pops, live call dashboards, incident automation, and workflows that must begin before a completed CDR is available.

Use a CDR webhook instead when the destination needs the completed CUCM call record or conditional post-call processing.

CUBE Webhooks page with three fictional integrations, delivery totals, associated gateways, and selected call states

Before you begin​

  • Use Call Telemetry 0.8.7 or later with an Essentials or higher license.
  • Configure CUBE XCC integration, then confirm that the gateway is registered and call events are arriving.
  • Prepare an HTTP or HTTPS endpoint that accepts POST requests with a JSON body. HTTPS is recommended.
  • Allow the Call Telemetry appliance to reach the destination through DNS, routing, firewalls, and any outbound proxy.

CUBE webhooks do not require CURRI and can coexist with existing Call Telemetry policy integrations.

Add a CUBE webhook​

  1. In the sidebar, open Cubes > CUBE XCC Webhooks.
  2. Select Create Webhook.
  3. Enter a descriptive Name, optional Description, and destination URL.
  4. Leave Enabled on if the webhook should begin sending events after you save it.
  5. Select one or more Connection States.
  6. Under Associated Cubes, enable each gateway whose events should be sent.
  7. Add optional authentication or routing Headers.
  8. Review the Payload Preview, then select Save.
Edit CUBE webhook screen with a fictional HTTPS endpoint, five available connection states, two associated CUBEs, headers, and payload preview

Choose connection states​

Select only the states the receiving workflow needs:

StateWhen it occursTypical use
AUTHORIZE_CALLThe CUBE requests authorization for the callAuthorization visibility and early workflow correlation
CALL_DELIVERYThe call proceeds to deliveryRouting-progress tracking
ALERTINGThe destination is ringingCRM screen pops and ringing dashboards
CONNECTEDThe call is answeredActive-call status and answer-time workflows
DISCONNECTEDThe call endsClose tickets, clear presence, or finalize a call timeline

Selecting more states creates more requests for each call. For a simple screen pop, ALERTING may be enough; a complete live timeline commonly uses ALERTING, CONNECTED, and DISCONNECTED.

Understand the payload​

Each selected call-state change sends a compact JSON body:

{
  "calling_number": "+12515550100",
  "called_number": "+12515550101",
  "call_state": "CONNECTED",
  "timestamp": "2026-07-15T15:22:04.000Z"
}

Phone-number formatting depends on the values presented by the gateway. Normalize numbers in the receiving system if it requires a consistent E.164 format.

Monitor delivery logs​

In the CUBE Webhooks table, select View Logs for a webhook. Choose a date range and select Refresh to inspect recent attempts.

The log shows:

  • Processing time and connection state.
  • Destination HTTP status.
  • The JSON request and response bodies.
  • A delivery error when Call Telemetry could not complete the request.
CUBE webhook logs with ALERTING, CONNECTED, and DISCONNECTED events, successful responses, and one fictional 503 failure

A 2xx status means the destination accepted the request. For other results:

ResultWhat to check
No log rowsConfirm the webhook is enabled, at least one gateway and state are selected, and matching calls traverse that CUBE.
401 or 403Correct the authentication header or destination permissions.
404Correct the webhook URL path.
5xxInspect the response body and the destination service's logs.
Connection or timeout errorTest DNS, routing, firewall rules, TLS trust, and endpoint response time from the appliance network.
Last updated on by Call Telemetry