> For the complete documentation index, see [llms.txt](https://docs.frends.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.frends.com/reference/administration/environments-and-agent-groups/agents-and-api-gateways.md).

# Agents & API Gateways

The runtime components of Frends.

Agents and API Gateways represent the fundamental worker and routing instances that execute integration workloads and manage API traffic in Frends.

## What are Agents and API Gateways?

Within the Frends execution architecture, Agents and API Gateways operate as individual worker nodes assigned to an Agent Group, executing the runtime operations managed centrally by the Frends Control Panel. While both component types share identical administration interfaces, configuration options, and event monitoring tools, they fulfill distinct architectural roles in an enterprise integration topology.

### Agents

An Agent is a full-featured worker node designed for executing backend integration Processes. Agents listen to scheduled, conditional, and message-based Triggers, execute sequential Tasks, handle data transformations, and orchestrate communication with internal and external enterprise systems. In clustered configurations, multiple Agents within the same Agent Group share processing queues and database state to balance execution workloads and deliver automatic high availability.

### API Gateways

An API Gateway is a specialized instance designed primarily for managing incoming HTTP and REST API traffic. API Gateways receive client requests, terminate TLS connections, enforce authentication and rate limiting policies, and route traffic to backend Agents or external microservices. By deploying API Gateways in network perimeter zones such as DMZs, organizations securely expose public endpoints while keeping core integration Agents and sensitive business databases isolated inside internal private networks.

## Agent and API Gateway management

The management interface for Agents and API Gateways in the Frends Control Panel provides administrative tools for configuring instance connectivity, reviewing runtime event streams, and inspecting active Trigger endpoints.

Administrators access two primary views for each instance: the configuration view used during provisioning and maintenance, and the operational monitoring view used for inspecting live agent health, execution events, and Trigger routes.

## Usage

Managing Agents and API Gateways is performed through the Environments view under the Administration menu of the Frends Control Panel.

### Accessing Agent and API Gateway views

To access an existing instance, open the `Administration` dropdown from the main navigation bar and select `Environments`. In the left panel, expand the target Environment and select the appropriate Agent Group. Within the main panel, locate the `Agents` or `API Gateways` section and select an instance card to open its operational monitoring view.&#x20;

To adjust connection parameters or security settings for an active instance, select the settings gear icon located at the top right of the monitoring view.

### Provisioning self-hosted Agents & API Gateways

To add a new Agent or API Gateway to a Self-Hosted Agent Group, navigate to the Agent Group view and select either the `+ New Agent` or `+ New API Gateway` button. This opens the instance configuration form where you define connection properties and security certificates.

<figure><img src="https://3198802258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1H5SQ92uIfBOYNIeoUAc%2Fuploads%2Fi8DLdFNNFhOUBSGgDdtI%2Fimage.png?alt=media&amp;token=b5998898-2dbb-42ce-9675-bcbcf8aa00bc" alt=""><figcaption><p>Details for self-hosted Agents are provided in Environment management.</p></figcaption></figure>

In the `Name for agent` field, specify a unique identifier for the worker node within the Agent Group.&#x20;

Enter the service account authentication details in the `Username for agent` and `Password for agent` fields, which the background service or container uses to authenticate with the Frends Control Panel during startup and heartbeat operations.

{% hint style="info" %}
The user account must be in local administrator group on the server in order to work.
{% endhint %}

Configure the local port bindings in the `Ports for REST API (HTTPS)` and `Ports for REST API (HTTP)` fields, which define the network ports the instance listens on for management calls and incoming REST requests. The ports must be separately opened from the firewall, if external connectivity is required. Frends versions from 5.7 onwards only listen for the HTTPS connections.

In the `External address` field, you can optionally provide the fully qualified domain name or URL prefix that clients use to reach this specific instance. This information is used for display purposes only; if provided, the Agent's Active Triggers view can display the full URL for the HTTP and API Triggers. Actual connectivity to the Agent does not require this value, nor does adding the value enable connectivity to the Agent.

If custom TLS encryption is required, provide the certificate identifier in the `SSL Certificate thumbprint` field, or leave the input empty to allow Frends to use an automatically generated certificate.&#x20;

Save your configuration using the `Save changes` button to finalize the instance definition.

### Configuring containerized Agents

When operating in containerized environments such as Docker, Kubernetes, or cloud container services, Agent provisioning and configuration occur directly on the container server rather than through the Frends Control Panel interface.

All connection parameters, including the Frends Tenant URL, Agent Group registration token, service account credentials, and database connection strings, are supplied as environment variables in the container deployment manifests or Helm charts. When a containerized Agent pod or container starts up, it initializes its internal runtime, connects to the Frends Control Panel, and automatically registers itself within the target Agent Group. Once connected, the newly registered Agent appears dynamically in the Control Panel under the Agent Group, where administrators can immediately inspect its health, monitor event streams, and review active Triggers without performing manual UI configuration.

### Installing Agent software

To install a new Agent or API Gateway to a Self-Hosted Agent Group, navigate to the Agent Group view to find the available Agent registrations.&#x20;

<figure><img src="https://3198802258-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1H5SQ92uIfBOYNIeoUAc%2Fuploads%2FJ2yWovknWhesYpj33jyK%2Fimage.png?alt=media&amp;token=dfb500ce-edcf-42b9-9b7a-5f45884834ad" alt=""><figcaption><p>Configuration options for existing Agents.</p></figcaption></figure>

Selecting the download package dropdown on an Agent card reveals multiple installation options tailored for different operating environments.&#x20;

Choosing `Preconfigured Linux binary package` downloads a pre-configured archive containing the cross-platform runtime binaries and configuration files ready for deployment on Linux systems.&#x20;

Selecting `Windows installer` downloads a setup wizard pre-populated with the group's connection tokens for Windows server installations.&#x20;

The `Configuration only` option supplies the standalone configuration files for updating existing installations or configuring custom container workloads.

The `Database Initializer` provides the database provisioning utility to prepare the shared database schema before launching newly installed Agents.

Refer to the guide [Installing Frends Agent](/guides/setup-and-installation/installing-frends-agent.md) for more information on installing the Agent software on your server or machine.

### Monitoring Agent events

The `Agent events` section provides a real-time log viewer for tracking internal runtime diagnostics, lifecycle state changes, and error conditions reported by the instance.

The event log table displays entries with their severity `Level`, exact `Timestamp`, diagnostic `Source` namespace, and descriptive `Message`. Administrators can quickly locate specific operational issues using the `Search for agent events by message` filter bar located above the table. If an Agent encounters connectivity failures or Trigger initialization issues, detailed error traces appear directly in the message column. The table supports multi-page navigation controls to inspect historical event entries across previous operational intervals.

### Inspecting active Triggers

The `Triggers` section allows administrators to review all Process Triggers currently bound to and listening on the selected instance.

The left list displays all deployed Processes that have active Triggers running on this node, indicating the Process name, version number, and total count of active Triggers. Selecting a Process from the list displays detailed metadata in the right Trigger pane, including the Trigger type, such as `HTTP trigger`, and the fully resolved endpoint URLs for both HTTP and HTTPS listeners. This enables developers and operators to verify the exact public and internal URLs generated for API endpoints hosted on that specific worker node.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.frends.com/reference/administration/environments-and-agent-groups/agents-and-api-gateways.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 `automate deployments from our CI pipeline` 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.
