> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/agent-builder/deploy/whitelisted-domains.md).
# Whitelisted Domains
**Whitelisted Domains** is the allowlist of web origins where the agent's embedded widget is permitted to run. When a request reaches the platform from the widget, the platform checks the request's origin against this list; if it isn't on the list, the request is refused. The list is what prevents your agent — and its associated API quota and data — from being embedded on a site you didn't authorize.
Manage Agent → Whitelisted Domains
Reach this page from **Manage Agent → Whitelisted Domains** in the left navigation.
### The Domains list
The right pane has a single table titled `Domains`. Each row is one URL or domain pattern, with a trash-can delete icon on the right. A `+ Add New Domain` row sits at the bottom of the table for adding new entries.
The list is empty by default. An agent with an empty domains list typically rejects widget calls from every origin — the widget effectively can't run anywhere. Adding entries opens the agent up, origin by origin.
### Obligation
| Field | Obligation | Notes |
| ---------- | ----------------- | --------------------------------------- |
| Domain URL | Mandatory per row | An entry with no URL serves no purpose. |
| | | |
| | | |
> **Note — Depth gap** The accepted URL formats — wildcard support (`*.example.com`), protocol requirements (`https://` versus bare hostnames), port specifications — were not exercised during capture. Test additions match your intended origin before relying on the agent reaching production traffic.
### What gets checked
The list governs the **widget** integration described in Export and integrate. The widget runs in a web page, has an origin (the page's domain), and the platform checks that origin against this list on every call.
API and headless integrations are server-to-server — they don't have a web origin in the same sense. Those integrations are gated by the Authentication key alone.
### Working with the list
#### Adding an entry
Click `+ Add New Domain`. A new editable row appears with an empty input. Type the URL or domain, then click **Save** in the top-right of the section.
#### Removing an entry
Click the trash-can icon on the row. The row is removed from the list (after the **Save** click that commits the change).
#### Saving
The **Save** button in the top-right of the section activates once you've added, edited, or removed any row. Changes only take effect after saving.
### Recommended pattern
For each environment where the widget will be embedded, add the specific origin:
* `https://app.example.com` — production app
* `https://staging.example.com` — staging environment
* `http://localhost:3000` — local development (be ready to remove this before publishing the agent to production)
Avoid using one open entry like `*` (if the platform accepts it). The list's whole purpose is to constrain origins; an "allow everything" entry defeats it.
### Why this matters
A widget is a piece of frontend code that talks to your agent. The agent has access to whatever you've configured — connectors, knowledge, skills, the keys in Secrets & Variables — and a malicious page embedding the widget could send the agent inputs you'd rather it not see. The Whitelisted Domains list is the boundary that says "this agent runs here and nowhere else." Audit it the same way you'd audit a firewall rule: add origins deliberately, remove ones you no longer need, and never leave the list looser than it needs to be.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.uptiq.ai/agent-builder/deploy/whitelisted-domains.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.