Skip to main content

Conference Room

Business Scenario​

Place multiple callers into the same named conference room. This pattern is useful when you want a small, testable call flow that can be expanded later. Start with the exact JSON shown here, verify it works with a test DID or outbound call, then add your own routing and customer lookup logic.

Call Flow Diagram​

Each participant calls or is routed into the same conference action with the same room name
↓
MiniVoice connects them in that room.

Webhook Flow​

call.answered and call.completed for each participant. Store each webhook by call ID so your application can reconstruct the call journey after the call ends.

JSON Actions​

{
  "actions": [
    {
      "type": "conference",
      "room": "daily_support_room",
      "mute": false,
      "end_on_exit": false
    }
  ]
}

Expected Result​

Two or more callers join the same room and can speak to each other. During manual testing, confirm the caller experience first, then confirm your application received the expected webhooks. For production use, add logging around every answer_url response and webhook handler so you can investigate individual call IDs quickly.

How To Adapt​

Replace example URLs with your HTTPS endpoints, replace phone numbers with verified destinations, and keep metadata values small and consistent. Test one change at a time: first answer_url, then webhook receiver, then call routing, then AI or recording features if the flow uses them.

Implementation Notes​

Before using this pattern with real callers, run it in a test application and capture the full webhook timeline. Confirm that the first webhook creates or updates your local call record, that action-specific webhooks update the current step, and that the terminal webhook closes the workflow.

Keep the example JSON small while you test. After the basic version works, add customer lookup, business hours checks, agent availability, or CRM updates one piece at a time. When a change breaks the caller experience, roll back to the last working JSON response and compare the webhook payloads.

A production version should include clear fallback behaviour. Decide what happens when a caller does not press a digit, a destination is busy, a webhook is retried, or recording and AI results arrive later than expected.

Copy/Paste Examples​

Real Request​

curl -sS https://api.minivoice.eu/v1/calls/call_123 \
  -H 'Authorization: Bearer $MINIVOICE_API_KEY'

Real Response​

{
  "id": "call_123",
  "status": "completed",
  "direction": "outbound",
  "from": "+15551230001",
  "to": "+15551230002"
}

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 one known call ID to verify each integration test.

Common Failure Case​

{
  "error": {
    "code": "conference_unavailable",
    "message": "conference room could not be joined"
  }
}

Use the error code for branching and log the full response body while testing.