Skip to main content
PurposeThe checkpoint event acts as a marker in your audio event queue. When Vobiz finishes playing all audio events that were sent before the checkpoint, it sends a playedStream acknowledgment back to your application. This allows you to:
  • Track playback completion of specific audio segments
  • Synchronize your application logic with audio playback
  • Implement multi-turn conversations with timing control

Attributes

Request & Response

Request Format

Send this JSON message through the WebSocket to Vobiz:
Checkpoint event request

Response Format

When the checkpoint is reached (all previous audio has been played), Vobiz responds with:
playedStream acknowledgment
The WebSocket playedStream event carries only event and name - the name echoes the value you set on the matching checkpoint. Match acknowledgments by name, not streamId.
WebSocket playedStream vs HTTP PlayedStream. Two different channels share a similar name:
  • The WebSocket playedStream event (above) is event + name only.
  • The HTTP Event=PlayedStream status callback (sent to statusCallbackUrl) is form-encoded and does include StreamID, CallUUID, Name, etc. See Status callback events.
Use the WebSocket event for tight in-conversation timing; use the HTTP callback for logging and out-of-band workflows.
playedStream is conditional.It is only emitted if the audio queued before the matching checkpoint played to completion. If playback is interrupted (e.g. by a clearAudio event, a barge-in, or call disconnection), you will not receive this acknowledgment. Never block conversation logic on it - always pair a checkpoint with a timeout fallback.

Examples

Complete Event Sequence

Play audio + checkpoint + acknowledgment

Node.js Implementation

Using checkpoints to manage conversation flow
This example demonstrates using checkpoints to manage a multi-turn conversation flow, transitioning between states only when the current audio has finished playing.

Python AsyncIO Example

Checkpoint handling in Python

Ordering and edge cases

  • Send the checkpoint immediately after the last playAudio chunk of an utterance. The checkpoint marks a position in the playback queue, so it acks only after every chunk queued before it has been delivered to the caller.
  • Acks are not guaranteed and not ordered against media. A playedStream may arrive interleaved with inbound media frames. Match on name; don’t assume it is the next message after your checkpoint.
  • A clearAudio voids pending checkpoints. Any checkpoint whose audio was still queued when you sent clearAudio will never ack. Reset per-utterance state when you barge in.
  • Use unique names per utterance. Re-using a name across turns makes acks ambiguous. A monotonic counter (response-1, response-2, …) is a good pattern.
  • Always set a timeout fallback. Because the ack is conditional, drive a watchdog timer alongside each checkpoint so a dropped ack cannot stall the conversation.
Checkpoint with a timeout fallback

Best Practices

Use Descriptive Checkpoint Names

Give your checkpoints meaningful names that clearly indicate what audio segment they represent. This makes debugging and maintaining your code much easier.

Don’t Rely on Checkpoints for Critical Logic

Remember that playedStream acknowledgments may not arrive if the call is disconnected or audio is interrupted. Always have fallback logic for timeout scenarios.

Send Checkpoints Immediately After Audio

For the most accurate timing, send your checkpoint event immediately after the corresponding playAudio event. This ensures the checkpoint marks exactly when that audio segment finishes.