Connector Modes
Inbound connectors start runs asynchronously, sync connectors return responses through the same request or session, and outbound connectors send data to other systems.
On this page
Connectors link agents to external systems. An inbound or sync connector starts its linked agents from an external 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.
Create connectors in the dashboard as described below, through the REST API or connic MCP, or declare them in connectors/*.yaml in the project repository so that deploys apply them. See Connectors in code.
Add a connector
Start from the agent to connect.
Open the agent
Go to Agents in the sidebar and open the agent 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 linking an outbound connector, choose Automatic outbound connector, Agent-tool outbound connector, or Middleware outbound connector. Change the link settings from the flow.
For connector types that support multiple agents, one trigger starts every linked agent.
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 returns the agent's responses through the request or session that started it. Depending on the connector type, it delivers a complete result or streams responses as they are produced.
Best for
- REST API integrations
- Interactive applications
- Real-time conversations
- 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 linking 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. Application 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.
Pause and resume a connector
Open the connector from the Connector Flow and click Pause. A paused connector starts no new runs until you click Resume. Runs that are already queued or running are not affected.
What happens to events that arrive during a pause depends on the connector type.
connic stops reading. Messages stay in the topic or queue and are processed after you resume. Kafka continues from the last committed offset of the consumer group, so messages must still be within the topic retention.
connic stops listening on the channel. PostgreSQL does not keep notifications for a listener that is not connected, so notifications sent during the pause are lost.
Connectors such as HTTP webhook, Stripe, Slack, Telegram, and Twilio Messaging acknowledge requests without starting runs. These events are not stored and are not replayed after you resume.
New connections are refused. An open connection receives a CONNECTOR_INACTIVE error on its next message and closes.
Twilio Voice and Telnyx Voice reject incoming calls.
No scheduled runs start. Schedule times that pass during the pause are not made up.
New inbound Kafka, SQS, and PostgreSQL connectors are created paused. Click Resume once the connector is linked and ready to consume. Connectors declared in code start active instead.