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:
| Type | Description |
|---|---|
none | No authentication |
basic | HTTP Basic (username + password) |
bearerToken | Static bearer token |
apiKey | Custom header with a key value |
oauth2 | OAuth 2.0 Client Credentials flow |
olo | OLO 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, orPATCH - 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:
- Connector - Which API connector to use
- Authentication - Which credentials to authenticate with
- Operation - Which endpoint to call
- 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.itemsto pull just the items array) - Request Body - Static JSON, or a Liquid template (
dataTemplate) for dynamic bodies
How execution works
- Variables in parameters and body are resolved
- Full URL is built from base URL + operation path + path parameters
- Headers and authentication are applied
- HTTP request is made
- 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.
Updated 11 days ago