Streaming
Subscribe to thread updates using bidirectional gRPC streaming or Server-Sent Events (SSE).
Subscribe to thread updates using bidirectional gRPC streaming or Server-Sent Events (SSE).
The Thread API provides two methods for streaming real-time thread events: gRPC bidirectional streaming and REST API Server-Sent Events (SSE). Both methods deliver incremental message chunks, artifacts, and completion events as they occur during thread execution.
Choose the method that best fits your infrastructure:
The SSE endpoint (GET /v2/threads/stream/{thread_id}) establishes a persistent HTTP connection that streams events as they occur. Open the stream connection before calling POST /v2/threads/{thread_id}/messages to capture all events.
The server pushes events in this typical flow:
message_work_in_progress logs may appear before or between chunks, indicating background processing.message_chunk events arrive incrementally as the AI generates its response. Each chunk contains the partial text under message_chunk.message and a final_chunk boolean flag.final_chunk: true arrives, the complete message is ready.message events signal that a complete message has been assembled.task_status or execution_status events report progress. When status: "Complete" appears, the thread is idle.If the SSE channel closes before completion, call GET /v2/threads/{thread_id}/progress to check status. Issue DELETE /v2/threads/{thread_id}/task when a user manually stops work.
The following example demonstrates the full workflow: creating a thread, establishing an SSE stream, sending a message, and processing real-time events until completion.
The script uses Python’s threading module to establish the SSE stream before sending the message, ensuring all events are captured:
Set the ALFA_ACCESS_TOKEN environment variable with your OAuth2 access token obtained via token exchange. See the authorization guide for details. The threading synchronization ensures the SSE listener is ready before the message triggers any events, preventing lost chunks.
The stream emits several event types. Here are the most common:
Work in progress logs (background processing updates):
Message chunks (incremental response text):
Final chunk (last piece of the message):
Complete message (with metadata and citations):
Artifacts, when present, are JSON strings embedded in the message text (wrapped in triple backticks). Use GET /v2/threads/{thread_id}/artifacts/{artifact_id} to fetch the actual artifact data.
Task status (progress updates):
The message text is located at event.message_chunk.message. When final_chunk: true appears, the complete message is ready. The client must parse any artifact markers from the message text to extract artifact_id values. The script continues listening until it receives a task_status event with status: "Complete", signaling that all processing has finished.
Complete messages include a citations array in message_metadata. Each citation has a citation_type field that determines which additional fields are present. All citations share these common fields:
Web citation (citation_type: "web"):
References a web page with a direct link and snippet highlight positions.
News development citation (citation_type: "news_development"):
References a news development that aggregates multiple related articles.
Document citation (citation_type: "text"):
References a document such as an SEC filing, with snippet highlight positions.
Download and compile the following protocol buffer file to generate client stubs:
Generate client code from the proto file using the gRPC tools for your language.
Python:
This generates:
thread_service_pb2.py: Protocol buffer message classesthread_service_pb2_grpc.py: gRPC service stub classesthread_service_pb2.pyi: Type stubs for type checkingGo:
This generates Go code locally. Update the go_package option in the proto file to match your module path, or import the generated code using the path specified in go_package.
Establish a secure gRPC channel with keepalive settings to maintain the connection:
The keepalive settings ensure the connection remains active even during periods of inactivity, preventing timeouts.
The following example demonstrates subscribing to thread events via gRPC streaming:
thread_id, user_token, and subscribe=True. The generator continues running to keep the stream alive.StreamThreadEventsResponse contains:
thread_id: The thread the event belongs touser_ids: List of user IDs that requested accessthread_data: A ThreadData message containing the event payloadThe thread_data field is a ThreadData message with a oneof payload that can be one of:
message_event: A complete message with citationsmessage_chunk_event: An incremental message chunk with optional citations (check final_chunk for completion)work_in_progress_event: Background processing statusthread_name_event: Thread name updatesworker_error_event: Error notificationsmessage_cancelled_event: Cancellation confirmationsThe request generator must continue yielding or sleeping to keep the bidirectional stream alive. If the generator exits, the stream will close.
Complete messages and message chunks both include a citations array. Each citation carries common metadata plus a type-specific object determined by citation_type:
Web citation (web_citation):
References a web page with a direct link and snippet highlight positions.
News development citation (news_development_citation):
References a news development that aggregates multiple related articles.
News article citation (news_article_citation):
References a specific news article with a direct link and article identifier.
Document citation (document_citation):
References a document such as an SEC filing, with snippet highlight positions.
Fiscal quarter earnings citation (fiscal_quarter_earnings_citation):
References an earnings call transcript or report for a specific fiscal quarter.
Variable citation (variable_citation):
References a computed financial variable or metric, including its formula, data provider, time range, and periodicity.
gRPC streaming uses Bearer token authentication via metadata. Include your service account token in the metadata:
Obtain your service account token from your Boosted account. See the authorization guide for details. Ensure your token has permission to access the specified thread.