Mute

Overview

The mute action mutes audio in a selected direction. Use it for coaching, privacy moments, or temporary one-way audio control. Place it in the actions array returned by your answer_url. MiniVoice executes actions in order, so put mute before the action that depends on its result and after any prompt or setup the caller should experience first.

Business Use Case

Use mute in bridge or conference-style workflows when one direction of audio should be silenced. A conference moderator might mute caller audio while placing them into a listening-only segment.

JSON Example

{
  "actions": [
    {
      "mute": {
        "direction": "read"
      }
    }
  ]
}

Parameters

Field	Type	Required	Description
type	string	Yes	Must be mute when using typed action format.
direction	string	Yes	read, write, or both.

Execution Flow

1. MiniVoice validates the direction.
2. It mutes the requested audio direction on the active call.
3. The call remains connected.
4. Use unmute to restore audio.

Webhook Behaviour

No action-specific webhook is sent for mute.

Success Example

A successful answer_url response includes the action in a valid actions array:

{
  "actions": [
    {
      "mute": {
        "direction": "read"
      }
    }
  ]
}

Your application should store the MiniVoice call ID from webhooks or API responses so you can correlate the action with the call.

Failure Behaviour

Invalid direction values are rejected. Mute can fail if the call has already ended.

Expected Result

MiniVoice applies the requested audio direction mute. Later actions can unmute the same direction when the caller should speak again.

Testing

Mute write audio during a test call and confirm the far end no longer hears the caller. Then run unmute and confirm audio returns. 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": [
    {
      "mute": {
        "direction": "read"
      }
    }
  ]
}

Real Response

A valid answer_url response is the JSON action payload itself. MiniVoice accepts the response when it contains an actions array:

{
  "actions": [
    {
      "mute": {
        "direction": "read"
      }
    }
  ]
}

Real Webhook Example

{
  "event": "call.completed",
  "created_at": "2026-05-29T12:10:00Z",
  "call": {
    "id": "call_123",
    "customer_id": "cust_123",
    "application_id": "app_123",
    "status": "completed",
    "direction": "inbound",
    "from": "+15551230001",
    "to": "+15551230002"
  },
  "variables": {},
  "data": {}
}

Common Use Case

Use mute in bridge or conference-style workflows when one direction of audio should be silenced. A conference moderator might mute caller audio while placing them into a listening-only segment.

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.