> ## 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.

# Calls

> Understand asynchronous AI call resources and their results.

A call is an asynchronous, immediate AI voice execution for one contact. `POST /calls` returns `202 Accepted` after durable queueing; it does not wait for dialing or completion.

## Immediate asynchronous execution

A request selects one eligible `agent_id` and one existing or inline contact reference. It cannot choose a scheduled time. Use batch dialing for a scheduled start or calling window, and a dashboard-managed Automation for more complex timing.

Capacity may keep an accepted call in `queued`. Retrieve the call by its API resource `id` until `status` is terminal.

## Lifecycle and answer classification

`status` describes whether execution is queued, active, finished, failed, or cancelled. `answer_status` independently classifies the destination as `answered`, `no_answer`, `busy`, `voicemail`, or `unknown`.

A normal `no_answer`, `busy`, or `voicemail` disposition can therefore have `status: completed`. `failed` is reserved for inability to execute the service safely. See [Status lifecycles](/en/concepts/status-lifecycle) for the full model.

## API scalar result

The call resource contains only documented scalar fields:

| Category             | Fields                                                                                                       |
| -------------------- | ------------------------------------------------------------------------------------------------------------ |
| Identity and lineage | `id`, `contact_id`, `agent_id`, optional `batch_id`, optional `automation_run_id`                            |
| State                | `status`, `answer_status`                                                                                    |
| Basic result         | optional `outcome`, `outcome_reason`, `summary`, `duration_seconds`                                          |
| Timing               | `queued_at`, `created_at`, `updated_at`, and applicable dialing, connection, end, or cancellation timestamps |

Treat IDs as opaque and optional result fields as absent until applicable.

## Cancellation

`POST /calls/{call_id}/cancel` is best-effort and idempotent. It prevents dispatch when cancellation wins early and requests termination for active work. A completion race may still leave the final `status` as `completed`; repeated cancellation returns the current call instead of creating another action.