Zum Hauptinhalt springen
Connic

Fertige Verbindungen
für bestehende Systeme

Von Webhooks bis Stripe: Der Marketplace bündelt die verfügbaren Connic-Verbindungen. Je nach Verbindung sind Zugangsdaten verschlüsselt gespeichert, eingehende Signaturen werden geprüft und private Dienste über Connic Bridge erreichbar.

Mit Basic startenKatalog durchsuchen
Dokumentation zu Verbindungen lesen

Verbindungen

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

Passende Verbindungen für bestehende Systeme

Empfange Ereignisse und greife auf angebundene Systeme zu. Die Dokumentation zu jeder Verbindung erklärt die Einrichtung und Nutzung.

Webhook

Agenten per HTTP auslösen. Inbound, Outbound und synchrone Request-Response-Aufrufe.

Cron

Agenten nach Zeitplan mit standardmäßigen Cron Expressions in UTC ausführen.

Postgres

Agenten aus PostgreSQL LISTEN/NOTIFY Events auf einem Channel auslösen.

Kafka

Topics konsumieren, um Agenten auszulösen, oder Agent-Ergebnisse in Topics veröffentlichen.

Stripe

Agenten durch Stripe-Webhook-Events auslösen. Die Signatur wird geprüft.

Email

E-Mails per IMAP empfangen, um Agenten auszulösen, oder Antworten per SMTP senden.

SQS

SQS Nachrichten abfragen, um Agenten auszulösen, oder Ergebnisse in einer Queue veröffentlichen.

S3

Agenten bei S3 Object Events über SNS oder EventBridge auslösen.

WebSocket

Bidirektionaler Echtzeit-Chat mit Streaming Responses und Session Memory.

Alle Verbindungen im Marketplace ansehen

Ereignisse empfangen. Ergebnisse zurücksenden.

Die meisten Verbindungen starten Agenten, sobald ein externes Ereignis eintrifft. Einige können auch Antworten übermitteln, etwa per Webhook, Queue, E-Mail oder Messaging.

VerbindungInboundOutbound
  • Webhook
    ja
    ja
  • Cron
    ja
    —
  • Postgres
    ja
    —
  • Kafka
    ja
    ja
  • Stripe
    ja
    —
  • Email
    ja
    ja
  • SQS
    ja
    ja
  • S3
    ja
    —
  • WebSocket
    ja
    —
  • Telegram
    ja
    ja
  • Slack
    ja
    ja
  • MCP
    ja
    —

So verbindet Connic Stripe mit einem Agenten

Hinterlege die Webhook-URL aus Connic im Stripe-Dashboard und verknüpfe die Verbindung mit einem Agenten. Jedes ausgewählte Stripe-Ereignis startet den Agenten und wird ihm vollständig als Eingabe übergeben.

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

name: dunning-agent
type: llm
model: connic/gpt-5.6-terra
system_prompt: |
  Du bist Spezialist für Mahnwesen. Wenn eine Zahlung fehlschlägt,
  erstelle eine persönliche Nachricht, die dem Kunden beim erneuten Bezahlen hilft.
output_schema: dunning-response.json
Webhook URL

Connic erzeugt beim Erstellen der Verbindung eine eindeutige URL. Diese URL wird im Stripe Dashboard unter Developers > Webhooks zusammen mit den gewünschten Events hinterlegt.

Einen Agenten verknüpfen

Dieselbe Verbindung kann mit einem oder mehreren Agenten verknüpft werden. Jedes Event wird an alle weitergeleitet.

Agent Input

Der Agent erhält das vollständige Stripe Event Object als Input. Felder wie data.object.last_payment_error sind direkt verfügbar. Mehr erfahren

Verbindungen für geschäftskritische Abläufe

Ein Vergleich zwischen eigenen Webhook-Handlern und Connic-Verbindungen für Systeme, auf die der tägliche Betrieb angewiesen ist.

Signierte Zustellung

Stripe Webhooks werden mit HMAC-SHA256 und Timestamp Checks verifiziert. Ausgehende HTTP Webhooks signieren jeden Request mit X-Connic-Signature, damit der empfangende Endpoint die Authentizität prüfen kann.

Zugangsdaten und verschlüsselte Übertragung

Webhook Secrets, IMAP/SMTP- und Postgres-Zugangsdaten, AWS Keys und Stripe Signing Secrets werden verschlüsselt gespeichert. Kafka unterstützt SASL und Mutual TLS, Postgres unterstützt SSL Modes und Telegram Tokens werden verschlüsselt gespeichert.

Zuverlässige Zustellung

SQS Nachrichten werden erst nach erfolgreicher Verarbeitung gelöscht und erscheinen bei einem Fehler nach dem Visibility Timeout erneut, optional mit AWS DLQ. Kafka verwendet Consumer Groups, Offset Tracking und vollständige Replication Acks mit Retries.

Entdecke weitere Features

Testing

Assertions und Judges in CI.

Environments

Konfiguration und Secrets je Environment.

Bridges

Private Services ohne eingehende Ports erreichen.

Composer SDK

Agenten in YAML definieren.

Storage

Retrieval, Sessions und Database.

Observability

Jeden Schritt und jedes Token nachvollziehen.

Häufig gestellte Fragen

Das hängt von der Verbindung ab. SQS Nachrichten erscheinen nach dem Visibility Timeout erneut und können wiederholt werden; für mehrfach fehlgeschlagene Nachrichten steht optional eine AWS DLQ bereit. Kafka verwendet Consumer Groups und Offset Tracking mit Reconnect und exponentiellem Backoff. HTTP Webhooks liefern Error Status Codes, die der Aufrufer prüfen und wiederholen kann: 401 für ein ungültiges Secret, 404 für einen unbekannten Webhook und 400 bei ausschließlich ausgehender Konfiguration.

Eine HTTP-Webhook-Verbindung kann viele eigene Integrationen ersetzen. Jedes System, das eine HTTP-Anfrage senden kann, kann einen Agenten mit JSON, Formulardaten, GET oder Datei-Uploads auslösen. Ausgehende Webhooks senden das Agentenergebnis per POST an eine konfigurierte URL und signieren es mit HMAC-SHA256 zur Prüfung durch den Empfänger. Vor einer Eigenentwicklung lohnt sich der Artikel dazu, warum vorgefertigte Verbindungen eigenen Integrationscode ersetzen können.

Je nach Verbindung unterschiedlich. HTTP Webhooks verwenden ein erzeugtes Secret im X-Connic-Secret Header, als Authorization: Bearer oder Query Parameter. Stripe verifiziert Webhook Signatures mit HMAC-SHA256. Kafka unterstützt SASL (PLAIN, SCRAM-SHA-256, SCRAM-SHA-512) und Mutual TLS über PEM-Inhalte. Postgres verwendet Nutzername und Passwort mit SSL Modes. SQS und S3 nutzen AWS-Zugangsdaten. Telegram verwendet secret_token mit einem erzeugten Token im X-Telegram-Bot-Api-Secret-Token Header. E-Mail nutzt IMAP/SMTP-Zugangsdaten, bei Gmail als App-Passwort.

Das hängt von der Verbindung ab. Kafka Outbound übernimmt beim Produzieren den Key der eingehenden Nachricht und erhält so die Reihenfolge innerhalb einer Partition. SQS FIFO Queues verwenden eine Message Group ID für geordnete Zustellung; die Deduplication ID entspricht der Run ID. HTTP Webhooks und Cron Trigger laufen je Request unabhängig.

Sie verwendet PostgreSQL LISTEN/NOTIFY. Eine Trigger Function für die gewünschte Tabelle oder ein pg_notify-Aufruf im Anwendungscode veröffentlicht einen JSON Payload auf einem benannten Channel. Die Verbindung bleibt für diesen Channel bestehen und startet für jede Notification einen Agent Run. Payloads sind auf 8000 Bytes begrenzt; daher können IDs gesendet werden, während der Agent die vollständige Zeile abruft.

Ja. Postgres und ausgehende HTTP Webhooks können über die Connic Bridge in private Netzwerke geroutet werden, ohne öffentlich erreichbar zu sein.