Webhook vs Kafka vs SQS vs Postgres for AI Agent Triggers

Webhook, Apache Kafka, AWS SQS, and Postgres LISTEN/NOTIFY solve one production question: how does an external event start an AI agent run? The choice depends on delivery, ordering, replay, backpressure, and response latency. This comparison stays at that inbound trigger boundary; outbound result delivery and MCP tool calls are separate decisions.

Four inbound paths to the same agent run

All four are inbound connectors: an external event arrives, Connic parses it, and one run starts for every linked agent with the payload attached. The connector layer handles receiving the event, authenticating the source, and retrying or buffering where the protocol supports it. The agent can stay unchanged while the event path changes underneath it. The documentation explains inbound, outbound, and sync modes.

The guide to pre-built AI agent connectors covers the wider integration setup. The Connic connector catalog lists available connections and links to their setup guides.

Webhook: synchronous HTTP push

A webhook connector gives the agent a URL. Any service that can make an HTTP request triggers one run for every linked agent by posting to it, authenticated with a shared secret in the X-Connic-Secret header. It is the direct HTTP 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"}'

Until Connic accepts the request, delivery belongs to the caller: retry transport failures and unsuccessful responses. In inbound mode, a successful response includes run IDs that Connic has created. Monitor those run IDs for dispatch or execution failure; the HTTP response does not prove that queue publication succeeded. The source still has no durable event log or ordering between concurrent calls. A caller that retries should send a stable event ID or idempotency key. The receiving agent or tool must persist processed IDs and check them before repeating a side effect; the webhook connector does not deduplicate arbitrary payloads. The documentation covers webhook sync setup and outbound signature verification.

Apache Kafka: streaming consumer

A Kafka connector subscribes to a topic as a consumer and starts one run for every linked agent on each message. The full Kafka context (topic, partition, offset, key) arrives under a _kafka field. Because Kafka is a durable, ordered log, this pattern preserves order within a partition and can replay retained history with a new consumer group configured to start at the earliest offset. Connic commits the offset after it creates a run for every linked agent. A restart before that commit can redeliver the message and duplicate a run already created; after the commit, a created run that fails before or during execution does not make Kafka redeliver the message.

{
  "order_id": "12345",
  "customer": "john@example.com",
  "items": ["widget-a", "widget-b"],
  "_kafka": {
    "topic": "orders",
    "partition": 0,
    "offset": 1542,
    "key": "order-12345"
  }
}

Consumers that share a group ID split partitions between them. Separate group IDs consume the same retained stream independently. Inside Connic, one connector fans each message out to every agent linked to that connector. Kafka fits teams that already run it, have high throughput, or need ordering and replay. The cost is operational: it requires a cluster, and the connector is a consumer in it. Kafka connector settings.

Postgres LISTEN/NOTIFY: in-database push

A database change 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 one run for every linked agent. There is no polling and no extra infrastructure: the existing database 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 keeps no replay log for a disconnected listener. A notification sent while the connector is disconnected is missed, and reconnecting does not recover it. PostgreSQL's documentation, checked in 2026, sets the default payload limit below 8000 bytes, so send an ID and let the agent fetch the full row. PostgreSQL NOTIFY delivery and payload limits. 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 Bridge instead of exposing it. Implementation details cover private infrastructure access through Bridge and Postgres LISTEN/NOTIFY setup.

AWS SQS: durable polled queue

An SQS connector polls a queue with long polling and starts one run for every linked agent per message. Messages persist until every linked run completes and the connector deletes them, so worker restarts and traffic spikes do not discard queued 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 configured in AWS. Standard queues do not guarantee order, while FIFO queues preserve it within a message group.

This pattern supports reliable asynchronous work that must survive failure without an in-house retry implementation. AWS documentation checked in 2026 allows a long poll to wait up to 20 seconds when the queue is empty; the request returns sooner when a message arrives. AWS SQS long-poll limits. An AWS account and credentials are also required. SQS queue and polling settings.

Side by side

Delivery, ordering, replay, backpressure, and latency distinguish these triggers:

Choosing a pattern