> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/developer-guide/platform-api/safety/prompt-logs.md). # Prompt Logs Query LLM prompt logs for auditing and debugging agent conversations across a workspace. The Prompt Logs endpoint lets you retrieve captured LLM inputs and outputs from agent conversations, including available system prompts, conversation history, tool catalogs, model selection, and responses. Coverage and populated fields vary by prompt type and logging path. This is useful for auditing agent behavior, debugging unexpected responses, and understanding how context flows through multi-turn conversations. {% hint style="warning" %} **Access restriction**: Prompt log access requires an API key with the **admin** or **owner** role. Prompt logs contain full conversation history and tool I/O, which may include PHI. All reads are audit-logged. {% endhint %} ## List Prompt Logs {% openapi src="" path="/v1/{workspace\_id}/prompt-logs" method="get" %} {% endopenapi %} Returns available prompt log entries for the workspace, newest first. {% hint style="info" %} **Auto-applied time window**: When none of `conversation_id`, `call_sid`, `from_ts`, or `to_ts` is provided, the query is automatically capped to the last 7 days. The applied window is reported in the `applied_time_window_days` response field. {% endhint %} {% hint style="info" %} String fields such as `system_prompt`, `full_prompt`, and `llm_response` can be large. Do not assume a maximum length beyond limits published in the API schema. {% endhint %} ### Link a Prompt to Its Turn Each entry names the turn it was rendered for, so you can read a prompt beside the exchange it produced: * `turn_id` is the user exchange the prompt was rendered for, the same `turn_id` the conversation's [turns](/developer-guide/platform-api/conversations.md#list-conversation-turns) carry. Every prompt in one exchange shares it, tool rounds included, so join prompt logs to turns on it. It is null before the conversation's first user message. * `engine_turn_id` names the engine turn that rendered the prompt: the user turn, or one tool round within it, so each tool round's prompt has its own. Where a message in conversation detail has an `engine_turn_id`, it names the same engine turn. * `tool_names` lists the tools the agent's state offered when the prompt rendered, and `llm_model` is the model the prompt was sent to. * `turn_index` counts prompts as they are rendered and can repeat within a conversation, so it doesn't identify a turn. Join on `turn_id` or `engine_turn_id` instead. Either id is null when the entry didn't record one. ### Pagination The endpoint uses peek-ahead pagination. When `has_more` is true, pass the value of `next_offset` as the `offset` parameter on the next request to retrieve the next page. ### Error Responses | Status | Description | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `400 Bad Request` | Both `conversation_id` and `call_sid` were supplied (they are mutually exclusive) | | `403 Forbidden` | Caller does not have admin or owner role | | `404 Not Found` | `conversation_id` does not match a conversation in this workspace, or names a voice call that has no conversation record; filter that call's logs by `call_sid` | | `503 Service Unavailable` | Prompt log data source is unavailable | ### Example ```bash curl -X GET \ 'https://platform.api-us.concurrence.com/v1/{workspace_id}/prompt-logs?call_sid=CA1234567890&limit=10' \ -H 'Authorization: Bearer {api_key}' ``` ```json { "items": [ { "event_id": "evt_abc123", "call_sid": "CA1234567890", "workspace_id": "ws_xyz", "effective_at": "2026-07-15T14:30:00Z", "prompt_type": "engage_user", "turn_id": "6f1c2a9e-4b7d-5e3a-9c1f-2d8b7a6e5f40", "engine_turn_id": "4c0e9b2a7d1f4e6b8a3c5d7e9f1a2b3c", "turn_index": 3, "system_prompt": "You are a helpful healthcare scheduling assistant...", "history": [ {"role": "user", "content": "I need to reschedule my appointment"}, {"role": "assistant", "content": "I can help with that..."} ], "llm_model": "model-v2", "llm_response": "Let me look up your upcoming appointments...", "state_name": "scheduling", "tool_names": ["search_appointments", "reschedule_appointment"], "has_tools": true, "data_parse_error": false } ], "count": 1, "has_more": false, "next_offset": null, "applied_time_window_days": null } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/developer-guide/platform-api/safety/prompt-logs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.