I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
Many features are conditionally rendered by validating user enabled features or global config, but some of these are fetched from the backend regardless of permissions. This produces http errors which are avoidable. These request cause, although small, load on the backend, and are additionally then logged as failed requests in Open Telemetry, causing noise.
Calls where this is the case (when that feature is disabled):
Channels: Are called onMount and cause an 401 each load
API Keys: Are called when users navigate to Settings > Account and causes a 404 each time
Desired Solution you'd like
If a feature is deemed unavailable, and the frontend does not render the components, don't try to fetch the data for the component. No changes of backend validation needed.
Alternatives Considered
No response
Additional Context
No response
Originally created by @rozatoo on GitHub (Dec 15, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19967
Originally assigned to: @Classic298 on GitHub.
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
Many features are conditionally rendered by validating user enabled features or global config, but some of these are fetched from the backend regardless of permissions. This produces http errors which are avoidable. These request cause, although small, load on the backend, and are additionally then logged as failed requests in Open Telemetry, causing noise.
Calls where this is the case (when that feature is disabled):
- **Channels:** Are called onMount and cause an 401 each load
- **API Keys**: Are called when users navigate to Settings > Account and causes a 404 each time
### Desired Solution you'd like
If a feature is deemed unavailable, and the frontend does not render the components, don't try to fetch the data for the component. No changes of backend validation needed.
### Alternatives Considered
_No response_
### Additional Context
_No response_
@owui-terminator[bot] commented on GitHub (Dec 15, 2025):
🔍Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#19908feat: Supports OpenAI-Response format API and related parameters by daxiass • Dec 12, 2025
💡Tips:
If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
If you found a solution in any of these issues, please share it here to help others
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
<!-- gh-comment-id:3655862886 -->
@owui-terminator[bot] commented on GitHub (Dec 15, 2025):
🔍 **Similar Issues Found**
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
1. [#19908](https://github.com/open-webui/open-webui/issues/19908) **feat: Supports OpenAI-Response format API and related parameters**
*by daxiass • Dec 12, 2025*
---
💡 **Tips:**
- If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
- If you found a solution in any of these issues, please share it here to help others
*This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
I think it does make sense from a performance/consistency standpoint.
If you plan on doing this then keep the PRs atomic, minimal and focused to one aspect ideally to make them easier mergable
<!-- gh-comment-id:3666933897 -->
@Classic298 commented on GitHub (Dec 17, 2025):
@rozatoo
So i am not tim, but:
I think it does make sense from a performance/consistency standpoint.
If you plan on doing this then keep the PRs atomic, minimal and focused to one aspect ideally to make them easier mergable
Yes, this seems like it would be wanted. Aligning the fetching logic with the rendering logic to respect the feature flags and permissions is a great hygiene and performance improvement.
I checked the code and confirmed that getAPIKey in src/lib/components/chat/Settings/Account.svelte and initChannels in Sidebar.svelte are indeed called unconditionally in onMount, supporting your observation. Wrapping these in the same $config.features... checks used for the UI would be perfect.
Please feel free to open a PR for this.
<!-- gh-comment-id:3672231393 -->
@silentoplayz commented on GitHub (Dec 18, 2025):
> hi [@silentoplayz](https://github.com/silentoplayz), is this wanted? I could PR it?
Yes, this seems like it would be wanted. Aligning the fetching logic with the rendering logic to respect the feature flags and permissions is a great hygiene and performance improvement.
I checked the code and confirmed that `getAPIKey` in `src/lib/components/chat/Settings/Account.svelte` and `initChannels` in `Sidebar.svelte` are indeed called unconditionally in `onMount`, supporting your observation. Wrapping these in the same `$config.features...` checks used for the UI would be perfect.
Please feel free to open a PR for this.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rozatoo on GitHub (Dec 15, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19967
Originally assigned to: @Classic298 on GitHub.
Check Existing Issues
Verify Feature Scope
Problem Description
Many features are conditionally rendered by validating user enabled features or global config, but some of these are fetched from the backend regardless of permissions. This produces http errors which are avoidable. These request cause, although small, load on the backend, and are additionally then logged as failed requests in Open Telemetry, causing noise.
Calls where this is the case (when that feature is disabled):
Desired Solution you'd like
If a feature is deemed unavailable, and the frontend does not render the components, don't try to fetch the data for the component. No changes of backend validation needed.
Alternatives Considered
No response
Additional Context
No response
@owui-terminator[bot] commented on GitHub (Dec 15, 2025):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
by daxiass • Dec 12, 2025
💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@rozatoo commented on GitHub (Dec 17, 2025):
hi @silentoplayz, is this wanted? I could PR it?
@Classic298 commented on GitHub (Dec 17, 2025):
@rozatoo
So i am not tim, but:
I think it does make sense from a performance/consistency standpoint.
If you plan on doing this then keep the PRs atomic, minimal and focused to one aspect ideally to make them easier mergable
@silentoplayz commented on GitHub (Dec 18, 2025):
Yes, this seems like it would be wanted. Aligning the fetching logic with the rendering logic to respect the feature flags and permissions is a great hygiene and performance improvement.
I checked the code and confirmed that
getAPIKeyinsrc/lib/components/chat/Settings/Account.svelteandinitChannelsinSidebar.svelteare indeed called unconditionally inonMount, supporting your observation. Wrapping these in the same$config.features...checks used for the UI would be perfect.Please feel free to open a PR for this.
@Classic298 commented on GitHub (Dec 19, 2025):
I'll attempt it
@Classic298 commented on GitHub (Dec 20, 2025):
Fixed in dev