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

# Retrieve a call transcript for a workflow

> Read a call through v3, wait for its transcript, and send only the result your workflow has verified.

Use the v3 call detail endpoint to retrieve a recorded call's transcript. A call ID, conversation ID, and contact ID are different identifiers; use the call's local ID or provider call ID for this request.

## Retrieve the call

Use an API key with `calls:read` authorized for the intended account. For a workspace key, specify that account with `X-Subaccount-Id`.

```bash theme={null}
curl "https://api.assistable.ai/v3/calls/$CALL_ID" \
  -H "Authorization: Bearer $ASSISTABLE_API_KEY" \
  -H "X-Subaccount-Id: $SUBACCOUNT_ID"
```

The response envelope contains `data` and `error`. Read `data.transcript` for plain transcript text, and use the complete field reference below for other call data.

If you only have a conversation ID, use `GET /v3/conversations/{id}/calls` with `conversations:read` to find up to 100 calls for its contact in that account. Match the intended call by its ID and time; the list is not restricted to one conversation session. Then use `calls:read` for the selected call detail. A conversation detail response alone does not contain the call transcript. See the [v3 API overview](/v3/introduction) and [authentication](/v3/authentication).

## Call detail fields

The detail response exposes the following fields under `data`. These camelCase fields belong to the v3 call API; the [post-call webhook](/v3/guides/call-results/webhooks) uses a different field shape. Optional data can be null or absent from the stored record; do not substitute empty analysis with an inferred result.

| Fields | Meaning |
| - | - |
| `id`, `callId` | Local call ID and provider call ID. Either can identify the call in the detail request. |
| `callStatus` | Recorded lifecycle status; values below. |
| `callType`, `direction` | Recorded call type and direction. |
| `toNumber`, `fromNumber` | Destination and source numbers. |
| `durationMs`, `totalDurationSeconds` | Recorded durations in milliseconds and seconds respectively. |
| `costInDollars` | Stored dollar cost as a number, or null. |
| `disconnectionReason`, `disposition` | Recorded ending reason and disposition. |
| `userSentiment`, `callSummary` | Stored sentiment and summary. |
| `recordingUrl`, `recordingUrls` | Primary recording URL and additional recording data. |
| `assistantId`, `contactId` | Associated assistant and contact IDs. |
| `startTimestamp`, `createdAt` | Recorded call start and record creation times. |
| `contact` | Related contact with `id`, `name`, `email`, and `phone`, when available. |
| `assistant` | Related assistant with `id` and `name`, when available. |
| `transcript` | Transcript text to map to a plain-text destination. |
| `transcriptObject` | Structured transcript data. |
| `conversationId` | Linked conversation ID, when available. |
| `callControlId`, `callSessionId` | Provider call-control and session identifiers. |
| `callAnalysis`, `latencyAverages` | Stored analysis and latency data. |
| `calledTools` | Recorded tool-call data. |
| `callCost` | Stored detailed cost data. |
| `variables` | Variables recorded for the call. |
| `callLegs` | Recorded call-leg data. |

Structured fields are returned as stored. Inspect their actual contents before mapping nested values; the endpoint does not replace missing data with a fixed example object.

| `callStatus` | Meaning |
| - | - |
| `QUEUED` | Waiting for call initiation. |
| `INITIATED` | Call initiation recorded. |
| `RINGING` | Ringing recorded. |
| `IN_PROGRESS` | Call is ongoing. |
| `COMPLETED` | Call completed; this alone does not prove a human answer or successful task. |
| `BUSY` | Busy outcome. |
| `FAILED` | Call failed. |
| `NO_ANSWER` | No answer recorded. |
| `CANCELED` | Call canceled. |

## Add a safe delivery step

1. Capture the call ID when your call workflow creates or receives the call result.
2. Read the call after it ends. Require `error` to be null and inspect `data.transcript` before mapping it into another action.
3. If the transcript is still empty, retry reads with a bounded delay and a stop condition. Do not send an empty transcript or label it complete.
4. Map the transcript string to your destination's text field. Use structured transcript data only if the receiving integration handles that structure.
5. Record the call ID after successful delivery so a repeated workflow event does not send it twice.
6. Verify the receiving record, email, or webhook request with a controlled test.

## Troubleshooting

* **403:** the key lacks access to the account or required scope.
* **404:** verify the account and call ID. A call may not have been recorded yet; do not substitute a contact ID.
* **Empty transcript:** the request succeeded, but the transcript is not available. Preserve this state and inspect the call before continuing.
* **Duplicate messages:** fix deduplication in the receiving workflow; successful GET requests do not track deliveries.

The API read does not send an email or execute a GHL workflow by itself. Configure and test that separate destination action.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.