Conversations and end users

Lookio keeps every answer from an API key, the CLI or the MCP server in a conversation. Send the next question with the conversation_id of the previous answer. Lookio reads the history itself.

This page is for products that show an assistant to their own users. A person’s chats in the app are personal. See Chat.

Continue a conversation

The first answer returns two ids. conversation_id continues the conversation. message_id identifies the answer. You need it to send a thumb.

# First question
curl https://api.lookio.app/v1/assistants/ASSISTANT_ID/query \
  -H "Authorization: Bearer $LOOKIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"question": "How much does the Pro plan cost?", "end_user": "user_42"}'

# The answer has "conversation_id": "CONVERSATION_ID" and "message_id": "MESSAGE_ID".
# Follow-up: only the new question.
curl https://api.lookio.app/v1/assistants/ASSISTANT_ID/query \
  -H "Authorization: Bearer $LOOKIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"question": "And for the annual plan?", "conversation_id": "CONVERSATION_ID", "end_user": "user_42"}'

const first = await lookio.assistants.ask("ASSISTANT_ID", {
  question: "How much does the Pro plan cost?",
  end_user: "user_42",
});
const followUp = await lookio.assistants.ask("ASSISTANT_ID", {
  question: "And for the annual plan?",
  conversationId: first.conversation_id!,
  end_user: "user_42",
});

lookio ask ASSISTANT_ID "How much does the Pro plan cost?" --end-user user_42
lookio ask ASSISTANT_ID "And for the annual plan?" --conversation CONVERSATION_ID --end-user user_42

The MCP tool ask_assistant takes the same conversation_id, end_user and store. The streamed answer returns both ids in its done event: see Streaming.

A conversation:

• belongs to the API key that started it. Another key gets resource_not_found, also in the same workspace.
• stays with one assistant. Another assistant with that conversation_id gets resource_not_found.
• uses the last six messages as context (three questions and their answers), like a chat in the app.

Two ways to keep a conversation

Sending both conversation_id and history fails with invalid_request.

Name the people who use your product with end_user

end_user is your own id for the person who asks, such as a user id of your product. It is optional.

• It is 1 to 200 characters: letters, digits and . _ @ : + -. Anything else fails with invalid_parameter.
• Use an opaque id such as user_42, not an email address. The id appears in the logs.
• It groups that person’s conversations. List them with GET /v1/conversations?end_user=user_42.
• It locks the conversation to that person. To continue, read, rename, delete or rate a conversation started with end_user: "user_42", a call must send the same end_user. Other calls get resource_not_found. So one of your users cannot open the conversation of another, even if an id leaks.
• A conversation started without end_user is reachable only by calls without end_user. Use one method for your whole product.

end_user and store are for API keys only. A person’s connection that sends them gets invalid_parameter.

Keep nothing with store false

Send store: false when Lookio must keep nothing. There is no conversation and no entry in the logs. conversation_id and message_id are null. The price is the same. For a follow-up, send the previous messages yourself in history.

You cannot send store: false with conversation_id.

How long it is kept

The plan sets how long a conversation stays readable, counted from its last message. A new message restarts the count.

Between the two, the conversation is locked. It stays in the lists with its channel, assistant, cost and dates, but its messages are hidden. A plan with a longer period makes it readable again. A member’s own chats in the app are never locked.

To delete a conversation earlier, call DELETE /v1/conversations/{conversation_id}. It also leaves the logs and their figures. To erase a user’s data on request, list their conversations with end_user and delete each one.

Who can read a kept conversation:

• you, with the API key that started it (the endpoints below);
• the people of the workspace who may read the logs.

Members’ own chats are never in the logs.

Read and tidy your key’s conversations

Each row has an MCP tool with the same job. See Standard tools. Each conversation has a channel: api for a key through REST, the CLI or the SDK, mcp for a key through the MCP server, personal for a person’s own chat. A key lists only its own conversations.

Errors you may meet