An AI agent in production does not wait behind a chat box. It wakes up when something happens elsewhere: a service calls it, a database row changes, or a message lands on a stream or a queue. In Connic that wake-up is an inbound connector. The four most common ones, webhook, Apache Kafka, Postgres LISTEN/NOTIFY, and AWS SQS, each deliver the same event with sharply different guarantees. Pick the wrong one and you either drop events under load or stand up infrastructure you never needed.
Every trigger is an inbound connector
All four are inbound connectors: an external event arrives, Connic parses it, and an agent run starts with the payload attached. The connector layer handles receiving the event, authenticating the source, and retrying or buffering wherever the protocol allows. So the real difference between them is not the agent. It is what happens to an event on its way from your system to that run. See the connectors overview for how inbound, outbound, and sync modes fit together, and why pre-built connectors replace integration glue for the broader case.
Webhook: synchronous HTTP push
A webhook connector gives your agent a URL. Any service that can make an HTTP request triggers a run by posting to it, authenticated with a shared secret in the X-Connic-Secret header. It is the lowest-latency option and the only one that can hand the result straight back: in sync mode the request blocks until the run finishes and returns its output, which is what a chat UI or a synchronous API call needs.
curl -X POST "<webhook-url>" \
-H "X-Connic-Secret: <your-secret-key>" \
-H "Content-Type: application/json" \
-d '{"order_id": "12345", "action": "review"}'The trade-off is durability. An HTTP request is a single attempt. If your agent is briefly unavailable, the event is gone unless the caller retries it. There is no buffer and no ordering between concurrent calls, so a webhook fits when the sender owns delivery and fails when events must never be lost. See the webhook connector reference for sync mode and signature verification.
Apache Kafka: streaming consumer
A Kafka connector subscribes to a topic as a consumer and starts a run for every message. The full Kafka context (topic, partition, offset, key) arrives under a _kafka field. Because Kafka is a durable, ordered log, this pattern gives the strongest guarantees of the four: at-least-once delivery, ordering within a partition, and replay of history by resetting the consumer to the earliest offset. Consumer groups let you share load across runs or fan the same stream out to several agents.
{
"order_id": "12345",
"customer": "john@example.com",
"items": ["widget-a", "widget-b"],
"_kafka": {
"topic": "orders",
"partition": 0,
"offset": 1542,
"key": "order-12345"
}
}Reach for Kafka when you already run it, when throughput is high, or when ordering and replay matter, such as reprocessing a day of events after fixing an agent. The cost is operational: you need a cluster, and the connector is a consumer in it. Full options are in the Kafka connector reference.
Postgres LISTEN/NOTIFY: in-database push
If the event you care about is a change in your database, you may not need a queue at all. The Postgres connector opens a persistent connection and listens on a channel; a trigger calls pg_notify when rows change, and each notification starts a run. There is no polling and no extra infrastructure: the database you already have becomes the event source.
-- Notify the agent whenever a customer row is inserted
CREATE OR REPLACE FUNCTION notify_new_customer()
RETURNS TRIGGER AS $$
BEGIN
PERFORM pg_notify(
'new_customers',
json_build_object('customer_id', NEW.id)::text
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER customer_insert_trigger
AFTER INSERT ON customers
FOR EACH ROW
EXECUTE FUNCTION notify_new_customer();NOTIFY is fire-and-forget, though. Notifications are not buffered: if nothing is listening at that moment they are dropped, and there is no replay. Payloads are capped at 8000 bytes, so the durable pattern is to send IDs and let the agent fetch the full row. Use LISTEN/NOTIFY for near-real-time reactions to data changes where an occasional miss during a reconnect is acceptable, and use Kafka or SQS when every change must be processed. If the database sits in a private network, route it through a private network bridge rather than exposing it. The full setup is in the Postgres connector reference.
AWS SQS: durable polled queue
An SQS connector polls a queue with long polling and starts a run per message. It sits between durability and simplicity: messages persist in the queue until a run completes and deletes them, so a restart or a spike never loses work. If a run fails, the message reappears after its visibility timeout and is retried; messages that fail repeatedly can be routed to a dead-letter queue you configure in AWS. Standard queues do not guarantee order, while FIFO queues preserve it within a message group.
This is the pattern for reliable asynchronous work that must survive failure without you building the retry machinery yourself. The latency floor is the polling interval, up to 20 seconds, and you need an AWS account and credentials. See the SQS connector reference for the queue and polling settings.
Side by side
The four patterns line up cleanly on the dimensions that decide which one fits:
| Dimension | Webhook | Kafka | Postgres | SQS |
|---|---|---|---|---|
| Trigger style | Synchronous HTTP push | Streaming consumer | In-database push (NOTIFY) | Polled queue |
| Delivery guarantee | At-most-once (caller retries) | At-least-once | At-most-once | At-least-once |
| Ordering | None | Per partition | Commit order while connected | None (FIFO: per group) |
| Buffering / replay | None | Durable log, replayable | None (not buffered) | Durable queue, no replay |
| Backpressure | Hits the agent directly | Consumer lag | None | Queue absorbs spikes |
| Typical latency | Lowest (can return result) | Near-real-time | Near-real-time | Poll interval (up to 20s) |
| Extra infrastructure | None | Kafka cluster | Reuse your database | AWS account + queue |
Choosing a pattern
Webhooks, Kafka, Postgres, SQS, and more, wired up as configuration instead of consumer code.
Try Connic freeThe same patterns cover the rest of the catalog
These four are the archetypes, but the model is the same for the other systems Connic connects to: cron for scheduled runs, S3 for file uploads, email, Stripe for signed events, Telegram for chat, WebSocket for live streams, and an MCP connector that exposes agents as callable tools, among others. Each one is push or pull, durable or ephemeral, ordered or not, so the decision dimensions above carry straight over. See the full list on the connectors page.
Triggering in production vs. testing
These connectors are the production path for triggering agents from real events. A REST trigger endpoint exists as well, but it is meant for first-party calls and testing. Reach for a connector whenever an external system should drive the agent. See the REST API reference for the endpoint and the quickstart to wire up your first connector.