Skip to content

Resume a paused parallel-dialer session by auto-fetching next batch

POST
/voice/dialer/sessions/{session_id}/resume

Resume a PAUSED parallel-dialer session.

The voice service’s PATCH /sessions/{id}/status rejects ACTIVE - the real resume flow is to call start-session again with the existing session_id and a fresh batch of contacts. This route does the lookup + filtering + forwarding in one shot so an MCP caller only has to supply the session id (and optionally a batch size).

Steps performed server-side:

  1. Fetch the session via GET /api/parallel-calls/sessions (filtered to the caller’s org). Voice has no per-id GET, so we page with page_size=200 and find the row.
  2. Verify the session belongs to the caller’s org and is in the PAUSED state. ACTIVE / COMPLETED sessions return 422.
  3. Read list_id and the list_offset cursor from session_metadata. Sessions created without a list_id (ad-hoc / campaign-mode) cannot be resumed via this route and return 422.
  4. Page contacts out of the source list starting at the cursor, skipping rows already in session.contact_ids and rows that have no usable phone field.
  5. Forward up to max_contacts rows to voice’s /api/parallel-calls/start-session with the existing session_id. Voice de-duplicates active calls within the session and auto-promotes status to ACTIVE on success.

The list_offset we send back to voice is advanced by the total number of rows we read from the list (called + skipped + dialed) so a future resume picks up where we left off, not where the previous pause cursor sat.

Authorizations

Parameters

Path Parameters

session_id
required

Session UUID.

string
>= 1 characters

Session UUID.

Header Parameters

X-Target-Org-Id
Any of:
string

Request Body

Body for resuming a paused parallel-dialer session.

The resume endpoint mirrors what the dialer UI does when the SDR clicks “Start Dialing” on a paused session: it pages the source list using the cursor stored in session_metadata, filters out already-called contacts, and forwards the next batch to the voice service’s start-session endpoint.

Only max_contacts is exposed - org / user / from_phone / list_id / agent / session_metadata are all read off the persisted session so the caller doesn’t have to reconstruct them.

object
max_contacts

Number of contacts to dial in this batch. Voice caps parallel dialing at 4.

integer
default: 4 >= 1 <= 4

Responses

200

Successful Response

object
data
required

Echo of voice’s ParallelDialResponse plus a count of contacts dialed.

dialed_count is the number of calls actually placed in this resume batch. It can be lower than max_contacts when the list is near exhausted, every remaining row is missing a phone, or every candidate was already called earlier in the session.

twilio_token and conference_name are deliberately dropped - they are SDR-frontend specific and an MCP / API caller has no use for them. The dialer UI regenerates them on join.

object
created_at
Any of:
dialed_count
integer
from_phone
Any of:
string
message
Any of:
string
name
Any of:
string
org_id
Any of:
string
session_id
required
string
session_metadata
Any of:
object
key
additional properties
any
status
required
string
total_calls
integer
updated_at
Any of:
user_email
Any of:
string
user_id
Any of:
string
pagination
Any of:
object
has_next
required

Whether there are more pages

boolean
limit
required

Items per page

integer
next_cursor
Any of:
string
page
required

Current page number (1-indexed)

integer
total
required

Total number of items

integer

422

Validation Error

object
detail
Array<object>
object
loc
required
Array
msg
required
string
type
required
string