> 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.