--- title: "Logs" description: "The four logs of a workspace, conversations, answers, indexing and activity, what each shows, who can read it, how long it is kept and how to filter it in the app, the API, the CLI, the SDK and MCP." canonical: "https://lookio.app/docs/platform/logs" updated: "2026-11-03" --- # 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. | Log | Answers the question | Needs | Kept | | ------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [Conversations](#conversations) | What did people ask, yourself included, and where did the assistant fail? | Your own chats: nothing. Widget, API key and MCP conversations: the right to edit assistants (API key: `assistants:write`) | Your chats: until you delete them. The others: 90 days after the last message | | [Answers](#answers) | Which answers did Lookio give, through what, and what did they cost? | `usage:read` | With the usage history | | [Indexing](#indexing) | Was my file, page or site read, and why did it fail? | `resources:read` | With the resources | | [Activity](#activity) | Who changed what, and through which door? | Admins (in the app, or a personal connection with `admin`) | A year | ## 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](/docs/widget/overview), 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](#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. | In the log | Not in the log | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Your own chats from the app (`chat`), for you only. | Another member's chat. It is personal: nobody else reads it, admins included. It is not in the API either. | | A visitor's conversation through a widget (`widget`). | A question sent with `store: false`. Nothing is kept. | | A conversation started with an API key through REST, the CLI or the SDK (`api`). | A conversation older than 90 days, or one that was deleted. | | A conversation started with an API key through the MCP server (`mcp`). | The app's own widget previews. | A widget, API key or MCP conversation is kept 90 days after its last message. See [Conversations and end users](/docs/platform/conversations-and-end-users#how-long-it-is-kept). 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. | Filter | Keeps | | -------------- | ------------------------------------------------------------------------------------------------------ | | `channel` | Only these channels, comma-separated: `widget`, `api`, `mcp` (and `chat` in the app, your own chats). | | `widget_id` | One widget's visitors. | | `api_key_id` | Conversations asked with one API key. | | `assistant_id` | Conversations with one assistant. | | `rating` | `down` (at least one thumbs down, where the assistant failed), `up`, `rated` (any thumb) or `unrated`. | | `end_user` | One person. | | `q` | Conversations with these words in the title or in any question or answer. | | `from`, `to` | Conversations with activity since a date, and conversations started before one. | 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. | Channel | Where the question came from | | ----------- | ----------------------------------------------------------------------------------------------- | | `chat` | A member, in the app's chat. | | `lookio_ai` | The in-app agent. | | `api` | An API key through REST, the CLI or the SDK. An answer sent with `store: false` shows here too. | | `mcp` | The MCP server. | | `widget` | A visitor of a widget. | 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. | Filter | Keeps | | ----------------------------------------- | -------------------------------------------------------------------------------- | | `channel` | Only these channels, comma-separated. | | `assistant_id`, `widget_id`, `api_key_id` | One assistant, one widget or one API key. | | `member_id` | One member's answers (admins). | | `result` | `answered`, or `no_answer` to find the questions the resources could not answer. | | `mode` | One query mode. | | `from`, `to` | A period. | 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. | Status | Meaning | | ---------------------- | -------------------------------------------------------------------- | | `queued`, `processing` | Not finished. | | `indexed` | Searchable now. | | `replaced` | Was indexed, then replaced by a newer indexing of the same document. | | `unchanged` | A sync re-read it and the text is the same. | | `skipped` | A newer indexing of the same document finished first. | | `failed` | It could not be read. The line says why. | 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. | Filter | Keeps | | ------------------- | ------------------------------------------------------------------------------- | | `resource_id` | One resource's indexings. For a site, all its pages. | | `status` | These statuses, comma-separated. `failed` finds what to retry. | | `source_type` | `file`, `url`, `site` or `text`. | | `q` | Words in the resource's title, the file's name, or the page's address or title. | | `include_unchanged` | Also the pages a sync re-read and found unchanged. | | `from`, `to` | Indexings started in a period. | 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. | Door (`origin`) | Meaning | | --------------- | ----------------------------------------------------------- | | `app` | Someone in the web app. | | `api` | An API key or a connection through the REST API or the SDK. | | `cli` | The `lookio` command. | | `mcp` | An MCP client. | | `agent` | Lookio AI, the in-app agent. | | `system` | Lookio itself, such as a scheduled sync. | | Filter | Keeps | | -------------------------- | ------------------------------------------------------------------------------------------- | | `actor_id` | What one member or API key did. | | `origin` | Only these doors, comma-separated. | | `target_type`, `target_id` | One kind of thing (`resource`, `assistant`, `widget`, `tag`, `member`), or one thing of it. | | `action` | An exact action such as `assistant.updated`, or every action on a kind such as `assistant`. | | `q` | Words in the name of what changed. | | `from`, `to` | A period. | 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 ```bash title="curl" # 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" ``` ```ts title="SDK" 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" }); ``` ```bash title="CLI" 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](/docs/mcp/standard-tools#logs). ## 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](#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](/docs/api/logs/list-log-conversations), [Retrieve a logged conversation](/docs/api/logs/get-log-conversation), [Retrieve the figures of the conversation logs](/docs/api/logs/get-log-conversation-stats), [List the answer logs](/docs/api/logs/list-log-answers), [Retrieve the figures of the answer logs](/docs/api/logs/get-log-answer-stats), [List the indexing logs](/docs/api/logs/list-log-indexing), [Retrieve the figures of the indexing logs](/docs/api/logs/get-log-indexing-stats) and [List the workspace activity](/docs/api/logs/list-log-activity). A widget's own list, [List a widget's conversations](/docs/api/widgets/list-widget-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](/docs/api/conversations/delete-conversation) to remove it from the conversation log at once. Deleting a widget deletes its visitors' conversations.