What a system message does
POST /api/conversations/{conversation_session_id}/system-messages/ appends exactly one message to the live LLM context:
- It is not spoken.
- It is not treated as a user turn.
- Do not wrap it in extra JSON or role labels. Send the text you want the model to see.
run_llm controls what happens next:
Full request shape: Post a system message.
How you get the session id
You need the session UUID on your server. Typical sources:conversation_session_idfrom connectX-Akapulu-Conversation-Session-Idon every HTTP tool POST (live and Testing Mode). You cannot put the id in the endpoint template ahead of time. See Endpoints.
Authorization: Bearer <YOUR_AKAPULU_API_KEY>. Do not put the API key in the browser.
Workflow
HTTP tools on Akapulu return immediately. They are not a place to wait on a slow job. A pattern that works:- The in-call assistant calls an HTTP tool (for example “review this chart”).
- Your endpoint records the session id from
X-Akapulu-Conversation-Session-Id, starts the job, and returns a 2xx quickly. - Your server does the work.
- When it finishes, POST a system message into that session with the result.
When to set run_llm
false: the user is still talking, or you only want the facts available if they ask. Example: “Prior auth notes are in. Last A1C was 7.2.”true: the user is waiting for that result and the assistant should speak now. Example: “Chart review is done. Tell the patient the A1C in one short sentence.”
Example
Your tool handler starts work and returns:Limits and ownership
contentmust be a non-empty string, at most 16,000 characters.run_llmmust be a boolean if you send it.- The session must exist and be owned by the API key. Otherwise the API returns
SESSION_NOT_FOUND. - The same route works for Testing Mode session ids.
Keep HTTP tools short. If your endpoint waits minutes for a job, the live tool call sits open and the conversation feels stuck. Return quickly, then update context when the job is done.

