クイックスタート
/access-token エンドポイント からアクセストークンを取得します。詳細は クライアントアプリの認証 を参照してください。
接続
WebSocket エンドポイントに接続します:| ヘッダー | 値 |
|---|---|
Authorization | Bearer {token} |
Cartesia-Version | 2025-04-16 |
プロトコル概要
WebSocket 接続は、制御イベントには JSON メッセージ、メディアには Base64 エンコードされた音声を使用します。 クライアントがstart イベントを送信すると、サーバーは ack で応答します。その後、両者は接続が閉じるまで音声と制御イベントを交換します。
クライアントイベント
Start イベント
音声ストリームの構成を初期化します。configはエージェントのデフォルトの入力音声設定を上書きしますstream_idは任意です。指定されない場合、サーバーが生成してackイベントで返します
stream_id(任意): ストリーム識別子。指定されない場合はサーバーが生成config.input_format: クライアント音声入力の音声形式(mulaw_8000、pcm_16000、pcm_24000、pcm_44100)config.voice_id(任意): エージェントのデフォルト TTS ボイスを上書きagent(任意): API 経由で個別のエージェント通話を構成し、本番環境に公開せずに introduction やプロンプトの変更をプレビュー可能metadata(任意): カスタムメタデータオブジェクト。これらはエージェントコードに渡されますが、特別なフィールドも使用できます:to(任意): コールルーティング用の宛先識別子(デフォルトはエージェント ID)from(任意): 通話の発信元識別子(デフォルトは「websocket」)
Media Input イベント
クライアントからサーバーに送信される音声データです。payload の音声データは Base64 エンコードする必要があります。
stream_id: ack レスポンスから取得したストリームの一意の識別子media.payload: start イベントで指定された形式の Base64 エンコードされた音声データ
DTMF イベント
DTMF(デュアルトーン多重周波数)トーンを送信します。stream_id: ストリーム識別子dtmf: DTMF 桁(0〜9、*、#)
Custom イベント
エージェントにカスタムメタデータを送信します。stream_id: ストリーム識別子metadata: カスタムデータのキーと値のペアを含むオブジェクト
サーバーイベント
Ack イベント
ストリーム構成を確認します。start イベントで stream_id が指定されなかった場合、サーバーが生成した stream_id を返します。
Media Output イベント
サーバーがエージェントの音声レスポンスを送信します。payload は Base64 エンコードされた音声データです。
Clear イベント
エージェントが現在の音声ストリームをクリア/中断したいことを示します。Transfer Call イベント
エージェントが通話を電話番号に転送したいことを示します。クライアントは自身のテレフォニー側で転送を開始する責任があります。stream_id: ストリーム識別子transfer.target_phone_number: 通話を転送する E.164 形式の電話番号
接続の管理
無操作タイムアウト
サーバーは 180 秒 後にアイドル接続を閉じます。クライアントからのメッセージがあるたびにタイマーがリセットされます:- アプリケーションメッセージ(media_input、dtmf、custom イベント)
- 標準の WebSocket ping フレーム
- その他の有効な WebSocket メッセージ
- コード: 1000(Normal Closure)
- 理由:
"connection idle timeout"
Ping/Pong キープアライブ
無音期間中の無操作タイムアウトを防ぐため、定期的なキープアライブとして標準の WebSocket ping フレームを使用します:接続の終了
接続はクライアントまたはサーバーのどちらからでも WebSocket クローズフレームを使って閉じることができます。 クライアント開始のクローズ:- コード: 1000(Normal Closure)
- 理由:
"call ended by agent"または、追加のコンテキストが利用可能な場合は"call ended by agent, reason: {specific_reason}"
ベストプラクティス
- 最初に
startを送信 —startより前に他のイベントが送信されると接続は閉じられます。 - 適切な音声形式を選択 — ソースに合わせて形式を選択してください:テレフォニーには
mulaw_8000、Web クライアントにはpcm_44100。 - クローズを適切に処理 — デバッグやリカバリのため、常にクローズコードと理由をキャプチャしてください。
- 接続を維持 — 180 秒の無操作タイムアウトを回避するため、60〜90 秒ごとに WebSocket ping フレームを送信してください。
- ストリーム ID を管理 — システム全体のオブザーバビリティを高めるため、独自の
stream_id値を指定してください。 - アイドルタイムアウトから復旧 —
1000 / connection idle timeoutの場合、再接続してstartイベントを再送してください。