mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 02:48:13 -05:00
[GH-ISSUE #15329] feat: Store API Requests in chat Table Along with Web Interface Requests #33061
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#33061
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nsa09-nsa09 on GitHub (Jun 26, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15329
Check Existing Issues
Problem Description
Current Behavior
Currently, Open WebUI only stores chat interactions in the chat table of the SQLite database (webui.db) when they are initiated through the web interface. Requests made through the API endpoints are not recorded in this table, making it impossible to have a unified history of all conversations.
Desired Behavior
I would like to request a feature that would store API requests in the same chat table as web interface requests. This would provide several benefits:
Unified conversation history across all interaction methods
Consistent user experience when reviewing past conversations
Better integration between API and web interface workflows
Ability to view API-initiated conversations in the web UI
Technical Details
While the recent audit logging feature (PR #10436) provides a way to log API requests to an audit.log file, this doesn't integrate with the existing chat history system. Ideally, the same mechanism that stores web interface conversations in the chat table should be applied to API requests.
The implementation could:
Intercept API requests to chat endpoints
Format the data in the same structure used by web interface requests
Insert records into the chat table with appropriate metadata
Use Case
I'm using Open WebUI with external applications that communicate via the API. Currently, these conversations are "invisible" in the web interface, which creates a disconnected experience when switching between API and web interface usage.
Additional Context
I've verified that API requests are properly processed but not stored in the database by examining the webui.db file after making API calls. The chat table only contains entries from web interface interactions.
Thank you for considering this feature request!
Feedback submitted
Desired Solution you'd like
Desired Solution
I would like to see an implementation that:
Captures all API requests to chat endpoints (e.g., /api/chat, /api/generate, etc.)
Processes these requests to extract the user's prompt/message and the model's response
Creates entries in the chat table with the same structure as those created by the web interface
Associates these entries with a default or configurable user ID (for API authentication scenarios)
Makes these conversations visible and accessible in the web interface under chat history
Optionally, adds a flag or indicator to distinguish API-initiated conversations from web interface ones
Ideally, this would be configurable via an environment variable (e.g., STORE_API_CHATS=true) to maintain backward compatibility and allow users to disable this feature if desired for performance reasons.
Alternatives Considered
No response
Additional Context
No response
@Classic298 commented on GitHub (Jun 26, 2025):
Um sorry for asking.. but how does storing every single API request enhance the integration between the API and the web interface, or making the user experience when reviewing old conversations more consistent? I have never had consistency issues. And what do you mean by unifying the conversation history?
What?
Also the sheer amount of extra data this will take up to store every single API request, let alone the performance deficiencies this will introduce - why is this needed?
//EDIT: you mean manual /api/v1/chat/completions requests? You can store them into the chat table if you call chat/completed afterwards with the response data of the first request. This will store them into the database and create a visual chat for that user. Why would there be a need for a hardcoded feature when you can achieve this with just API Calls?
@nsa09-nsa09 commented on GitHub (Jun 26, 2025):
@Classic298 hello!
Yes, I'm referring to manual
/api/v1/chat/completionsrequests. The issue is that these requests currently don't get recorded in the SQLchattable inwebui.db, which creates a gap in conversation tracking.My specific use case: I'm running Open WebUI in production, and I need to monitor and review all user interactions - both from the web interface and direct API calls. Currently, when users make direct API requests, these conversations are "invisible" in the admin interface, making it difficult to:
Track user activity comprehensively
Debug issues reported by users who used the API
Maintain audit trails for compliance purposes
Provide support when users reference conversations that only exist via API
@Classic298 commented on GitHub (Jun 26, 2025):
@nsa09-nsa09 To track user activity comprehensively I'd suggest using a Filter (where in the inlet() of the filter, you store every request to disk or database). Alternatively, you can use LiteLLM as the proxy for your LLM integrations and in LiteLLM use a custom callback or third party integrations to extensive tracking.
When calling the API, you need to also call the "completed" endpoint with the prior response to STORE the request as a new chat.
The fact that the /completions endpoint does not store it to the database is intended, and expected.
I don't think this behaviour will be changed, and I am not sure Tim would be fond of the idea of introducing a new feature just to cover your very specific usecase of always storing all requests that call the completions endpoint.
Usually, if something can be done with functions, filters or otherwise (easily) then there is no point to introduce a new feature into open webui itself.
@nsa09-nsa09 commented on GitHub (Jun 26, 2025):
@Classic298 Thank you for your detailed response! What do you think about adding a simple configuration option like TRACK_API_REQUESTS=true as an environment variable?
This would provide an easy way to enable API request tracking for users who need it (like in my compliance/monitoring use case), while keeping it disabled by default to avoid performance issues for regular users.
If you don't think this is a strong enough argument for adding to the core codebase, I'll implement it using the inlet() filter approach you suggested. Thanks for your help!