Interpreting calls that did not complete

When a call does not concretely complete, the outcome is on the scheduled request and the failure cause is on its call attempts. Three cases cover the situations where the call never produced a confirmed result: voicemail (read the voicemail_left field in generated_outcomes), no answer or busy (read positive_or_negative_contact and appointment_attendance_status), and failed dialing (read error_classification on the call attempt records).

Where to read these fields from the call job API

Poll GET /scheduler/call-jobs/{call_job_id} or bulk-read with POST /scheduler/call-jobs/query, and pass include_call_attempts=true when you need failure causes. The submission response does not carry any of these fields.

1. Call GET /scheduler/call-jobs/{call_job_id}?include_call_attempts=true (or POST /scheduler/call-jobs/query with include_call_attempts: true).

2. Read workflow_status and stop_reason on each entry in scheduled_requests to see whether the request is finished and why it stopped.

3. Read generated_outcomes for what the call actually reached, without inspecting raw attempts.

4. Read error_classification on each entry in call_attempts for why a failed attempt failed.

Field references for every endpoint: see the Call Jobs API. The snapshot-based tracking workflow is in Track specific calls after a batch API call.

Voicemail

voicemail_left is a boolean in generated_outcomes that records whether a voicemail message was actually left. The voicemail outcome is not a terminal result: the request is re-enqueued for another call.

No answer and busy

A call where no live human answers is recorded as negative contact, not as a confirmed attendance result, and the request is retried automatically before it becomes final.

Both outcomes re-enqueue the request for another call. The default retry allowance is 3 semantic call attempts per request. When the allowance is exhausted, the request's snapshot freezes with workflow_status COMPLETE and stop_reason SEMANTIC_RETRIES_EXHAUSTED.

Unable to confirm

appointment_attendance_status: "unable_to_confirm" means the call connected but a clinic representative could not or would not establish the appointment's status. It also covers appointments that did not happen for an administrative reason: authorization pending, an insurance or payer discrepancy, a billing dispute, a scheduling error, or the clinic waiting on an external resolution such as the adjuster.

Two distinctions matter when you read this value:

• It is not the value for no answer. A call that reached no one records negative contact with appointment_attendance_status unknown. unable_to_confirm appears only when an attempt actually connected and the status could not be established.

• It is not terminal. Neither unable_to_confirm nor unknown establishes what happened to the appointment, so the request is re-enqueued for another call.

Failed dial attempts: error_classification

error_classification is a string on each call attempt that classifies why the call failed. It is independent of the retry disposition: the classification describes the failure and does not by itself decide whether the request is retried. A null value means no classification has been saved; attempts recorded before this field existed are not backfilled, so older attempts also return null.

How to interpret the values:

• Classification is code-based only: it is derived from the provider's SIP status code or service-level code. A mapped SIP code takes precedence over a service-level mapping, and a failure that matches neither returns UNKNOWN.

• There is no dedicated value for a "number no longer in service" carrier announcement. When the provider reports SIP 404 for that situation, the attempt is classified DESTINATION_NOT_FOUND. Announcement text is not inspected, so the same situation can also land in another mapped value or UNKNOWN, depending on what the provider reports.

• Service-side values (SERVICE_UNAVAILABLE, SERVICE_CAPACITY_EXCEEDED, PROVIDER_TIMEOUT) describe our calling infrastructure or provider capacity, not the destination number.

Which attempt's outcome the API returns

generated_outcomes on a scheduled request is the most representative attempt outcome, not simply the newest one. Outcomes are ranked in this order: positive live-human contact first, then outcomes where a voicemail was left, then other negative-contact outcomes, then unknown outcomes. Ties are broken by preferring the later attempt.

This ranking has one practical consequence: an answered attempt that produced unable_to_confirm outranks an earlier voicemail or no-answer attempt. A history that contains only voicemail and no-answer attempts never becomes unable_to_confirm; its representative outcome stays negative contact with appointment_attendance_status unknown.