Overview

MiniVoice lets developers build programmable voice workflows with applications, DIDs, SIP trunks, call actions, webhooks, recordings, billing controls, and AI results.

A typical integration flow is:

1. Create or select an application and API key.
2. Configure an answer_url that returns call actions.
3. Assign a DID to the application.
4. Receive inbound calls or create outbound calls.
5. Handle webhook events.
6. Review recordings, transcripts, summaries, scores, and topics when enabled.

All customer API examples use the /v1 API and bearer authentication.

Customer vs Application vs API key vs DID vs Trunk

MiniVoice separates account ownership from call routing. A customer owns the billing relationship and the resources in the account. An application owns the developer configuration for a call flow: answer_url, webhook_url, webhook_secret, and API keys. The API key authenticates customer API requests. A DID controls inbound PSTN routing. A trunk controls BYOC/SIP routing for inbound or outbound traffic.

For inbound calls, the DID or trunk route determines which application handles the call. That application's answer_url returns call actions, and its webhook_url receives events. For outbound calls, the API request includes application_id; that application controls the answer_url, webhook_url, webhook_secret, and call behavior for the new call.

Object	Purpose	Example ID
Customer	Owns account, billing, applications, DIDs, trunks, and usage.	cust_123
Application	Owns answer_url, webhook_url, webhook_secret, and API keys.	app_123
API key	Authenticates customer API requests.	mv_live_xxx
DID	Routes inbound phone-number calls to an application or route.	did_123
Trunk	Routes BYOC/SIP traffic for inbound or outbound calls.	trunk_123

Integration checklist

Set up the smallest possible working integration before adding business logic. Use one API key, one application, one answer_url, one webhook_url, and one DID or outbound test number. Save the successful request and response bodies because they become the baseline for later troubleshooting.

When you add features, change one part of the flow at a time. If a call fails, check authentication first, then the route, then the answer_url response, then webhook delivery. That order usually separates setup errors from call-control errors quickly.

Copy/Paste Examples

Real Request

curl -sS -X POST https://api.minivoice.eu/v1/calls \
  -H 'Authorization: Bearer $MINIVOICE_API_KEY' \
  -H 'Content-Type: application/json' \
  --data @- <<'JSON'
{
  "application_id": "app_123",
  "from": "+15551230001",
  "to": "+15551230002",
  "record": true,
  "metadata": {
    "campaign": "appointment-confirmation"
  }
}
JSON

Real Response

{
  "id": "call_123",
  "status": "dialing",
  "direction": "outbound",
  "application_id": "app_123",
  "created_at": "2026-05-29T12:00:00Z"
}

Real Webhook Example

{
  "id": "evt_123",
  "type": "call.completed",
  "created_at": "2026-05-29T12:10:00.000Z",
  "sequence": 2,
  "data": {
    "call": {
      "id": "call_123",
      "application_id": "app_123",
      "status": "completed",
      "direction": "inbound",
      "from": "+15551230001",
      "to": "+15551230002"
    },
    "reason": "completed"
  }
}

Common Use Case

Prepare the base integration for a receptionist IVR, appointment confirmation line, or payment reminder workflow before sending real callers through it.

Common Failure Case

{
  "error": {
    "code": "unauthorized",
    "message": "unauthorized"
  }
}

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