Connectors

Connectors are integrations between Koladr and external services. They enable Koladr to execute approved actions on behalf of your agents, so your agents never need direct access to third-party credentials.

What Connectors Are

A connector is a configured link between Koladr and an external service like Gmail, Stripe, HubSpot, or Zendesk. When an agent action is approved, Koladr uses the appropriate connector to execute it.

This architecture provides two key benefits:

Credential isolation. Your agents never see third-party API keys or OAuth tokens. Koladr holds the credentials and executes on their behalf.
Centralized governance. Every action through a connector passes through your policies first. You get a single point of control for all external interactions.

How Connectors Work

The flow is:

An agent requests an action (e.g. email.send)
Koladr evaluates policies and determines the action is allowed
Koladr maps the action to the appropriate connector (e.g. Gmail)
The connector executes the action using its stored credentials
The result is logged in the run timeline

Connectors handle authentication, rate limiting, and error handling for the external service. Your agent code only needs to describe what it wants to do, not how to do it.

Supported Providers

Gmail

Send transactional or outbound email through a connected Gmail account. Connects via OAuth 2.0. Currently exposes email.send.

Stripe

Issue refunds and look up payment metadata. Connects via API key. Currently exposes refund.create, charge.retrieve, and customer.retrieve.

HubSpot

Create, update, and read CRM records (contacts, companies, deals, tickets). Connects via OAuth 2.0. Currently exposes crm.create_record, crm.update_record, and crm.get_record.

Zendesk

Read and update support tickets and add comments. Connects via API token. Currently exposes ticket.get, ticket.update, and ticket.add_comment.

Supported Actions

The tables below list every action type a built-in connector will execute, along with the payload fields each action expects. Use these action types when authoring policies — for example, action_type = refund.create AND payload.amount > 5000.

ℹCustom action types are also fine

Agents can request any action string via requestAction(), and policies can target any string — these are just the actions the built-in connectors will actually execute today. Custom action types still flow through the policy engine, approvals queue, and run timeline; they just won't auto-dispatch to a third-party API.

Stripe

Action	Description	Payload
`refund.create`	Issue a refund against a charge or payment intent.	One of `charge` or `payment_intent` (string). Optional: `amount` (number, smallest currency unit), `reason` (string — must be a Stripe-allowed reason).
`charge.retrieve`	Look up a charge by ID.	Required: `chargeId` (string).
`customer.retrieve`	Look up a customer by ID.	Required: `customerId` (string).

Gmail

Action	Description	Payload
`email.send`	Send an email from the connected Gmail account.	Required: `to` (string or string array), `subject` (string), and at least one of `text` / `html` (string). Optional: `cc`, `bcc`, `threadId`, `inReplyTo`.

HubSpot

All HubSpot actions accept an objectType of contacts, companies, deals, or tickets.

Action	Description	Payload
`crm.create_record`	Create a new CRM record.	Required: `objectType` (string), `properties` (object of CRM properties).
`crm.update_record`	Patch fields on an existing CRM record.	Required: `objectType` (string), `recordId` (string), `properties` (object).
`crm.get_record`	Read an existing CRM record.	Required: `objectType` (string), `recordId` (string). Optional: `properties` (string array — fields to return).

Zendesk

Action	Description	Payload
`ticket.get`	Look up a ticket by ID.	Required: `ticketId` (number or numeric string).
`ticket.update`	Update fields on a ticket and/or attach a comment in a single call.	Required: `ticketId` plus at least one of `updates` (object: e.g. `status`, `priority`, `type`, `assigneeId`, `groupId`, `subject`, `externalId`, `tags`) or `comment` (object: `body`, `public`).
`ticket.add_comment`	Append a comment to an existing ticket.	Required: `ticketId`, `body` (string). Optional: `public` (boolean — defaults to `false`).

Connecting a Provider

To set up a connector:

Navigate to Connectors in the sidebar
Find the provider you want to connect
Click Connect
For OAuth providers (Gmail, HubSpot): complete the authorization flow in the popup
For API key providers (Stripe, Zendesk): enter your API key
Test the connection to verify it works

Once connected, the connector is available for all agents in your workspace. You can disconnect and reconnect at any time.

Governed Execution

The key insight of connectors is that they enforce the governance layer. Your agents cannot bypass Koladr to interact with external services directly. Every action goes through the policy engine first.

This means:

You have a complete audit trail of every external interaction
Policies apply consistently regardless of which agent made the request
You can revoke connector access without changing any agent code
Credential rotation happens in one place, not across every agent

Current Status

ℹConnector availability

Koladr's connector system is in active development. Currently, connectors are available in demo/stub mode for testing and evaluation. Full production integrations for Gmail, Stripe, HubSpot, and Zendesk are being rolled out progressively. Contact us if you need production access to a specific provider.

In demo mode, connectors simulate the execution of actions and return realistic responses. This lets you build and test your full agent workflow, including policies and approvals, before connecting to live external services.

Monitoring Runs

Track and inspect agent activity in real time

→