Control Existing Sessions

​

What you can do

• Fetch session metadata to understand current state and links
• List messages to read the full conversation history
• Send follow-up messages to continue or redirect the session
• Poll final_message to wait for the next assistant result

​

Common pattern

1. Store the session_id when the session is created.
2. Load the session later with GET /rest/v1/sessions/{session_id}.
3. Read prior messages with GET /rest/v1/sessions/{session_id}/messages.
4. Send a new instruction with POST /rest/v1/sessions/{session_id}/messages.
5. Poll the returned _links.final_message.href to receive the assistant’s next completed reply.

​

Example

const headers = {
  Authorization: `ApiKey ${process.env.BLOCKS_API_KEY}`,
  "Content-Type": "application/json",
};

const sessionId = "a196cec6-49cb-4c48-8e4c-2707fb5d6709";

const session = await fetch(
  `https://api.blocks.team/rest/v1/sessions/${sessionId}`,
  { headers },
).then((r) => r.json());

const history = await fetch(session._links.messages.href, { headers }).then((r) => r.json());

const followup = await fetch(
  `https://api.blocks.team/rest/v1/sessions/${sessionId}/messages`,
  {
    method: "POST",
    headers,
    body: JSON.stringify({
      message: "Summarize the current plan and suggest the next best action.",
    }),
  },
).then((r) => r.json());

const finalMessage = await fetch(followup._links.final_message.href, { headers }).then((r) => r.json());

​

Good fits

• Reopening a session from your own application UI
• Letting support or operations tools inspect active work
• Handing a live session from one system step to another
• Continuing long-running work without losing context