Broadcast API Release Notes

This page documents the release history of the EnableX Voice Broadcast API. Each version entry covers new capabilities, changes to campaign flows, webhook updates, and breaking changes that affect how you integrate with the API.

Broadcast API v2.1.0 — June 15, 2026

New: Dialout Call Lifetime Pipeline

Broadcast calls can now be configured with automatic retry on connection failure. Add a retry object to the POST /voice/v1/broadcast request body and the platform will automatically redial any recipient whose call fails to connect — no application-side retry loop required. The same retry schedule applies to every number in the batch.

{
    "retry": {
        "interval": 10,
        "max_attempts": 3
    }
}

With this configuration, the platform redials each unanswered recipient after 10 seconds, up to 3 total attempts per number. Application-level retry (detecting a failed disconnected event and issuing a new broadcast or per-call request) continues to work exactly as before — the retry object is additive.

New webhook field: attempt
For broadcasts using the retry object, the initiated, connected, and disconnected webhook events include an attempt field (1-based integer) on all attempts after the first. The first attempt's payload is unchanged. For subsequent retries:

{
  "broadcast_id": "74a2c2c2-4d55-4b0d-a9f6-8ec09f3bcc35",
  "voice_id": "bc273d94-cb59-4f66-8eba-e1f96a7e482e",
  "from": "1",
  "to": "918088394833",
  "state": "initiated",
  "attempt": 2,
  "timestamp": "2026-06-15T10:52:10.000Z"
}

See the Broadcast API — Dialout Call Lifetime Pipeline section for the full request example and webhook behaviour details.

Breaking Change: custom_data is now per recipient

The top-level custom_data field has been removed from the Broadcast API initiation request. Pass custom_data inside each recipient object instead:

Before (v2.0 — no longer accepted):

{
  "recipients": [
    {
      "to": "918088394833",
      "play": { "type": "url", "url": "https://example.com/audio.mp3", "prompt_ref": "p1" }
    }
  ],
  "custom_data": { "booking_id": 12345, "farmer_id": 6789 }
}

After (v2.1.0 — required format):

{
  "recipients": [
    {
      "to": "918088394833",
      "play": { "type": "url", "url": "https://example.com/audio.mp3", "prompt_ref": "p1" },
      "custom_data": { "booking_id": 12345, "farmer_id": 6789 }
    }
  ]
}

This change allows different context to be attached to each call leg within the same batch. For example, you can now include a per-recipient booking ID or customer reference directly alongside each number, rather than sharing a single object across the entire campaign.

You cannot include both a top-level and a per-recipient custom_data in the same request — the API will reject the call.

Migration deadline: December 2026

For backward compatibility, the platform will continue to echo the old batch-level custom_data in webhook notifications until December 2026. Applications that have not migrated will continue to receive it in ringing, connected, disconnected, and broadcastcall_complete events during this period. Update your integration to use per-recipient custom_data before that date.

See the Broadcast API — Initiate Broadcast Call section for updated request examples across all audio types.