Skip to main content

Keep a chat reply current while the user waits

Section ID: Guide/j7obcqlplu#receive-conversation-updates

Keep your chat display up to date with conversation-state reads. If your deployment also provides live updates, use its connection instructions and refresh state after a disconnect.

The native conversation operations do not use the OpenAI wire protocol. An OpenAI SDK cannot call them by changing its base URL alone.

For the first implementation, choose asynchronous send plus state reads. You need an authenticated thread and the run ID retained from the send. Add deployment-specific live updates only after the same read/recovery path works.

Recipe: update the reply and recover a dropped connection​

Section ID: Guide/j7obcqlplu#get-replies-with-the-current-api

Use the send-and-poll recipe to submit a turn and follow its outcome with the current API. Keep the returned conversation and turn identifiers so recovery reads the same work.

After a dropped response, reconcile the original turn before sending again. A second send can create new work or invoke the configured concurrency policy. Streaming or live-view availability is deployment-specific; use the transport guidance below and confirm that the selected surface is enabled.

Variant: add live updates available in your deployment​

Section ID: Guide/j7obcqlplu#integrate-a-qualified-streaming-transport

Follow the deployment's connection instructions, load the current authorized state and use live updates to keep the view responsive. Retain the state-read path for reconnect and missing events. A snapshot plus a live subscription is not automatically gap-free.

The public API reference does not provide a universal subscription URL or replay cursor. Use the state-read recovery flow in receiving updates and the field interpretation in interpreting updates. A deployment-specific subscription does not replace authoritative state reads.

See API conventions for the current native protocol and conversation generation for reply handling.

Upcoming recipe: stream a reply through the client’s chosen protocol​

Section ID: Guide/j7obcqlplu#native-and-compatible-streams

Status: Upcoming — not yet available.

Choose native conversation run events when the client needs Travila run/tool status, or a supported OpenAI Responses or Chat Completions interface for an application using that protocol. A self-hosted deployment path supports these streaming workflows.

  1. Start with that transport’s authentication and event contract.

  2. Keep the accepted run and individual attempt distinct while displaying partial answer content provisionally.

  3. Continue complete tool calls through the matching protocol.

  4. Follow the reconnection flow after a disconnect and use event identities and outcomes to reconcile the final result.

Finished result: incremental output leads to a recognizable terminal outcome. Native and compatible payloads stay within their own protocol; provisional text does not complete the run.

Each transport defines its own authentication, event schema, terminal outcomes, replay boundary and retention limits. Subscription URLs and SDK setup for these interfaces are not yet available. Current native REST operations retain their existing protocol.

Document ID: Guide/j7obcqlplu