> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brightalk.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Status lifecycles

> Distinguish the API-visible statuses for calls, batches, and Automation runs.

Poll an API resource only while its `status` is nonterminal. A terminal resource remains retrievable and does not transition back to active work.

## Call `status`

```mermaid theme={null}
flowchart LR
  queued --> dialing
  queued --> in_progress
  queued --> completed
  dialing --> in_progress
  dialing --> completed
  in_progress --> completed
  queued --> failed
  dialing --> failed
  in_progress --> failed
  queued --> cancelled
  dialing --> cancelled
  in_progress --> cancelled
```

| Status        | Terminal | Meaning                                                    |
| ------------- | -------- | ---------------------------------------------------------- |
| `queued`      | No       | Accepted and waiting for dispatch or capacity              |
| `dialing`     | No       | Dialing has begun                                          |
| `in_progress` | No       | The call is connected and active                           |
| `completed`   | Yes      | Execution finished, including ordinary callee dispositions |
| `failed`      | Yes      | The service could not execute safely                       |
| `cancelled`   | Yes      | Cancellation won before completion                         |

The diagram shows allowed API-visible transitions, not one required path. A late callback, worker update, or reconciliation pass can skip intermediate observable states and advance `queued` or `dialing` directly to `in_progress` or `completed`. Clients must accept any depicted transition. Cancellation is supported from `queued`, `dialing`, or `in_progress`.

## Batch `status`

```mermaid theme={null}
flowchart LR
  draft --> scheduled
  draft --> queued
  scheduled --> queued
  scheduled --> in_progress
  scheduled --> completed
  scheduled --> failed
  scheduled --> paused
  queued --> in_progress
  queued --> completed
  queued --> paused
  in_progress --> paused
  paused --> scheduled
  paused --> queued
  in_progress --> completed
  queued --> failed
  in_progress --> failed
  draft --> cancelled
  scheduled --> cancelled
  queued --> cancelled
  in_progress --> cancelled
  paused --> cancelled
```

| Status        | Terminal | Meaning                                               |
| ------------- | -------- | ----------------------------------------------------- |
| `draft`       | No       | Configured but not started                            |
| `scheduled`   | No       | Started and waiting for its eligible schedule         |
| `queued`      | No       | Recipients are eligible and queued for dispatch       |
| `in_progress` | No       | At least some recipient work is active or progressing |
| `paused`      | No       | Subsequent dispatch is paused                         |
| `completed`   | Yes      | All recipient work reached a terminal result          |
| `failed`      | Yes      | The batch could not continue safely                   |
| `cancelled`   | Yes      | Remaining work was cancelled                          |

The controls match the diagram: start moves `draft` to `scheduled` or `queued`; pause accepts `scheduled`, `queued`, or `in_progress`; resume moves `paused` back to `scheduled` or `queued` according to schedule eligibility; and cancel accepts every nonterminal batch state.

These transitions are not one required path. A late callback, worker update, or reconciliation pass can skip intermediate observable states and advance `scheduled` or `queued` directly to `in_progress`, `completed`, or `failed` along a depicted edge. Clients must accept every depicted transition and stop polling only at a terminal state.

## Automation run `status`

```mermaid theme={null}
flowchart LR
  queued --> running
  running --> waiting
  waiting --> running
  running --> completed
  waiting --> completed
  queued --> failed
  running --> failed
  waiting --> failed
  queued --> cancelled
  running --> cancelled
  waiting --> cancelled
```

| Status      | Terminal | Meaning                                               |
| ----------- | -------- | ----------------------------------------------------- |
| `queued`    | No       | Accepted and waiting to begin                         |
| `running`   | No       | An Automation step is executing or ready to execute   |
| `waiting`   | No       | The Automation is waiting according to its definition |
| `completed` | Yes      | The Automation run finished normally                  |
| `failed`    | Yes      | The Automation run could not continue safely          |
| `cancelled` | Yes      | The run was cancelled before normal completion        |

## `answer_status` is independent

`answer_status` belongs to a call and is not a lifecycle state. It may be `answered`, `no_answer`, `busy`, `voicemail`, or `unknown`.

| Call result                                   | Example combination                                   |
| --------------------------------------------- | ----------------------------------------------------- |
| Answered and finished normally                | `status: completed`, `answer_status: answered`        |
| No answer, busy, or voicemail                 | `status: completed` with the matching `answer_status` |
| Execution failure without connection evidence | `status: failed`, `answer_status: unknown`            |
| Cancelled after a connection                  | `status: cancelled`, `answer_status: answered`        |

Always decide whether to stop polling from `status`, then interpret destination behavior from `answer_status`.