Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sequentum.com/llms.txt

Use this file to discover all available pages before exploring further.

While an Agent Builder session is running, the work it’s doing — pages it visits, plans it generates, data it extracts — surfaces as a stream of typed events. Long-poll them with one endpoint:
GET /api/v1/agent-builder/{sessionId}/events?lastEventIndex=N
This is the workhorse for any UI or backend that watches a session.

Cursor pattern

Pass lastEventIndex=-1 on the first call. Each response carries:
  • events[] — events emitted since your cursor.
  • lastEventIndex — the index of the last event in this response.
Pass that returned lastEventIndex on the next call. Repeat until you see a terminal event.
LAST=-1
while :; do
  RESPONSE=$(curl -s "https://dashboard.sequentum.com/api/v1/agent-builder/$SESSION_ID/events?lastEventIndex=$LAST" \
    -H "Authorization: ApiKey $SEQUENTUM_API_KEY")
  LAST=$(echo "$RESPONSE" | jq -r .lastEventIndex)
  echo "$RESPONSE" | jq -c '.events[]'
  # Break on terminal event in your loop
done
Despite the underlying class being named AgentBuilderSseEvent, the External API delivers events via HTTP long-poll, not Server-Sent Events. Each call returns a snapshot; you re-call to get more. Long-poll is simpler to consume from any client and Sequentum doesn’t charge per call.

Event types

Every event carries a discriminator type, plus base fields timestamp and eventIndex. Per-type payloads:
TypePayloadNotes
session_startedsessionId, modeFirst event in every session.
user_promptpromptReplays the original prompt; useful for UI reconstruction.
thinkingmessageBuilder reasoning narration.
user_messagemessageMessage to display to the user.
plan_generatedplanA structured plan was produced.
step_startedstepNumber, totalSteps, description, actionTypeA plan step is starting.
step_completedstepNumber, success, snapshot, commandAddedA plan step finished.
errormessage, stepNumber, isRecoverableTerminal if isRecoverable is false.
navigation_completedurl, title, snapshot, configId, agentNameThe browser landed on a new URL.
screenshotimageBase64A new screenshot is available.
command_addedcommandA command was added to the in-progress agent.
ready_for_interactionsnapshot, message, configId, agentName, hasBrowserUrlBuilder is paused, awaiting human input.
tool_executiontoolName, phase, args, result, success, durationMsInternal tool ran (start/end). Useful for debugging.
llm_responseiteration, content, hasToolCalls, toolCount, isCompleteRaw model output. Debugging.
extended_thinkingiteration, thinkingContent, isCompleteStreamed model reasoning. Debugging.
data_extractedcolumns, rows, totalRowsStructured data was extracted from the page.
todos_updatedtodosBuilder’s task list changed.
browser_session_readyurlFrontend can connect to the browser WebSocket (UI use).
completedconfigId, agentName, commandCountTerminal — Agent saved.

Terminal events

Stop polling on:
  • completed — the Agent was saved; pull configId and agentName from the payload.
  • error with isRecoverable: false — the session is dead.
Cancellations don’t emit an event — detect them by polling GET /{sessionId}/status and watching for status: "cancelled".

What you actually need to handle

Most production integrations only care about a handful of types. A reasonable minimum:
  • session_started — record that the session is live.
  • data_extracted — surface progress to your user.
  • ready_for_interaction — prompt the user for follow-up input.
  • completed — save the resulting configId.
  • error — handle the failure mode.
Ignore the rest unless you’re building a debug surface.