Logs

The workspace has four logs, one for each question you end up asking: what did people ask, what did Lookio answer and what did it cost, did my documents get indexed, and who changed what. They are free to read, and they live on the Logs page of the app, in the API under /v1/logs, in lookio logs, in the SDK as lookio.logs, and as MCP tools.

In the app

The Logs page has four tabs: Conversations, Answers, Indexing and Activity. Each tab has its filters, and the filters are kept in the address of the page, so you can copy the link of a filtered view and send it to a colleague. You also reach a filtered view from where the thing lives: an assistant, a widget, a resource and an API key each have a See all logs link that opens the logs already filtered on it.

Conversations

What people asked the assistants: your own chats from the app, the visitors of your widgets, and the users of your own product who reach an assistant through an API key or the MCP server. Use it to see what people really ask and where the assistant falls short.

Your own chats are yours alone. Every member sees their own in this tab (channel chat) and no one else’s: another member, an admin and an API key never see them. The widget, API key and MCP conversations are read by people who can edit assistants. So an answer of yours in the Answers log always has its conversation here, and Open the conversation works from both. The API and the MCP server list the widget, API key and MCP conversations only, never anyone’s chats.

A widget, API key or MCP conversation is kept 90 days after its last message. See Conversations and end users.

Each entry shows the channel, the widget or api_key it came through, the end_user (a widget visitor’s random id, or the one your product sent), the assistant, the number of messages, the credits and the thumbs. Open one conversation to read every question and answer with its sources, query mode, cost, duration and the thumb with its comment.

The figures are conversations, questions, distinct people (a conversation without an end_user counts as one person), credits, thumbs up and down, and the conversations per channel.

Answers

Every answer Lookio produced, one line each, whatever asked. It is the log behind your credits.

A line holds metadata only: the assistant, who asked, the query mode, the credits, how long it took, and whether the resources held an answer (an answer with nothing found is charged like any other). It never holds the question or the answer. When the exchange was kept, the line carries a conversation_id that leads to it in the Conversations log.

The figures are answers, answered and not, credits, the average time, and the answers per channel.

Who reads what: an admin reads every line. A member reads their own answers, plus those of widgets and API keys on the assistants they edit. An API key reads the widget and API lines of its assistants. A member’s own chats are personal: other people see their lines without content, and an API key sees none of them. Answers are kept with the usage history.

Indexing

Every indexing Lookio ran, one line each: a file read, a web page or a site’s page fetched, a text added, and each update of them. It is where you find out why a document is not searchable yet, or why it failed.

Each line shows the resource, what was read, the reader used, the pages, words and passages found, the warnings (such as pages without text), the error of a failure and the time it took. A site’s weekly sync re-reads its changed pages, so the list leaves out unchanged and skipped lines unless you ask for them.

The figures are the total, indexed, failed, in progress, unchanged and the words indexed. Whoever may see the resources reads this log, and its lines are kept with the resources.

Activity

Who changed what in the workspace: resources added, edited, re-indexed or deleted, site rules and syncs, assistants and widgets created, edited, paused or deleted, tags renamed or deleted, and members’ access changed.

Each line gives the actor (a member, an API key, or Lookio itself for a scheduled sync), the door used, the thing changed with its name at the time, and which fields changed. It never holds content: you see that an assistant’s context was edited, not what they said.

Only admins read the activity: in the app, or through a personal connection (the CLI’s lookio auth login, an MCP client) with the admin scope. An API key never can, as a key manages no people. It is kept a year.

Read the logs

# Where did the assistant fail this month?
curl "https://api.lookio.app/v1/logs/conversations?rating=down&from=2026-10-01" \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

# One conversation in full
curl https://api.lookio.app/v1/logs/conversations/CONVERSATION_ID \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

# The figures of the conversations
curl "https://api.lookio.app/v1/logs/conversations/stats?channel=widget,api" \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

# Questions the resources could not answer
curl "https://api.lookio.app/v1/logs/answers?result=no_answer" \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

# Indexings that failed
curl "https://api.lookio.app/v1/logs/indexing?status=failed" \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

# Who changed assistants through the CLI or MCP
curl "https://api.lookio.app/v1/logs/activity?target_type=assistant&origin=cli,mcp" \
  -H "Authorization: Bearer $LOOKIO_API_KEY"

for await (const chat of lookio.logs.conversations.iterate({ rating: "down" })) {
  console.log(chat.channel, chat.end_user, chat.title);
}
const full = await lookio.logs.conversations.get("CONVERSATION_ID");
const stats = await lookio.logs.conversations.stats({ from: "2026-10-01" });

const unanswered = await lookio.logs.answers.list({ result: "no_answer" });
const failed = await lookio.logs.indexing.list({ status: "failed" });
const changes = await lookio.logs.activity.list({ target_type: "assistant", origin: "cli,mcp" });

lookio logs conversations --rating down --from 2026-10-01
lookio logs conversations --stats --channel widget,api
lookio logs get CONVERSATION_ID
lookio logs answers --result no_answer
lookio logs indexing --status failed
lookio logs activity --target-type assistant --origin cli,mcp

The lists of answers, indexing and activity page with an opaque cursor: pass the next_cursor of a page back unchanged. The SDK iterators do it for you.

For an AI agent, the MCP tools are list_conversation_logs, get_conversation_log and get_conversation_log_stats for the conversations, list_answer_logs and get_answer_log_stats for the answers, list_indexing_logs and get_indexing_log_stats for the indexing, and list_activity_log for the activity. Their descriptions tell the model that the conversation log holds what people outside the workspace asked, and that a person’s own chats are read with list_conversations instead. See Standard tools.

Who can read the logs

• Conversations. A person needs the right to edit assistants, and sees only the conversations of the assistants they may use. A member without it gets permission_denied. An API key needs the assistants:write scope, the one that manages assistants and widgets, and sees the conversations of its own assistants, including those other keys started. The Ask questions preset does not include it: a key that only asks questions never reads other people’s conversations.
• Answers. The usage:read scope, with the visibility described in Answers. It is part of the Read only and Editor presets.
• Indexing. The resources:read scope.
• Activity. Admins, in the app or through a personal connection with the admin scope. Never an API key.

The endpoints are List the workspace’s conversation logs, Retrieve a logged conversation, Retrieve the figures of the conversation logs, List the answer logs, Retrieve the figures of the answer logs, List the indexing logs, Retrieve the figures of the indexing logs and List the workspace activity. A widget’s own list, List a widget’s conversations, is the conversation log filtered on that widget.

Privacy

• What people type can be personal. Read the conversations as you would any support inbox, and keep the keys and permissions that open them to the people who need them.
• The answer, indexing and activity logs hold no question, answer or content. They tell you what happened, not what was said.
• Send an opaque end_user, not an email address, so a log line does not identify anyone on its own.
• Send store: false for a question that must not be kept.
• Delete a conversation with Delete a conversation to remove it from the conversation log at once. Deleting a widget deletes its visitors’ conversations.