Skip to main content

Live Transcript WebSocket API Reference

WebSocket Endpoint

Endpoint: wss://api.burki.dev/live-transcript/{call_sid}?token={api_key} This WebSocket endpoint provides real-time streaming of call transcripts as they are generated. It’s designed for building live monitoring dashboards, call supervision tools, and accessibility features.

Path Parameters

  • call_sid (string, required): The Burki call SID you want to monitor

Authentication

Required: All connections must be authenticated with a valid API key or JWT token. Methods Supported:
  1. Query Parameter (Recommended):
  2. Authorization Header (non-browser clients): Use this with server-side WebSocket clients (Node ws, Python websockets, etc.). Browsers do not allow custom Authorization headers on new WebSocket(...).
  3. WebSocket Subprotocol:

Access Control

  • Only users from the same organization as the call’s assistant can access the transcript stream
  • API keys must have valid permissions and belong to an active user
  • Invalid authentication results in immediate connection termination with code 1008

Connection Process

  1. Establish Connection: Connect to the WebSocket endpoint with a valid Call SID
  2. Receive Confirmation: Server sends a connection established message
  3. Get Historical Data: Receive any existing transcripts for the call
  4. Stream Live Data: Receive real-time transcripts as they’re generated
  5. Handle Status Updates: Receive call status changes (start, end, etc.)

Server-to-Client Messages

Connection Established

Transcript Data

Field Descriptions:
  • content: The transcribed text
  • speaker: "user" or "assistant"
  • is_final: Whether this is a final transcript
  • confidence: Speech recognition confidence (0.0 - 1.0)
  • segment_start: Start time in seconds from call start
  • segment_end: End time in seconds from call start
  • created_at: ISO timestamp of transcript creation

Call Status Updates

Status Values:
  • in-progress: Call is active
  • completed: Call ended successfully
  • failed: Call failed or was terminated

Error Messages

Pong Response

Client-to-Server Messages

Ping (Health Check)

Send a ping to test connection health:
Response: Server will reply with a pong message

Request Status

Request the current call status:
Response: Server will reply with a call_status message

Features

Historical Transcripts

When connecting to an ongoing call, you’ll immediately receive all existing transcripts before new live data starts streaming.

Multiple Connections

Multiple clients can connect to the same call simultaneously without performance impact.

Automatic Cleanup

Connections are automatically cleaned up when:
  • Clients disconnect
  • Calls end
  • Connection errors occur

Error Handling

The server gracefully handles:
  • Invalid Call SIDs
  • Connection timeouts
  • Malformed messages
  • Concurrent connection limits

Example Usage

JavaScript

Python

Error Codes

Best Practices

  1. Secure API Keys: Store API keys securely and never expose them in client-side code
  2. Implement Reconnection: Use exponential backoff for reconnection attempts
  3. Handle All Message Types: Process all message types to avoid missing important updates
  4. Validate Call SID: Ensure Call SID format is valid before connecting
  5. Use Ping/Pong: Regularly send pings to maintain connection health
  6. Error Handling: Always handle connection errors and authentication failures gracefully
  7. Use Query Parameters: Prefer query parameter authentication for simplicity

Security Considerations

  • Validate Call SID ownership before connecting
  • Implement rate limiting in production
  • Use secure WebSocket connections (WSS) over HTTPS
  • Consider implementing authentication tokens for sensitive deployments