Connic

Wire agents to
the systems you already run

Webhook, Cron, Postgres, Kafka, Stripe, Email, S3, SQS, WebSocket, Telegram, MCP. Signature verification, encrypted credentials, SASL/mTLS for Kafka, Bridge support for private networks.

Start Building FreeBrowse the catalog
Read the connector docs

Connectors

inbound & outboundall healthy
trigger
stripe.invoice.paid
agent
invoice-processor
Webhook
Cron
Postgres
Kafka
Stripe
Email
SQS
Telegram
WebSocket
S3
MCP
The catalog

Real systems. No glue code.

Inbound and outbound connectors for the systems your team already runs. Click any connector for the docs.

Webhook

Trigger agents via HTTP. Inbound, outbound, and sync request-response.

Cron

Run agents on a schedule using standard cron expressions in UTC.

Postgres

Trigger agents from PostgreSQL LISTEN/NOTIFY events on a channel.

Kafka

Consume topics to trigger agents, or produce agent results to topics.

Stripe

Trigger agents from Stripe webhook events. Signature verified.

Email

Receive emails via IMAP to trigger agents, or send replies via SMTP.

SQS

Poll SQS messages to trigger agents, or publish results to a queue.

S3

Trigger agents on S3 object events via SNS or EventBridge.

WebSocket

Bidirectional real-time chat with streaming responses and session memory.

See the full library
Two directions

Trigger agents in. Send results out.

Most connectors trigger agent runs from external events. Several also send agent responses back out: webhooks, queues, email, messaging.

ConnectorInboundOutbound
  • Webhook
    yes
    yes
  • Cron
    yes
    —
  • Postgres
    yes
    —
  • Kafka
    yes
    yes
  • Stripe
    yes
    —
  • Email
    yes
    yes
  • SQS
    yes
    yes
  • S3
    yes
    —
  • WebSocket
    yes
    —
  • Telegram
    yes
    yes
  • MCP
    yes
    —
From Stripe to your agent in three steps

Anatomy of a connector

Create a Stripe connector in Connic, paste the webhook URL into the Stripe Dashboard, and link it to an agent. Every selected event triggers the agent with the full Stripe event as input.

agents/dunning-agent.yaml
version: "1.0"

name: dunning-agent
type: llm
model: gemini/gemini-2.5-flash
system_prompt: |
  You are a dunning specialist. When a payment fails,
  draft a personalized recovery message for the customer.
output_schema: dunning-response.json
Webhook URL

Connic generates a unique URL when you create the connector. Paste it into Stripe Dashboard > Developers > Webhooks and pick the events you want.

Link an agent

The same connector can be linked to one or many agents. Each event fans out to all of them.

Agent input

The agent receives the full Stripe event object as input. Access fields like data.object.last_payment_error directly. Learn more

Connectors that survive production

What separates a webhook handler from a connector you can put in front of revenue

Signed delivery

Stripe webhooks are verified with HMAC-SHA256 and timestamp checks. Outbound HTTP webhooks sign every request with X-Connic-Signature so your endpoint can verify authenticity.

Secrets and transport security

Webhook secrets, IMAP/SMTP and Postgres credentials, AWS keys, and Stripe signing secrets are stored encrypted. Kafka supports SASL and mutual TLS; Postgres supports SSL modes; Telegram tokens are stored encrypted.

Reliable delivery

SQS messages are deleted only after success and re-appear after the visibility timeout on failure (with optional AWS DLQ). Kafka uses consumer groups, offset tracking, and full replication acks with retries.

Keep exploring

Testing

Assertions and judges, in CI.

Environments

Per-env config and secrets.

Bridges

Reach private services, no inbound ports.

Composer SDK

Define agents in YAML.

Storage

Knowledge, sessions, and a database.

Observability

Trace every step, every token.

Frequently Asked Questions

It depends on the connector. SQS messages re-appear after the visibility timeout for retry, and you can configure an AWS DLQ for messages that fail repeatedly. Kafka uses consumer groups and offset tracking with reconnection and exponential backoff. HTTP webhooks return error status codes (401 invalid secret, 404 unknown webhook, 400 outbound-only) that the caller can inspect and retry.

The HTTP Webhook connector is the universal escape hatch. Any system that can make an HTTP request can trigger an agent (JSON, form data, GET, file uploads). On the outbound side, an outbound webhook POSTs the agent result to any URL you control with HMAC-SHA256 signatures so your endpoint can verify it.

Per-connector. HTTP webhooks use a generated secret (X-Connic-Secret header, Authorization: Bearer, or query param). Stripe verifies webhook signatures with HMAC-SHA256. Kafka supports SASL (PLAIN, SCRAM-SHA-256, SCRAM-SHA-512) and mutual TLS via PEM contents. Postgres uses username/password with SSL modes. SQS and S3 use AWS credentials. Telegram uses the secret_token feature with a generated token in the X-Telegram-Bot-Api-Secret-Token header. Email uses IMAP/SMTP credentials (app passwords for Gmail).

Per-connector. Kafka outbound preserves the inbound message key when producing, keeping ordering within a partition. SQS FIFO queues use a Message Group ID for ordered delivery (deduplication ID is set to the run ID). HTTP webhooks and cron triggers run independently per request.

It uses PostgreSQL LISTEN/NOTIFY. You create a trigger function on the table you care about (or call pg_notify from your application code) that publishes a JSON payload to a named channel. The connector keeps a persistent connection open on that channel and dispatches an agent run for every notification. Payloads are capped at 8000 bytes, so send IDs and let the agent fetch the full row.

Yes. Postgres and outbound HTTP webhooks can route through the Connic Bridge for private networks instead of requiring public reachability.