---
title: "Handle Recording Status Callback"
method: POST
path: "/calls/recording-status-callback/{call_id}"
tags: ["Calls"]
---

# Handle Recording Status Callback

`POST /calls/recording-status-callback/{call_id}`

## Request

- Base URL: `https://api.openintake.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://api.openintake.ai/calls/recording-status-callback/{call_id}`
- Auth: none declared

Twilio webhook: fires when the dual-channel recording we started on the
carrier leg is finalized (BYOB attended transfer, or a Vapi-native warm
transfer on ``vapi_transfers_enabled``).

By the time Twilio fires ``RecordingStatus=completed``, the carrier call
has hung up, every Vapi end-of-call-report has been delivered, and the
full audio file is available. That makes this the right moment to trigger
the transcription pipeline for these calls — earlier triggers (the Vapi
end-of-call-report) fire while the carrier call is still in progress and
would capture only the pre-transfer half.

``absent``/``failed`` mean no usable Twilio file exists. Those clear
``call_sid`` so the pipeline falls back to Vapi's own recording, then
trigger — dropping them would leave the call with no transcript at all.

No authentication (Twilio webhook).

## Path parameters

- `call_id` string, uuid, required

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/openintake/apis/openintake-api.md) - [All operations](https://skmtc.dev/openintake/apis/openintake-api/llms.txt) - [OpenAPI document](https://skmtc.dev/openintake/apis/openintake-api/revisions/de90a8dcbc07?raw)