Skip to main content
Every assistant conversation is a chat session identified by an ID. This recipe walks through a common export pattern:
  1. Resolve a project ID (by name or from a known UUID).
  2. List session IDs for that project within a created_at date range.
  3. Fetch every message in each session (user turns, assistant replies, and tool calls).
Each message expands into one or more typed events (user_message, assistant_message, tool_call, tool_result, compaction), so tool calls and results appear inline rather than on a separate endpoint.
All endpoints require admin access and operate at tenant scope: with an admin platform access token or dashboard session, you can list and read any session in your workspace, not only ones you started.

Endpoints used

Resolve the project ID

If you already have a project ID, skip this step. GET /api/v1/projects returns paginated projects.

List sessions for a project and date range

GET /api/v1/assistants/sessions returns sessions for your workspace. Use project_id plus timestamp_start / timestamp_end to restrict to sessions created within a range (both bounds are inclusive, ISO 8601):
count is the total number of sessions matching your filters, not just the current page.
If timestamp_start is after timestamp_end, the API returns 400.
You can also grab a single session ID from the Session Logs page in the Caylex Platform UI — it’s the ID in the URL of an open session.

Reading the messages

GET /api/v1/assistants/sessions/{session_id}/messages returns the canonical paginated envelope plus a top-level session block identifying who the session belonged to:
size and total count messages, not events. One message can hold several events (e.g. an assistant turn with text plus parallel tool calls), so the items array’s combined event count is usually larger than size.
The full request and response schema for these endpoints is browsable in the interactive API reference at https://developers.caylex.ai.

raw vs resolved

The agent talks to the Caylex Navigator through meta-tools (suggest_tools, get_tool_schemas, invoke_tools, list_skills, …). invoke_tools is the one that runs the real downstream tools.
  • view=raw (default) shows exactly what happened, meta-tools included, useful for debugging the agent loop.
  • view=resolved drops the pure meta-tools and unwraps invoke_tools into the actual server tool calls and results it performed, so you see business tools like gmail_search_messages directly.
In resolved mode, unwrapped tool_call events carry server_name, intent, and parent_tool_use_id; unwrapped tool_result events carry tool_name and parent_tool_use_id.

The procedure

1

Resolve the project ID

GET /api/v1/projects and find the id for your project name — or use a project_id you already have from provisioning or the UI.
2

List sessions in the date range

GET /api/v1/assistants/sessions?project_id={id}&timestamp_start=…&timestamp_end=… and collect each session_id. Page with limit / offset while offset + len(sessions) < count.
3

Fetch messages for each session

For every session_id, call GET /api/v1/assistants/sessions/{session_id}/messages?size=100 (add view=resolved to hide meta-tools).
4

Page each session until done

While meta.has_next is true, call again with cursor=meta.next_cursor, accumulating items until has_next is false.

Full script

This resolves a project by name, lists all assistant sessions created in June 2026 for that project, then exports the complete message timeline for each session. Pass view=resolved to get business tools instead of Caylex meta-tools.
export_project_sessions.py
To reconstruct the agent’s reasoning, match each tool_call to its tool_result by tool_use_id. They share that ID even when they land in different messages (parallel tool calls return out of order). In resolved mode, the unwrapped events share the parent invoke_tools ID via parent_tool_use_id.

Next steps

Provision a customer project

Stand up a project per customer and capture the returned id for session exports.

Analytics overview

Aggregate metrics (queries, tool calls, error rates) across sessions.

Background Agent Tasks

Run the agent server-to-server; each task is backed by a chat session you can read here.

REST API Reference

Full request/response schemas for these endpoints.