Documentation Index
Fetch the complete documentation index at: https://docs.sigmic.ai/llms.txt
Use this file to discover all available pages before exploring further.
Streaming Events
Real-time task events are delivered via Server-Sent Events (SSE) through theGET /api/v1/tasks/:id/stream endpoint. This is the recommended way to receive live updates as the AI agent processes your request.
Architecture
The API uses a fire-and-forget pattern:POST /tasksreturns JSON immediately with the task IDGET /tasks/:id/streamis the unified SSE channel for all events
SSE Format
Events are delivered in the standard SSE format:- event - The event type identifier
- data - JSON payload with event details
\n\n).
Stream Phases
The stream delivers events in three phases:Phase 1: History Replay
All saved conversation messages are emitted ashistory_message events.
Phase 2: History Complete
A singlehistory_done event signals that history replay is complete and indicates whether the task is still running.
Phase 3: Live Events (if running)
If the task is currently executing, the stream delivers catch-up state followed by real-time events until the task completes.Event Types
history_message
A replayed conversation message. Emitted for each saved message at the start of the stream.
history_done
Signals that all history messages have been sent.
| Field | Description |
|---|---|
messageCount | Number of history messages emitted |
isStreaming | true if the task is running (live events follow), false if task is idle |
status
Processing status updates indicating task progress.
| Status | Description |
|---|---|
connecting | Establishing connection to the agent |
processing | Task is being processed |
retrying | Retrying after a temporary failure |
thought
Agent’s thinking and reasoning process. Useful for understanding how the AI approaches the task.
content
Text content from the agent’s response. May be delivered in chunks.
| Field | Description |
|---|---|
text | The content text |
isPartial | true if more content is coming, false for final chunk |
tool_call
Indicates a tool is being executed by the agent.
| Status | Description |
|---|---|
pending | Tool call queued |
executing | Tool is currently executing |
awaiting_approval | Waiting for manual approval (when autoExecute=false) |
tool_result
Result of a completed tool execution.
error
Error event indicating something went wrong.
done
Task completion event with the final response.
The
done event signals that the current execution turn is complete. For completed tasks, the stream ends after this event. For ongoing conversations, you can send follow-ups and reconnect.Subagent Events
When the AI agent delegates work to specialized subagents, these events track the subagent’s lifecycle and activity. Each subagent session begins withsubagent_start and ends with subagent_end, with subagent_thought and subagent_tool events in between.
subagent_start
Emitted when the agent delegates work to a subagent.
| Field | Description |
|---|---|
agentName | Unique identifier for the subagent |
displayName | Human-readable name |
description | What the subagent does |
objective | The specific task delegated to the subagent |
subagent_thought
Reasoning text from a running subagent.
| Field | Description |
|---|---|
agentName | Which subagent produced this thought |
text | The thought/reasoning text |
subagent_tool
Tool usage within a subagent. Emitted at both the start and end of each tool call.
| Field | Description |
|---|---|
agentName | Which subagent is using the tool |
status | start when the tool begins, end when it completes |
toolName | Name of the tool being used |
args | Tool arguments (present on start events) |
output | Tool output (present on end events) |
subagent_end
Emitted when a subagent finishes execution.
| Field | Description |
|---|---|
agentName | Which subagent finished |
terminateReason | GOAL (success), TIMEOUT, MAX_TURNS, ERROR, or ABORTED |
result | Summary of what the subagent accomplished (on success) |
error | Error message (when terminateReason is ERROR) |
Parsing SSE in Code
JavaScript
Python
Connection Handling
Heartbeat events
Heartbeat events
The server sends periodic heartbeat comments (
:heartbeat) to keep the connection alive. These can be safely ignored by SSE parsers.Reconnection
Reconnection
Disconnect and reconnect to the stream at any time. The stream replays full conversation history, then catches up to the current state. The task continues executing in the background regardless of stream connections.
Background execution
Background execution
Closing the stream connection does NOT cancel or stop the task. Execution continues in the background. Use
DELETE /api/v1/tasks/:id to explicitly cancel a task.Timeouts
Timeouts
Tasks may take several minutes to complete. Ensure your HTTP client has appropriate timeout settings. The 15-second heartbeat keeps the connection alive.
Polling as an Alternative
If you cannot use SSE streaming (e.g., due to infrastructure limitations), you can poll the task endpoint to get real-time progress via theoutput field.
Output Structure
When pollingGET /api/v1/tasks/{id}, the response includes an output object that works the same way for both running and completed tasks:
| Field | Description |
|---|---|
output.content | Accumulated text response (partial while running, final when completed) |
output.updatedAt | ISO timestamp when the output was last updated |
output.thoughts | Agent’s thinking process |
output.toolCalls | All tool executions with their current status |
pendingApprovals | Tool calls awaiting approval (for autoExecute=false tasks) |
Use the task’s
status field to determine if output.content is partial (when status is running or awaiting_approval) or final (when status is completed, failed, or cancelled).Polling Example
SSE vs Polling
| Approach | Pros | Cons |
|---|---|---|
| SSE Streaming | Real-time updates, history replay, lower latency | Requires SSE support, persistent connection |
| Polling | Works everywhere, simpler implementation | Higher latency, more API calls |