Start Recording
Overview
The start_recording action starts recording the active call. Use it when recording should begin after consent, after an IVR step, or only for a specific part of a call. Place it in the actions array returned by your answer_url. MiniVoice executes actions in order, so put start_recording before the action that depends on its result and after any prompt or setup the caller should experience first.
Business Use Case
Use start_recording when a call needs a later recording for QA, transcription, or appointment confirmation review. Start recording only at the point where recording is needed.
JSON Example
{
"actions": [
{
"start_recording": {}
}
]
}
Parameters
| Field | Type | Required | Description |
|---|---|---|---|
| type | string | Yes | Must be start_recording when using typed action format. |
Execution Flow
- MiniVoice reaches start_recording in your action list.
- Recording begins for the active call.
- MiniVoice continues to the next action.
- When recording starts, your webhook endpoint can receive recording.started.
Webhook Behaviour
MiniVoice sends recording.started when recording begins. If recording cannot start, MiniVoice sends recording.failed.
Success Example
A successful answer_url response includes the action in a valid actions array:
{
"actions": [
{
"start_recording": {}
}
]
}
Your application should store the MiniVoice call ID from webhooks or API responses so you can correlate the action with the call.
Failure Behaviour
Recording can fail if the call is not active or recording cannot be started. Your app should handle recording.failed and avoid assuming a recording exists until it receives completion.
Expected Result
MiniVoice starts recording the active call. Recording metadata becomes available through recording-related APIs and final call data after processing.
Testing
Return start_recording, say, and stop_recording. Verify recording.started and recording.completed webhooks. During testing, log every webhook payload and compare the call ID, action timing, and final call status with the behavior you expected.
Integration guidance
Place this action in a short answer_url response first, then combine it with other actions after you have confirmed the single-action behaviour. Always log the answer_url response your application returned for the call. If the caller experience differs from what you expected, compare the logged response with the webhook timeline for that call ID.
When this action is part of a larger IVR, keep each step explicit. For example, play a prompt before collecting input, redirect after collecting input, and transfer only after your application has selected the final destination. This makes the flow easier to test and easier to change later.
For production integrations, build a fallback path. A caller may hang up, enter no digits, reach a busy destination, or disconnect before the flow completes. Your webhook handler should update the call record with the last known step so support teams can understand what happened.
Copy/Paste Examples
Real Request
Return this from your answer_url:
{
"actions": [
{
"start_recording": {}
}
]
}
Real Response
A valid answer_url response is the JSON action payload itself. MiniVoice accepts the response when it contains an actions array:
{
"actions": [
{
"start_recording": {}
}
]
}
Real Webhook Example
{
"event": "recording.started",
"created_at": "2026-05-29T12:00:12Z",
"call": {
"id": "call_123",
"status": "in_progress",
"direction": "inbound"
},
"variables": {},
"data": {
"recording_id": "rec_call_123",
"status": "started",
"call_id": "call_123"
}
}
Common Use Case
Use start_recording when a call needs a later recording for QA, transcription, or appointment confirmation review. Start recording only at the point where recording is needed.
Common Failure Case
{
"error": {
"code": "answer_url_error",
"message": "invalid action payload"
}
}
Invalid fields or malformed JSON cause MiniVoice to reject the answer_url payload. Log the exact response your server returned while testing.