Skip to main content
Connic

Ready-made connections
for existing systems

From webhooks to Stripe, the Marketplace brings together the available Connic connections. Depending on the connection, credentials are stored encrypted, incoming signatures are verified, and private services are accessible through Connic Bridge.

Start for freeBrowse the catalog
Read the connector docs

Connectors

trigger
stripe.invoice.paid
agent
invoice-processor
Webhook
Cron
Postgres
Kafka
Stripe
Email
SQS
Telegram
WebSocket
S3
MCP

Connections for existing systems

Receive events and access connected systems. Each connection’s documentation explains setup and usage.

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 all connectors in the marketplace

Receive events. Send results back.

Most connections start agents when an external event arrives. Some also deliver responses through webhooks, queues, email, or 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
  • Slack
    yes
    yes
  • Twilio Messaging
    yes
    yes
  • Telnyx Voice
    yes
    —
  • Telnyx Messaging
    yes
    yes
  • MCP
    yes
    —

How Connic connects Stripe to an agent

Register the webhook URL from Connic in the Stripe dashboard and link the connection to an agent. Each selected Stripe event starts the agent and is passed to it in full as input.

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

name: dunning-agent
type: llm
model: connic/gpt-5.6-sol
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 the connector is created. The URL belongs in Stripe Dashboard > Developers > Webhooks alongside the selected events.

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. Fields such as data.object.last_payment_error are available directly. Learn more

Connections for business-critical workflows

Compare custom webhook handlers with Connic connections for systems that daily operations depend on.

Signed delivery

Stripe webhooks are verified with HMAC-SHA256 and timestamp checks. Outbound HTTP webhooks sign every request with X-Connic-Signature so the receiving 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-environment config and secrets.

Bridges

Reach private services, no inbound ports.

Composer SDK

Define agents in YAML.

Storage

Retrieval, sessions, and 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, with an optional 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 controlled URL with HMAC-SHA256 signatures for endpoint verification. Before building a custom connector, see the case for pre-built connectors over custom integration code.

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. A trigger function on the relevant table, or a pg_notify call in the application code, 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 IDs can be sent while the agent fetches the full row.

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