> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bigdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect chat and document viewer on one page

> Use a single BigdataWidgetManager so the chat and document viewer share a theme, coordinate on opendocument events, and open citations in the viewer without your own bus.

When you embed the [chat widget](/widgets/chatbox-widget) and [document viewer widget](/widgets/document-viewer-widget) on the **same page**, you can pass both widgets a single **`BigdataWidgetManager`**. The manager gives you one place for **base theming** and a **shared event path** so when the chat raises **`opendocument`** (for example from a citation), the document viewer can show that document **without** wiring your own pub/sub or global state.

## Connecting Bigdata widgets

Load **both** widget script tags first so **`BigdataAgent`** and **`BigdataDocumentViewer`** are defined. Then create **one** **`BigdataWidgetManager`** and pass it in each widget’s config along with **distinct** **`instanceId`** values.

<Note>
  **`BigdataWidgetManager`** may be exposed by more than one widget bundle (for example the chat and document viewer). In this guide we use the canonical UMD export on **`BigdataDocumentViewer`**: **`BigdataDocumentViewer.BigdataWidgetManager`**. Use either export consistently-don’t mix them in the same page’s code.
</Note>

<Note>
  The proxy, API keys, and CORS story are unchanged. Each widget may still use its own **`proxyUrl`**; see the two embed guides for your backend and [Research Agent API](/api-reference/research-agent/research-agent) and document **Content** flows.
</Note>

### How a citation reaches the document viewer

**Citation flow** - the chat emits `opendocument` on the shared `BigdataWidgetManager`; the manager delivers it to the document viewer, which opens the file.

```mermaid theme={null}
sequenceDiagram
  participant C as Chat widget
  participant M as BigdataWidgetManager
  participant D as Document viewer
  C->>M: emit("opendocument", data)
  M->>D: listen: forward to D instance
  D->>D: open document in viewer
```

Event payloads in handlers include **`instanceName`**, **`timestamp`**, and **`data`**. The **`data`** object matches the [chat](/widgets/chatbox-widget#instance-lifecycle-and-events) and [document viewer](/widgets/document-viewer-widget#instance-lifecycle-and-events) event tables.

### Minimal wiring (concept)

1. **Create a manager** -

```javascript theme={null}
new BigdataDocumentViewer.BigdataWidgetManager(
  { theme: { /* optional, shared base */ } }
)
```

The class is exposed on the UMD object **`BigdataDocumentViewer`**; see the **Global API: `BigdataDocumentViewer`** section in the [document viewer](/widgets/document-viewer-widget) page.

2. **Initialize the document viewer** -

```javascript theme={null}
new BigdataDocumentViewer.BigdataDocumentWidget({
  container,
  proxyUrl,
  manager,
  instanceId: "my-document",
  /* openDocument, getHeaders, theme, … */
})
```

3. **Initialize the chat** -

```javascript theme={null}
new BigdataAgent.BigdataChatWidget(
  {
    container,
    proxyUrl,
    manager,
    instanceId: "my-chat",
    /* config, theme, … */
  }
)
```

Use a **string** `instanceId` for each that is **unique** on the page. If you omit it, the defaults are **`"chat"`** and **`"document"`**, which is fine for a **single** pair. Add explicit ids if you add more than one of either widget or want clearer logs and listeners.

Example shape (placeholders; align script URLs and options with the two quickstarts):

```html theme={null}
<div id="document-widget" style="min-height: 400px; width: 100%;"></div>

<div id="chat-widget" style="min-height: 520px; width: 100%; margin-top: 1rem;"></div>

<script>
  (function() {
    var manager = new BigdataDocumentViewer.BigdataWidgetManager({
      theme: { preset: "auto" },
    });

    new BigdataDocumentViewer.BigdataDocumentWidget({
      container: "#document-widget",
      proxyUrl: "https://your.api.example.com/document-proxy",
      manager: manager,
      instanceId: "my-document",
    });

    new BigdataAgent.BigdataChatWidget({
      container: "#chat-widget",
      proxyUrl: "https://your.api.example.com/chat-proxy",
      manager: manager,
      instanceId: "my-chat",
    });
  })();
</script>
```

(Requires both widget bundles loaded before this inline block.)

## Sharing configuration through the manager

* **Base theme** - The manager holds an optional **shared `baseTheme`**. The widgets merge their own `theme` on top, same as in [Multiple widgets and shared theming](/widgets/chatbox-widget#multiple-widgets-and-shared-theming) (chat) and the [document viewer’s matching section](/widgets/document-viewer-widget#multiple-widgets-and-shared-theming).

* **Event bus** - Internally, when one widget **emits** an event, the manager **broadcasts** it to every instance registered on that manager. The document viewer listens for **`opendocument`** to switch what is on screen. The chat emits that event when a user follows a **Bigdata** citation, so a shared manager is how those two stay in sync on one page.

### Events you lean on for coordination

| Event              | Role when connecting the two widgets                                                                                                                                                                                                                                                                                                                                          |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`opendocument`** | Chat **emits** with **`data`**: at least `documentId`, `isPrivate`; optional **match** metadata for highlights when your integration supplies it. The document viewer **handles** the event to show the file. **Full field lists:** [Chat](/widgets/chatbox-widget#instance-lifecycle-and-events) · [Document](/widgets/document-viewer-widget#instance-lifecycle-and-events) |
| **`openlink`**     | For opening an external **URL** instead of in-product document navigation; [chat](/widgets/chatbox-widget#instance-lifecycle-and-events) describes the `data` shape.                                                                                                                                                                                                          |
| **`ready`**        | Fires with `{ widgetName }` after the widget is mounted.                                                                                                                                                                                                                                                                                                                      |

You can still use **`addListener` / `removeListener`** (or the chat’s **`emit`** for **advanced** flows such as a host-triggered **send** - see the chat page) on the **returned instances** the same as on a single widget.

## Build your own connection

The chat can register **`onDocumentClick`** and **`onLinkClick`** in **`config`** (or attach equivalent listeners on the chat **instance**). These are **shortcuts for observing** user interactions (analytics, logging, or side effects) and **do not override** the default built-in behavior by themselves. The usual **“chat + document on one page”** path is the **shared** **`manager`**: the chat **emits**, the document viewer is already listening through the same manager, so you do not need extra glue for the default “open in viewer” experience.

## Further reading

* [Chat widget](/widgets/chatbox-widget) - `proxyUrl`, `config`, themes, and events.
* [Document viewer](/widgets/document-viewer-widget) - `openDocument` shape, proxy contract, and events.
* [Support](/support) - for WordPress, enterprise questions, or integration help.