> For the complete documentation index, see [llms.txt](https://docs.eesel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eesel.ai/apis-and-developer-resources/network-access.md).

# Network Access

Connect your AI agent to any REST API with Network Access. Allow the domain, add the auth header, and your agent looks up live data when it answers.

Network Access lets your agent reach APIs you don't have a built-in integration for. You allow a domain, tell it which header to authenticate with, and your agent can then look up live data like orders, shipping status or inventory, and use it when it answers.

It is how your agent works with your own systems: an order database, a shipping tracker, an internal tool. The credentials stay in your settings and are attached to each request by eesel, so the AI never sees them.

<figure><img src="https://3732419023-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2xXO0947TYoPIhGoBgSE%2Fuploads%2Fgit-blob-d8c4892a8c1fe33f4621abd530165035bea8e7a9%2Fnetwork-access-settings.png?alt=media" alt="The Network Access section in agent settings with two allowlisted domains, and the note that credentials are stored as headers and never shown to the AI"><figcaption><p>Network Access in your agent's settings. Note the line at the top: credentials are stored as headers and never shown to the AI.</p></figcaption></figure>

## What you can do

* Fetch live data from any REST API (orders, customers, inventory, shipping, etc.)
* Make GET, POST, PATCH and DELETE requests to retrieve data or trigger actions
* Attach authentication headers (API keys, Bearer tokens, Basic auth) per domain
* Combine with any helpdesk so the agent responds with real-time data

{% hint style="success" %}
**Your teammate can walk you through this.** Describe the API you want it to reach and it will tell you exactly what to add, which domain to allow, and which header the API expects.

**Never paste an API key, token or password into the chat.** You don't need to, and you shouldn't. Your teammate will point you at the field in your settings where the value goes, and it never sees the value itself, only the name of the header. If it ever asks you for a secret in chat, don't give it one.
{% endhint %}

## Setting up Network Access

{% stepper %}
{% step %}

### Add the domain

Open your agent, go to the **Settings** tab, scroll to **Network Access**, and click **Add domain**. Enter the base domain of the API, like `api.yourservice.com`. Pasting a full URL works too; the hostname is taken from it.

<details>

<summary>Allowing all subdomains with a wildcard</summary>

Use `*.yourservice.com` to match `api.yourservice.com`, `store.yourservice.com`, and so on. The wildcard doesn't match the bare `yourservice.com` itself, so add that separately if you need it.

</details>
{% endstep %}

{% step %}

### Add the authentication header

Fill in the header name and value the API expects, then click **Save**. Header name and value must be filled in together; to allow a domain with no auth, leave both empty.

<details>

<summary>Bearer token</summary>

| Field        | Value                 |
| ------------ | --------------------- |
| Header name  | `Authorization`       |
| Header value | `Bearer YOUR_API_KEY` |

The word `Bearer` and the space after it are part of the value.

</details>

<details>

<summary>Basic auth</summary>

Basic Auth encodes your credentials as base64. Most APIs expect `username:password`, or `api_key:` with an empty password.

Generate the value (the trailing colon is required):

```bash
echo -n "YOUR_API_KEY:" | base64
```

| Field        | Value                        |
| ------------ | ---------------------------- |
| Header name  | `Authorization`              |
| Header value | `Basic <your base64 output>` |

</details>

<details>

<summary>Custom API key header</summary>

Some APIs use their own header name instead of `Authorization`:

| Field        | Value          |
| ------------ | -------------- |
| Header name  | `X-API-Key`    |
| Header value | `YOUR_API_KEY` |

</details>
{% endstep %}

{% step %}

### Tell your agent how to use it

All that's left is telling your agent what these API connections are for, and the easiest way is to just talk to it: describe the workflow you want ("when a customer asks about an order, look it up by order number and reply with the status and tracking"), and it writes the rule into its own [instructions](/instructions-and-memory/instructions-and-memory.md).

The same connections work everywhere your agent does: in [automations](/automations-and-schedules/automations-and-schedules.md), in [skills](/skills/skills.md), and in ad-hoc requests in chat. Auth headers are attached automatically from your policies, so credentials never appear in instructions.
{% endstep %}
{% endstepper %}

## Troubleshooting

<details>

<summary>"Header name and value need to be filled in together"</summary>

Both fields must be filled in before saving. If you want to allow a domain without any auth headers, leave both fields empty.

</details>

<details>

<summary>"Outbound request to 'api.example.com' is not allowed"</summary>

The domain isn't in your Network Access policies. Check that the policy holds the hostname exactly (`api.yourservice.com`, not a full URL with a path), and that you clicked **Save** after adding it.

</details>

<details>

<summary>The API returns 401 Unauthorized</summary>

For Basic Auth, make sure you ran `echo -n "key:" | base64` with the trailing colon. For Bearer tokens, the value must start with `Bearer` followed by a space. And check the key is still valid in the third-party dashboard.

</details>

## FAQ

<details>

<summary>Can my AI agent call an API that eesel has no integration for?</summary>

Yes. Allow the API's domain under **Network Access** in your agent's **Settings** tab, add the header it authenticates with, and your agent can call it. It can make GET, POST, PATCH and DELETE requests.

</details>

<details>

<summary>Does the AI see my API key?</summary>

No. Credentials are stored as headers and attached to each request automatically, so your agent only ever sees the name of the header, never its value, and credentials never appear in its instructions. Never paste a key into the chat.

</details>

<details>

<summary>Which authentication methods does Network Access support?</summary>

Any that goes in a header: a Bearer token, Basic auth, or a custom API key header such as `X-API-Key`. You can also allow a domain with no authentication.

</details>

<details>

<summary>Can my agent reach any website once Network Access is on?</summary>

No. Requests are restricted to the domains you have added. A request to anywhere else is refused with an "Outbound request ... is not allowed" error.

</details>

<details>

<summary>Can I allow every subdomain of an API?</summary>

Yes. Use a wildcard like `*.yourservice.com`. It does not match the bare `yourservice.com`, so add that separately if you need it.

</details>

## Related

* [Skills](/skills/skills.md) for the workflows that can use an API you have allowed here
* [Instructions and Memory](/instructions-and-memory/instructions-and-memory.md) for telling your agent when to make a request
* [The eesel CLI](/apis-and-developer-resources/cli.md) for managing agents and integrations from your terminal
* [Security and Privacy](/account/security-and-privacy.md) for how credentials are handled
* [Use eesel from Claude and other AI assistants](/apis-and-developer-resources/use-eesel-from-claude-and-other-assistants.md) and [Use eesel from ChatGPT](/apis-and-developer-resources/use-eesel-from-chatgpt.md)


---

# 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 following URL with the `ask` and `goal` query parameters:

```
GET https://docs.eesel.ai/apis-and-developer-resources/network-access.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

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.