API connectors

An API connector represents a single external API that your agent can call. You define the API's base URL, how to authenticate, and which endpoints (operations) are available, then use those operations in your messages to fetch or send data.

Setting up an API connector

To create an API connector, you need:

Base URL

The root URL that all operations share. Operation paths are appended to this.

For example, if your base URL is https://api.example.com/v1 and an operation's path is /orders/:orderId, the full request URL becomes https://api.example.com/v1/orders/:orderId.

Authentication

The authentication method your API requires. All credentials created under this connector must match this type. Options:

TypeDescription
noneNo authentication
basicHTTP Basic (username + password)
bearerTokenStatic bearer token
apiKeyCustom header with a key value
oauth2OAuth 2.0 Client Credentials flow
oloOLO HMAC signature

After choosing a type, you create one or more authentication instances with the actual credentials. This lets you keep separate credentials for different environments (e.g. "Production" and "Staging") without duplicating the connector.

For setup details on each type, see API Connector Authentication.

Headers

Default headers included with every request (e.g. Content-Type: application/json, Accept: application/json). These apply to all operations on the connector.

Operations

Operations are the API endpoints you want to call. Each operation has:

  • Name - A unique identifier within the connector (e.g. get-order). This is how you reference it from messages.
  • Method - GET, POST, PUT, DELETE, or PATCH
  • Path - Appended to the base URL. Supports path parameters with colon syntax (e.g. /orders/:orderId).
  • Query Parameters - Declared parameter names and whether they're required. Values are provided when the operation is called from a message.
  • Request/Response Body Examples - Optional JSON examples for documentation. These help when configuring the operation in messages.

Connector ID

A unique kebab-case identifier (e.g. order-service, weather-api). Max 100 characters. Auto-generated from the connector name in the UI, but customizable. Cannot be changed after creation.


Example connector

weather-api
├── Base URL: https://api.weather.com/v3
├── Auth Type: apiKey
├── Headers: { "Accept": "application/json" }
├── Operations:
│   ├── get-forecast    → GET  /forecast/:locationId
│   └── get-alerts      → GET  /alerts?region=:region
└── Authentications:
    └── "Production Key"  (authenticationId: abc123)

Using operations in messages

When you add an operation to a message, you select:

  1. Connector - Which API connector to use
  2. Authentication - Which credentials to authenticate with
  3. Operation - Which endpoint to call
  4. Context Key - Where to store the result in data (e.g. forecast → accessible later as {{ data.forecast }})

You can also configure:

  • Path Parameters - Values for parameters in the URL path (e.g. :locationId). Supports Liquid syntax for dynamic values like {{ data.userLocation }}
  • Query Parameters - Key-value pairs appended to the URL
  • JSONPath - Extract a subset of the response before storing it (e.g. $.data.items to pull just the items array)
  • Request Body - Static JSON, or a Liquid template (dataTemplate) for dynamic bodies

How execution works

  1. Variables in parameters and body are resolved
  2. Full URL is built from base URL + operation path + path parameters
  3. Headers and authentication are applied
  4. HTTP request is made
  5. JSONPath is applied (if set), then result is stored at the context key

The result is available in your template and in subsequent operations within the same message.


API reference

To manage connectors programmatically, see the Connectors API.