Chat API

A chat thread holds one investigation: your questions and the answers from Squasher. Threads are visible to the project team, so you can continue one investigation from the web chat page, squasher ask, API clients, or MCP Code Mode. Conversations with the Squasher Agent in Slack are separate and are not stored in chat threads. See Squasher Agent.

Threads

GET /v1/projects/{project_id}/threads
GET /v1/projects/{project_id}/threads?incident_id=INC-123
POST /v1/projects/{project_id}/threads
GET /v1/projects/{project_id}/threads/search?q=checkout
GET /v1/projects/{project_id}/threads/{thread_id}
POST /v1/projects/{project_id}/threads/{thread_id}/archive
POST /v1/projects/{project_id}/threads/{thread_id}/unarchive
DELETE /v1/projects/{project_id}/threads/{thread_id}

Thread records include source, created_by, external_thread_id, archived_at, last_message_at, model_id, and the canonical incident UUID in incident_id when the conversation belongs to an incident. The list filter accepts either that UUID or the incident’s user-facing display ID. The list, search, and get routes also return origin, which says what opened the thread:

kind: dashboard, slack, api, cli, or mcp for a thread a person started; monitor, connector, or incident for a thread an incident opened; drill for a test alert sent to check an alert connector; automation for other automatic threads.
incident: the incident’s display id, severity, status, and title, or null.
monitor: the id and name of the monitor that opened the incident, or null.
connector: the id, label, and provider of the alert connector that opened the incident, or null.

Incident triage and fix runs share this durable thread, so the dashboard, API, CLI, and MCP Code Mode can continue with the full context.

Messages

GET /v1/projects/{project_id}/threads/{thread_id}/messages
POST /v1/projects/{project_id}/threads/{thread_id}/messages

Message records include a stable message id, append-only sequence, role, source, text, external message id, and author metadata. Human messages can carry author_name, author_image, and an authenticated user id. Assistant and system messages are attributed to Squasher. Assistant history may also include a parts array, in the order the answer was made:

Part type	Fields
`text`	`text`: the text of one step.
`step-start`	None. Starts the next step of the agent. Text before it belongs to the step before.
`tool`	`id`, `name`, `title`, `state` (`running`, `done`, `error`, or `approval-requested`), and optional `detail`, `summary`, `duration_ms`, `input`, `output`, and `approval`.
`platform-result`	`entity` (`monitor`, `incident`, or `issue`), `id`, `title`, and optional `status`, `severity`, and `description`.

A tool part is one tool call of the agent. Squasher writes title, detail, and summary (for example “Read issues”, GET /errors, and “43 results”). input and output are previews of at most 1,500 characters. An approval-requested part has approval.action, and optional approval.details and approval.operation: the change the agent asks to make. Squasher never makes a change for the agent without a person’s approval. When the part also has approval.id, the change is held until a project owner or admin presses Approve or Decline in the Squasher chat or in Slack. An approved change runs once, and the result arrives in the same conversation as the next message. A request expires after 24 hours. Older parts without approval.id are answered with a new message that starts with Approved: or Declined:. The required top-level text field is the plain-text projection for existing clients: the text of every step, with a blank line between steps. Platform results never include a URL; clients construct their own project-scoped destinations from the entity and id. Responses are ordered by sequence, not client timestamps. Replaying the same message id, or the same source plus external message id, is idempotent. This lets web, API, CLI, and MCP append concurrently without one surface overwriting another surface’s messages.

Ask

POST /v1/projects/{project_id}/ask
POST /v1/projects/{project_id}/ask/stream

ask creates or continues a shared thread and stores the question as a user message. Pass thread_id to continue an existing investigation. By default, /ask/stream returns text/plain; charset=utf-8 chunks as the assistant responds, then persists the assistant message back to the same thread. This remains the compatible format for terminal, CLI, and other API clients. Web clients can opt into typed streaming by sending:

Accept: application/x-ndjson

The response is newline-delimited JSON with one event per line:

{"type":"status","state":"thinking"}
{"type":"status","state":"searching"}
{"type":"platform-result","part":{"type":"platform-result","entity":"monitor","id":"mon_123","title":"Checkout health","status":"failed","description":"Timed out"}}
{"type":"text-delta","text":"The checkout monitor is failing."}
{"type":"done"}

To also receive the steps of the agent, send:

Accept: application/x-ndjson; steps=1

The stream then also has step-start events and tool events. Each tool event has the full tool part. The same tool id arrives again when its state changes, so replace the earlier part:

{"type":"tool","part":{"type":"tool","id":"call_1","name":"execute","title":"Read issues","detail":"GET /errors","state":"running"}}
{"type":"tool","part":{"type":"tool","id":"call_1","name":"execute","title":"Read issues","detail":"GET /errors","state":"done","summary":"43 results","duration_ms":812}}
{"type":"step-start"}
{"type":"text-delta","text":"## Errors in the last 7 days"}

Status states are thinking, searching, or working. A failed stream ends with an error event instead of done. Platform results are emitted only from strictly validated Squasher tool results, are deduplicated by entity and id, and contain no model-supplied links or other source fields. The persisted assistant message contains the same text and platform-result parts, so message history can reproduce the typed response.

Start here

Resources

Threads

Messages

Ask

​Threads

​Messages

​Ask

Threads

Messages

Ask