https://inkbox.ai/api/v1/slack. Use the selected connection’s current conversation access and contact rules. Starting or stopping a stream does not start or cancel your agent’s work.
Check availability
Inspect connection capabilities. Thetask_streaming capability requires chat:write. scopes_satisfied: true confirms that permission, not that the app and workspace support native task streams. native_task_streaming is missing_scope or unknown; unknown does not mean supported or unsupported.
Check every operation’s result. Unsupported native requests fail without automatically posting a substitute message. Your runtime can choose an ordinary message with edits before starting a native stream, or after a definitively unsupported start. Do not post that fallback after an uncertain start: the native stream may already exist.
Stream lifecycle
- Start the stream in the existing request thread. Supply the intended recipient’s Slack user and workspace IDs.
- Wait for the start operation to be
succeeded. Save itsidas the stream ID. - Append task updates in order. Wait for each operation’s outcome before sending the next.
- Stop the stream when work finishes or stops. Include final task updates if needed.
message_ts or an append operation’s UUID. The conversation, thread, and connection remain fixed for that stream. A stream from an earlier connection authorization is not reusable after reconnecting.
Every write requires its own Idempotency-Key. Save each key before making the request. Reuse that key with the same input to recover the same logical operation, not to request another update. See operation idempotency.
Start a stream
Take the destination and recipient from the request you are answering. Do not invent a thread timestamp or use a different workspace’s connection.
Returns
200 with a Slack operation, whose operation is stream_start. On success, id identifies the stream, message_ts identifies its Slack message, and thread_ts identifies its original thread. HTTP 200 alone does not mean the stream started.
Append task updates
stream_id is the successful start operation’s UUID. chunks requires 1–20 updates. Append does not accept a new recipient, thread, or message timestamp. Returns an operation with operation: "stream_append" and its own id.
Stop a stream
chunks is optional and accepts 0–20 updates; {} closes the stream without additional task updates. Returns an operation with operation: "stream_stop". A successful stop closes the stream to new append and stop operations. Reading or replaying the same completed operation with its original key remains possible.
Stopping the stream does not send a separate final answer. Send any final reply or attachment through the ordinary message or file endpoints.
Chunk types
Use a stableid when updating the same task. Task status and operation status are different: complete describes a task card, while succeeded describes an API operation.
Task IDs are 1–256 characters from letters, digits,
., _, :, or -. Titles are 1–256 characters. Optional details and output each accept up to 256 characters. Task status is in_progress, complete, or error.
Use the SDK
The task-stream methods and operation-by-key lookup require SDK or CLI version0.7.16 or later. The examples below show the successful path after you have checked capabilities. Replace the example coordinates with those from the request you are answering, and save a distinct key for each logical operation before sending it.
id returned by append or stop identifies that operation; keep using the original start’s id to address the stream.
Handle uncertain outcomes
Read the operation by ID, or recover it using its original idempotency key if the response was lost. Lookup does not repeat the write. Operation lookup is separate from message-send action lookup.in_progress: wait and inspect the same operation again.succeeded: use the confirmed result before advancing the stream.failed: inspecterror_codeand honorretry_afterbefore deciding whether a new operation is appropriate.unknown: the write may have happened. Do not blindly start another stream or repeat the write with a new key.
in_progress or unknown append or stop returns 409 for any new append or stop. An unknown outcome does not clear through lookup or replay, so you cannot subsequently update or close that stream through this API. A successfully closed stream also rejects new writes with 409. A missing or unavailable start operation returns 404.
A 404 from operation-by-key lookup is not proof that a lost start request cannot complete. Keep its original key and identical input; do not start a replacement stream under a new key because a lookup has not found it yet.
An unknown operation does not automatically become confirmed. If its outcome cannot be established, keep the uncertainty rather than creating duplicate progress messages. Native progress is optional; it should not prevent your runtime from finishing or cancelling its own work.
