[PR #1427] [MERGED] docs: document API key enablement, server-side limits, cleanup and processing status on the knowledge base sync page #1392

New issue

Closed

opened 2026-10-18 14:19:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:19:21 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/docs/pull/1427
Author: @silentoplayz
Created: 9/18/2026
Status: ✅ Merged
Merged: 9/26/2026
Merged by: @silentoplayz

Base: main ← Head: docs/kb-sync-page

📝 Commits (1)

8084cb5 docs: document API key enablement, server-side limits, cleanup and processing status on the knowledge base sync page

📊 Changes

1 file changed (+8 additions, -6 deletions)

View changed files

📝 docs/ecosystem/knowledge-base-sync/index.md (+8 -6)

📄 Description

Summary

I compared the knowledge base sync page with the knowledge and files routers and the API key checks.

The endpoints are named in full (POST /api/v1/knowledge/{id}/sync/diff and .../sync/cleanup), and the manifest entry carries a size field as well.
Cleanup deletes a stale file's record and bytes. It keeps them when ENABLE_KNOWLEDGE_FILE_RETENTION is on, when the file is linked elsewhere, or when the caller is neither owner nor admin. A file with no stored hash is re-uploaded once on the first sync.
The server enforces its own upload limits (RAG_FILE_MAX_SIZE answered with HTTP 413, RAG_ALLOWED_FILE_EXTENSIONS with HTTP 400) regardless of oikb's max-size.
Processing runs in the background and GET /api/v1/files/{id}/process/status reports completion.
API keys are off by default and gated by a permission. An HTTP 403 has four causes, including endpoint restrictions that must allow /api/v1/knowledge and /api/v1/files, and missing write access to the Knowledge Base.

None.

Checklist

I have reviewed the relevant documentation and matched the existing style.
This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

Sources on dev: routers/knowledge.py (FileManifestEntry, the sync routes, cleanup), routers/files.py (size and extension checks, process/status), config.py (ENABLE_API_KEYS, ENABLE_API_KEYS_ENDPOINT_RESTRICTIONS, API_KEYS_ALLOWED_ENDPOINTS), and utils/auth.py. oikb's own flags are unchanged.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/docs/pull/1427 **Author:** [@silentoplayz](https://github.com/silentoplayz) **Created:** 9/18/2026 **Status:** ✅ Merged **Merged:** 9/26/2026 **Merged by:** [@silentoplayz](https://github.com/silentoplayz) **Base:** `main` ← **Head:** `docs/kb-sync-page` --- ### 📝 Commits (1) - [`8084cb5`](https://github.com/open-webui/docs/commit/8084cb514182275db71e78d7d1389206a6ddb10c) docs: document API key enablement, server-side limits, cleanup and processing status on the knowledge base sync page ### 📊 Changes **1 file changed** (+8 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `docs/ecosystem/knowledge-base-sync/index.md` (+8 -6) </details> ### 📄 Description ## Summary I compared the knowledge base sync page with the knowledge and files routers and the API key checks. - The endpoints are named in full (`POST /api/v1/knowledge/{id}/sync/diff` and `.../sync/cleanup`), and the manifest entry carries a `size` field as well. - Cleanup deletes a stale file's record and bytes. It keeps them when `ENABLE_KNOWLEDGE_FILE_RETENTION` is on, when the file is linked elsewhere, or when the caller is neither owner nor admin. A file with no stored hash is re-uploaded once on the first sync. - The server enforces its own upload limits (`RAG_FILE_MAX_SIZE` answered with HTTP 413, `RAG_ALLOWED_FILE_EXTENSIONS` with HTTP 400) regardless of oikb's `max-size`. - Processing runs in the background and `GET /api/v1/files/{id}/process/status` reports completion. - API keys are off by default and gated by a permission. An HTTP 403 has four causes, including endpoint restrictions that must allow `/api/v1/knowledge` and `/api/v1/files`, and missing write access to the Knowledge Base. ## Related issue or discussion None. ## Checklist - [x] I have reviewed the relevant documentation and matched the existing style. - [x] This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility. - [x] I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories. ## Notes for reviewers Sources on `dev`: `routers/knowledge.py` (`FileManifestEntry`, the sync routes, cleanup), `routers/files.py` (size and extension checks, `process/status`), `config.py` (`ENABLE_API_KEYS`, `ENABLE_API_KEYS_ENDPOINT_RESTRICTIONS`, `API_KEYS_ALLOWED_ENDPOINTS`), and `utils/auth.py`. oikb's own flags are unchanged. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 14:19:21 +00:00