Connector Modes
Use inbound connectors to start runs asynchronously, sync connectors to return results on the same request, and outbound connectors to send data to another system.
On this page
Connectors link agents to external systems. An inbound or sync connector starts every linked agent from the same event. An outbound connector sends data from a linked agent to its configured destination.
Connectors are scoped to an environment. Each connector owns the credentials, destination validation, formatting, and retries required by its transport.
Add a connector
Start from the agent you want to connect.
Open your agent
Go to Agents in the sidebar and open the agent you want to connect.
Add a connector
In Connector Flow, click Add inbound connector or Add outbound connector, then choose Create New Connector.
Choose the connector type
Select a connector from the marketplace, choose inbound, outbound, or sync when available, and enter its settings.
Create the connector
Click Create. Open the connector from the flow later to review its settings, generated URL, or secret.
When you link an outbound connector, choose Automatic outbound connector, Agent-tool outbound connector, or Middleware outbound connector. You can change the link settings from the flow.
The same inbound or sync connector can be linked to multiple agents; one trigger starts all of them.
Inbound, sync, and outbound
The connector direction determines whether the external system starts a run, receives data, or waits for a result.
An inbound connector starts agent runs without waiting for their output. Request-driven connectors acknowledge the trigger after dispatching it.
Best for
- Background processing
- High-volume webhook ingestion
- Event-driven architectures
- Work that does not need an immediate result
HTTP webhook response
{
"status": "ok",
"dispatched_to": 2,
"run_ids": ["uuid-1", "uuid-2"]
}A sync connector keeps the request or session open until the agent completes, then returns the result on that request or session.
Best for
- REST API integrations
- Interactive applications
- Short-running agent work
- Requests that need an immediate result
HTTP webhook response
{
"status": "ok",
"result": {
"run_id": "uuid",
"output": "Response..."
}
}An outbound connector validates its own payload and handles destination selection, credentials, transport formatting, and retries. When you link it to an agent, choose how it can be called.
Best for
- External API delivery
- Chat and email notifications
- Kafka and queue pipelines
- Conditional sends during a run
Automatic HTTP, Kafka, and SQS payload
{
"run_id": "uuid",
"agent_name": "my-agent",
"status": "completed",
"output": "Agent response...",
"error": null,
"started_at": "2026-08-20T09:00:00Z",
"ended_at": "2026-08-20T09:00:02Z",
"token_usage": {}
}Choose an outbound connector mode
The mode controls who decides to send and when.
Sends once after a run completes. Send every completed run, or only runs started by selected inputs.
Adds the outbound connector as a tool to an LLM agent. The model decides whether to call it and supplies its payload.
Exposes the outbound connector to middleware. Your code decides when to send, outside the model.
Defaults to send_to_<normalized_connector_name> and must be unique across every tool available to the agent.
Call the configured name from before() or after() with send_connector(action_name, payload).
Filter automatic outbound connectors by source
Source filters apply only to automatic outbound connectors.
Sends after every completed run, including manual, scheduled, and trigger_agent runs.
Sends only when one of the selected inbound or sync connectors started the run.
Source filters do not affect agent-tool or middleware outbound connectors. Existing outbound links without mode settings behave as Automatic / All runs.
Each outbound connector defines its payload
Agent-tool and middleware outbound connectors accept the connector's documented payload, not credentials or transport envelopes. The connector validates the payload, resolves its destination and credentials, and formats the HTTP request, queue message, email, or chat message.
from connic.tools import send_connector
async def after(response: str, context: dict) -> str:
await send_connector(
"send_to_ops_slack",
{"text": response},
)
return responsesend_connector uses the same payload schema as the agent-tool outbound connector. Unknown top-level fields fail validation. Stored connector configuration stays unavailable to the agent and middleware.
What agents receive as input
The incoming format depends on the connector type.
The JSON body becomes the agent input. Form fields become key-value pairs. Uploaded files are sent to the model as inline data. See HTTP webhook details.
The message value is parsed as JSON. Connic adds a _kafka object with topic, partition, offset, timestamp, and key. See Apache Kafka details.
The agent receives the schedule, trigger time, and optional prompt. See Cron details.
Retrieve results from inbound runs
Inbound connectors return run_ids immediately. Use one of these paths to inspect or deliver the finished output.
Link it to the same agent. When the run completes, it sends the result to its configured destination.
Open the run in Logs to inspect its output, traces, and token usage.