Skip to main content

External Infrastructure Integration Guide

Pranthora Voice Platform — Client Integration Reference

Overview

Pranthora supports connecting your own telephony or audio infrastructure directly to the platform. Once connected, Pranthora handles the full AI pipeline — speech recognition, LLM inference, and text-to-speech — and streams responses back to your infrastructure in real time. Two integration modes are supported:

Authentication

All external connections authenticate using an API Key generated from the Pranthora platform.
Generate your API key from Pranthora Dashboard → Settings → API Keys

How to pass the API Key

For both integration modes, set the API key in the WebSocket connection header:
Pranthora extracts and validates the key on every new WebSocket connection. Connections without a valid key will be rejected with close code 4001.

Integration Mode 1 — Pure WebSocket

In this mode, your infrastructure connects directly to the Pranthora WebSocket endpoint, streams audio, and receives AI-generated speech in return. No prior HTTP handshake is needed.

Connection

Or, if using a workflow instead of a single agent:
Required query parameters — one of: Required headers:

Connection Lifecycle

Sending Audio (Client → Pranthora)

  • Wait for the {"event_type": "start_media_streaming"} text frame before sending audio.
  • Send audio as raw binary frames (no envelope, no JSON wrapper).
  • Stream continuously in small chunks — do not buffer or batch large chunks.
Expected audio format:

Receiving from Pranthora (Pranthora → Client)

Pranthora sends two types of frames back to your connection:

TTS Audio — Binary Frame

Raw PCM audio bytes in the same format as the inbound audio (16kHz, mono, PCM). Play this directly to the end user.

Interruption Signal — Text Frame

When you receive this text frame, immediately halt playback of any TTS audio you are currently streaming to the user. The user has spoken and Pranthora is generating a new response. Discard any buffered TTS audio.

Session Timeout

Pranthora enforces a configurable session timeout on idle connections. When the timeout is reached, the WebSocket will be closed with code 1000 and reason "Session timeout reached". Your infrastructure should reconnect if the call is still active.

Integration Mode 2 — HTTP Handshake + WebSocket

In this mode, your infrastructure sends a single HTTP request to Pranthora with your API key. Pranthora authenticates the request and returns a WebSocket URL. Your infrastructure then connects to that URL and begins streaming audio. This is useful for systems where a request/response handshake is required before opening a persistent connection — for example, orchestration layers that need to know the target URL before instructing a media server to connect.

Step 1 — Request a WebSocket URL

Or using a workflow:
Response:
Pranthora validates the API key and, if authenticated, returns the WebSocket URL your infrastructure should connect to.

Step 2 — Connect via WebSocket

Connect to the websocket_url returned in Step 1 using the Telephony Protocol (JSON-framed messages). The full message protocol is described in the Telephony Protocol section below.

Telephony Protocol (Twilio-Compatible)

If your infrastructure is a telephony provider or SBC that supports the Twilio Media Streams protocol, you can connect to the dedicated telephony WebSocket endpoints. This protocol uses JSON-framed messages instead of raw binary frames, and operates at 8kHz with mulaw encoding — matching traditional telephony.

Connection

Per-agent:
Per-workflow:
These endpoints follow the Twilio Media Streams WebSocket protocol. Your infrastructure must send and receive Twilio-format JSON events.

Message Protocol

All messages are UTF-8 encoded JSON text frames.

Client → Pranthora

Start Event — sent once when the stream begins:
Media Event — sent continuously with audio chunks:
Stop Event — sent when the call ends:

Pranthora → Client

TTS Audio:
Interruption / Clear Buffer:
Upon receiving clear, stop playback immediately and flush any buffered TTS audio. TTS Completion Mark:
Signals that the current TTS utterance has finished sending. Useful for synchronizing playback end detection on your side.

Supported Audio Formats

Note: Resampling is handled internally. If you send 8kHz mulaw audio, Pranthora upsamples it to 16kHz for model processing. TTS output is likewise encoded and downsampled back to match your input format.

Interruption Handling

Pranthora’s voice pipeline includes real-time interruption detection. When the system detects that the user is speaking while the agent is responding:
  1. Any in-progress TTS generation is cancelled.
  2. Pranthora sends an interruption signal to your connection:
    • Pure WebSocket: text frame "stop"
    • Telephony Protocol: {"event": "clear", "streamSid": "..."}
  3. Your infrastructure must stop playback and discard any buffered audio.
  4. Pranthora processes the new user speech and sends a fresh response.
Interruptions are validated intelligently — filler sounds like “um”, “uh”, or “hmm” do not trigger an interruption, but clear speech ("wait", "stop", "actually", direct questions, etc.) will.

WebSocket Close Codes


Quick Reference

Pure WebSocket

HTTP + WebSocket

Telephony Protocol