diff --git a/docs/content/Deploying/DocsGPT-Settings.mdx b/docs/content/Deploying/DocsGPT-Settings.mdx
index 160327df..42234d92 100644
--- a/docs/content/Deploying/DocsGPT-Settings.mdx
+++ b/docs/content/Deploying/DocsGPT-Settings.mdx
@@ -438,6 +438,37 @@ See [Access Control, Roles & Teams](/Deploying/Access-Control) for the full mode
The realtime notifications channel has its own settings — see [Realtime Events & Notifications](/Agents/notifications) (`ENABLE_SSE_PUSH`, `EVENTS_STREAM_MAXLEN`, `SSE_MAX_CONCURRENT_PER_USER`, and related).
+## Vector indexes on pgvector
+
+DocsGPT does **not** create a vector index on the `documents` table, and for
+most deployments it should not have one. Exact search is correct and fast well
+past the size most corpora reach, and searches are filtered to a single source
+(`WHERE source_id = ...`) — a filter an approximate index applies only *after*
+picking its candidates.
+
+That combination is what makes a badly-sized index dangerous rather than merely
+slow: the index picks candidates from the whole table, the source filter
+discards them, and the query returns **too few rows or none at all**, silently.
+The model then answers as if the source were empty.
+
+If you have an existing `documents_embedding_idx` from an older version and
+your corpus is small (roughly under 50k vectors), drop it:
+
+```sql
+DROP INDEX IF EXISTS documents_embedding_idx;
+```
+
+DocsGPT still works with one in place — it raises `ivfflat.probes` to
+`sqrt(lists)` automatically and falls back to an exact search whenever an
+indexed search returns fewer rows than the source actually holds. You can pin
+probes explicitly with `PGVECTOR_IVFFLAT_PROBES`.
+
+Only add an index once a corpus is genuinely large, size it to the data you
+actually have (IVFFlat's `lists` guidance is roughly `rows / 1000`), and build
+it **after** the data is loaded — IVFFlat computes its cluster centroids at
+build time, so an index built on an empty table gets random centroids and never
+recovers.
+
## Exploring More Settings
These are just the basic settings to get you started. The `settings.py` file contains many more advanced options that you can explore to further customize DocsGPT, such as:
diff --git a/docs/content/Extensions/chat-widget.mdx b/docs/content/Extensions/chat-widget.mdx
index 5eae2fc9..5fdf2157 100644
--- a/docs/content/Extensions/chat-widget.mdx
+++ b/docs/content/Extensions/chat-widget.mdx
@@ -2,7 +2,7 @@
title: Integrate DocsGPT Chat Widget into Your Web Application
description: Embed the DocsGPT Widget in your React, HTML, or Nextra projects to provide AI-powered chat functionality to your users.
---
-import { Tabs } from 'nextra/components'
+import { Callout, Tabs } from 'nextra/components'
# Integrating DocsGPT Chat Widget
@@ -32,12 +32,21 @@ In your React component file, import the `DocsGPTWidget` component:
import { DocsGPTWidget } from "docsgpt";
```
+
+ **Which `apiHost`?** It is the URL of the DocsGPT **API**, not the app you log
+ into. For DocsGPT Cloud that is `https://gptcloud.arc53.com` — which is also the widget's
+ built-in default, so you can omit the prop entirely. Self-hosting? Use your
+ own API URL (`http://localhost:7091` by default), not the frontend URL. A
+ `Network Error` or a CORS message in the console almost always means this is
+ pointing at the frontend instead of the API.
+
+
Now, you can embed the widget within your React component's JSX:
```jsx
` block, use the `renderDocsGPTWidget` functio