> For the complete documentation index, see [llms.txt](https://docs.toolregistry.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolregistry.ai/concepts/integrations/endpoint-controls.md).

# Endpoint Controls

Deterministic, policy-enforced controls that define exactly **which endpoints/tools are allowed** for a given integration. Controls apply **at plan time** and are **hard-enforced at execution**.

* **Allow-list only**: there is **no block list**. Endpoints are **disabled by default** until you explicitly enable them.
* **Precedence**: Deterministic allow-list **>** Agent Instructions **>** Intent/Context hints. (The last two are probabilistic guidance.)

### What “Enabled” vs “Disabled” means

* **Enabled** — The planner may include the endpoint; the executor will permit the call.
* **Disabled (default)** — The endpoint is excluded from plans. If a call is attempted at execution time, it is blocked with a policy error and surfaced in events/SSE.

> Deterministic policy is the **ground truth**. The agent cannot route around it.

### Where to configure (UI)

**Integration → Integration Endpoints** tab:

* **Import OpenAPI** (`.json`/`.yaml`) to populate the table.
* **Search path** to filter rows (e.g., `/PublicHolidays`).
* **Method filter** to narrow the list (All, GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS).
* **Active** checkbox per row enables that (method, path) pair.
* **Select All** to enable everything currently filtered (use sparingly).
* **Save** to persist. Changes take effect for newly created plans immediately; execution always re-checks policy.

**Columns**

* **Active** (checkbox), **Path** (e.g., `/PublicHolidaysByDate`), **Method** (e.g., `GET`), **Source** (e.g., `api`), **Description** (from spec if available), **Updated At** (last change/import).

### Deterministic vs probabilistic inputs (and why you care)

* **Deterministic (hard)** — This allow-list. Exact, enforced at both plan and execution.
* **Probabilistic (soft)**
  * **Intent & Context** — Hints like “use Pipedrive to schedule…”; helpful, not binding.
  * **Agent Instructions** — Strong steering (“prefer read-only”; “avoid deletes”), still non-binding.

Deterministic settings win every time. Use them to reduce search space (faster/cheaper) and to prevent unsafe actions.

### Operational guidance

* **Default-deny** naturally: endpoints are off until you turn them on.
* **Enable narrowly**: only the (method, path) pairs you truly need.
* **Writes need scrutiny**: for POST/PUT/PATCH/DELETE, enable only what’s required and run with `approvalStrategy: ON_TOOL_CALL` at **run level.**
* **Spec imports**: when you re-import an OpenAPI file, treat it like a deployment. Newly discovered endpoints should remain disabled until reviewed.
* **Naming**: the identity is `(method, path)`. If `GET /reports` is enabled, `POST /reports` is **not** enabled unless you check it explicitly.

### Examples

<figure><img src="/files/Xu6XGxD6A6qS9BDAqSty" alt=""><figcaption></figcaption></figure>

**Open Holidays**&#x20;

* ✅ `GET /Countries`, `GET /Languages`, `GET /PublicHolidays`, `GET /PublicHolidaysByDate`
* (Leave any `POST/PUT/DELETE` rows **unchecked** unless you truly need them.)

**Pipedrive (CRM)**

* ✅ `POST /activities`, `PUT /deals/{id}` (only if required)
* 🔲 `DELETE /deals/{id}` (keep disabled unless you have a strong, audited use case)
* Run destructive operations with `approvalStrategy: ON_TOOL_CALL`.

#### Illustrative configuration (conceptual)

```
allowed_endpoints:
  - GET /PublicHolidays
  - GET /PublicHolidaysByDate
  - POST /activities
  - PUT /deals/{id}
# there is no deny list; anything not listed remains disabled
```

### Planner & Executor Behavior

* **Plan stage** - The planner filters candidate tool calls to only those endpoints explicitly enabled in the allow-list. Disabled endpoints are ignored.
* **Execution stage** - The executor enforces the same allow-list. Only enabled endpoints can be invoked; any attempt to use a disabled one is blocked with a policy error.

### Troubleshooting

* **“The plan never picks endpoint X.”**\
  It isn’t enabled, or the **method** differs. Enable the exact (method, path) and Save.
* **“Run failed with a policy error.”**\
  A disabled endpoint was attempted. Check **Integration Endpoints** and re-enable if appropriate; then start a new run.
* **“Planning is slow or scattered.”**\
  Tighten the allow-list. Smaller surface → faster, more accurate planning.

### Best practices

* Keep your allow-list minimal and explicit.
* Treat changes like deployments (review → stage → roll out).
* For write operations, combine a narrow allow-list with `approvalStrategy: ON_TOOL_CALL` at run level.
* Use Agent Instructions and Context to guide the model, but rely on the allow-list for guarantees.


---

# 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:

```
GET https://docs.toolregistry.ai/concepts/integrations/endpoint-controls.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.