Skip to main content

The preview-dial loop: claim → review → launch

Outbound-campaign operators run the dialer workspace. Progressive, predictive, and agentless campaigns fire through the pacing scheduler automatically; preview mode is the one where a human reviews each contact card before the call launches. That human loop compresses into two endpoints, and both are worked below end-to-end.

1. Claim the next contact

The agent’s frontend claims the next contact with GET /api/v1/dialer/next-call:
The claim is atomic — two agents polling concurrently never receive the same number — so the response is the work ticket the agent reviews on their screen. preview_decision_seconds is the per-campaign review countdown; decision_expires_at is the server-side deadline for that countdown. 204 No Content means the campaign is progressive / predictive / agentless (calls fire automatically); 404 means the campaign is not active. A null contact means the list is drained.

2. Launch the dial

Once the agent clicks “Call”, the dial launches with POST /api/v1/dialer/dial:
The contact must still be in the dialing (claimed) state, or the request rejects with 409 CLAIM_NOT_HELD. The requesting operator records as the call’s agent for the TCPA audit trail, and the call itself exits through the Devotel softswitch — the preview loop never dials a number outside the commit path. Pass an Idempotency-Key so a retried client click never double-dials the same contact.

Hopper controls: pause and resume a running campaign

Pause and resume are the same PATCH /api/v1/dialer/campaigns/{id} operation with a status body field — valid for progressive and preview campaigns alike. Pausing stops the pacing scheduler and the preview claim queue; in-flight legs terminate normally.
Resuming stays an explicit operator action — when the org-wide compliance emergency stop is engaged, a missing voice application, or a recording-consent gap blocks activation, the patch rejects with a descriptive 4xx instead of silently restarting the hopper.

Disposition the contact with an optional callback

After the call wraps, the agent submits the outcome with POST /api/v1/dialer/campaigns/{id}/dispositions. When the disposition is callback_later, callback_scheduled_at is required: ISO-8601 with offset, in the future, and within 90 days.
The contact moves to its next lifecycle status (callback_scheduled, dnc, wrong_number, connected, …). A dnc or wrong_number disposition also writes a suppression entry, so future dial attempts to that number are blocked across every campaign in your tenant. Dispositions are recorded against the claim-time agent and are audit-loggable for TCPA defense.

Where errors go

The dialer rejects with a stable error.code in the envelope — the full registry of codes across the API lives in the on-page errors matrix, Error codes. The failures you will actually hit in this loop: Parse error.code, not the HTTP status alone — for example 409 carries both the claim-conflict and the in-flight-delete cases.

SDK surface bridge — List outbound-dialer campaigns, queue the next hop of the campaign FIFO, or trigger one alias lane — all with the sandbox key.

These three tabs mirror SDK status and coverage. Python fronts client.request, Go fronts client.Request, and TS fronts fetch-TS — each with the sandbox key.

List dialer campaigns

Queue the next campaign hop

Fire one alias lane

Alias-lane request inbox