Zum Hauptinhalt springen
connic

KI in dein Produkt bringen.
Mit einem API-Aufruf.

Antworten entwerfen, Shop-Kunden beraten oder Leads anreichern. Dein Backend ruft den Agenten mit einer Anfrage auf, seine Tools lesen die Kundendaten über deine API.

Starte kostenlosKontaktiere Sales
Lies den Quickstart
suggest-reply
webhook · sync
Anfrage
POST /webhook/7c1e9a52-0d4b-4f6e-9a83-5b2c1e7d4f10
Host: connect.connic.co
X-Connic-Secret: <secret>
Content-Type: application/json

{"account_id": "acct_4821", "ticket_id": "T-1093"}
Antwort200 OKreply-assistant · completed
result.outputaus dem JSON-String geparst
{
  "reply": "Hi Dana, you can export invoices as CSV under Billing > Export.",
  "article_ids": ["kb-112"],
  "needs_human": false
}

Antworten entwerfen. Shop-Kunden beraten. Leads anreichern.

Egal, was dein Produkt macht: Jede KI-Funktion ist eine Agentendatei. Wie dein Produkt sie aufruft, legt eine kleine Verbindungsdatei daneben fest.

agents/reply-assistant.yaml

Helpdesk: schreibt den Entwurf hinter dem Button „Antwort vorschlagen“. Ein synchroner Webhook liefert ihn direkt in der HTTP-Antwort.

version: "1.0"
name: reply-assistant
description: "Drafts replies to help desk tickets"
model: connic/claude-sonnet-5
system_prompt: |
  Draft a reply to the customer's latest message.
  Use only facts from the ticket and the account's articles.
  Set needs_human when the customer asks for a refund.
tools:
  - helpdesk.get_ticket
  - helpdesk.search_articles
output_schema: reply
agents/shop-advisor.yaml

Onlineshop: empfiehlt Produkte, die auf Lager sind. Eine WebSocket-Verbindung streamt jede Antwort, die Session merkt sich den Besucher.

version: "1.0"
name: shop-advisor
description: "Recommends products in the shop chat"
model: connic/gemini-3.6-flash
system_prompt: |
  Help the shopper find the right product.
  Only recommend items that are in stock.
tools:
  - catalog.search_products
  - catalog.check_stock
session:
  key: context.visitor_id
  ttl: 3600
agents/lead-enricher.yaml

CRM: recherchiert jede neue Anmeldung im Web und schreibt das Profil zurück an den Lead. Ein eingehender Webhook startet den Agenten im Hintergrund.

version: "1.0"
name: lead-enricher
description: "Researches new sign-ups before the first sales call"
model: connic/gpt-5.6-terra
system_prompt: |
  Find the lead's company, size and industry.
  Cite the pages you used. Never guess.
tools:
  - web_search
  - web_read_page
  - crm.update_lead
output_schema: lead_profile
agents/expense-categorizer.yaml

Buchhaltungs-App: ordnet jede Banktransaktion einer Buchungskategorie zu. Läuft im Hintergrund, bis zu 20 Transaktionen gleichzeitig.

version: "1.0"
name: expense-categorizer
description: "Books bank transactions to a ledger category"
model: connic/gpt-5.6-luna
system_prompt: |
  Pick the ledger category for the transaction.
  Flag anything that looks private or duplicated.
tools:
  - ledger.list_categories
output_schema: booking
max_concurrent_runs: 20
agents/listing-writer.yaml

Marktplatz: schreibt den Angebotstext aus den Artikeldaten, sobald der Verkäufer auf „Generieren“ klickt.

version: "1.0"
name: listing-writer
description: "Writes listing texts from item attributes"
model: connic/claude-sonnet-5
system_prompt: |
  Write a short, honest listing from the attributes.
  Follow the category rules and the seller's language.
tools:
  - marketplace.get_category_rules
output_schema: listing

Tools rufen deine API auf. Nur für den Kunden, der fragt.

Dein Backend schickt mit jeder Anfrage die account_id, eine Middleware legt sie im Run-Kontext ab. Jeder Tool-Aufruf und jede Suche bleibt in diesem Konto.

Kein Tool-Argument
Der context-Parameter taucht im Tool-Schema für das KI-Modell gar nicht auf. Ein anderes Konto kann es also nicht übergeben.
Ein Retrieval-Namespace pro Konto
Dein Backend indexiert die Artikel jedes Kontos in einem eigenen Namespace. search_articles sucht nur dort.
Ein Service-Token pro Environment
Die Tools lesen das Token für deine API aus einer Variable des Environments. So kann Staging deine Staging-API aufrufen.
tools/helpdesk.py
import os

import httpx
from connic.tools import retrieval_query

API_URL = os.environ["HELPDESK_API_URL"]
TOKEN = os.environ["HELPDESK_API_TOKEN"]

async def get_ticket(ticket_id: str, context: dict) -> dict:
    """Return the ticket thread with the customer's latest message.

    Args:
        ticket_id: Ticket ID from the request, such as T-1093
    """
    account_id = context["account_id"]
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"{API_URL}/accounts/{account_id}/tickets/{ticket_id}",
            headers={"Authorization": f"Bearer {TOKEN}"},
        )
        resp.raise_for_status()
        return resp.json()

async def search_articles(question: str, context: dict) -> list:
    """Search this account's help center for articles to cite.

    Args:
        question: What the customer is asking, in a few words
    """
    namespace = f"articles.{context['account_id']}"
    result = await retrieval_query(question, namespace=namespace, max_results=5)
    return result["results"]

Jede Antwort bis zum Tool-Aufruf nachvollziehen.

Jeder Aufruf wird als Run gespeichert, mit Kontext, Tool-Aufrufen und finalem JSON. Gruppiere die Token-Nutzung nach account_id, und du siehst, was jeder Kunde kostet.

Run 7f3c2a91
Completed
SpanData
Runreply-assistantok
Inbound connectorsuggest-replyok
Middlewarebeforeok
LLM Agentreply-assistantok
LLM Callok
Tool Callhelpdesk.get_ticketok{"ticket_id": "T-1093"}
Tool Callhelpdesk.search_articlesok{"question": "export invoices as CSV"}
LLM Callok{"reply":"Hi Dana, you can export invoices as CSV under Billing > Export.","article_ids":["kb-112"],"needs_human":false}
Context
account_id
"acct_4821"
agent_name
"reply-assistant"
payload.ticket_id
"T-1093"

JSON nach deinem Schema. Bei jedem Aufruf.

output_schema verknüpft reply-assistant mit schemas/reply.json. Über needs_human weiß deine Oberfläche, wann sie einen Entwurf zurückhalten soll.

Geprüft, bevor es dein Backend erreicht
Passt eine Antwort nicht zum Schema, schlägt der Run fehl, und die synchrone Antwort meldet status failed.
Vor dem Deployment getestet
tests/reply-assistant.yaml prüft die geparste Ausgabe, etwa output.needs_human == true bei einer Erstattungsanfrage.
agents/reply-assistant.yaml
version: "1.0"
name: reply-assistant
description: "Drafts replies to help desk tickets"
model: connic/claude-sonnet-5
system_prompt: |
  Draft a reply to the customer's latest message.
  Use only facts from the ticket and the account's articles.
  Set needs_human when the customer asks for a refund.
tools:
  - helpdesk.get_ticket
  - helpdesk.search_articles
output_schema: reply
schemas/reply.json
{
  "type": "object",
  "description": "A drafted ticket reply",
  "properties": {
    "reply": { "type": "string" },
    "article_ids": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Help center articles the reply relies on"
    },
    "needs_human": { "type": "boolean" }
  },
  "required": ["reply", "article_ids", "needs_human"]
}
connectors/suggest-reply.yaml
type: webhook
mode: sync
agents:
  - reply-assistant

Erst testen. Dann über Staging live.

connic test führt die Testfälle aus, die jedes Deployment absichern. Staging bekommt eine eigene URL, ein eigenes Secret und eigene Variablen.

Ist ein Git-Anbieter verbunden, löst ein Merge auf den Branch der Produktivumgebung das Deployment aus.

$ connic test
  PASS  reply-assistant::cites_the_export_article  1/1  100%
  PASS  reply-assistant::hands_refunds_to_a_human  1/1  100%
  ✓ 2/2 cases passed.
 
$ connic deploy --env staging --yes
  → Validating project files...
    ✓ Lint passed
  → Checking project and environment...
    ✓ Environment: Staging
  → Packaging upload...
    ✓ 8 files, 12,406 bytes
  → Submitting to backend...
  ✓ Deployment created.

Entdecke weitere Features

VerbindungenWebhooks, WebSockets, Zeitpläne und mehr, im Code.ToolsPython-Funktionen mit Zugriff auf den Run-Kontext.RetrievalDie Dokumente jedes Kunden durchsuchen.TestingPrüft die Ausgabe vor jedem Deployment.EnvironmentsStaging und Produktivumgebung mit eigenen Variablen.ObservabilityJeder Run, jeder Tool-Aufruf und jedes Token nachvollziehbar.

Häufig gestellte Fragen

Über eine Verbindung. Ein synchroner Webhook wartet bis zu fünf Minuten und liefert die Ausgabe des Agenten direkt in der HTTP-Antwort. Für längere Aufgaben gibt ein eingehender Webhook sofort die Run-IDs zurück, und ein ausgehender Webhook schickt das Ergebnis an deine API, sobald der Run fertig ist.

Schick die Konto-ID mit jeder Anfrage mit und leg sie per Middleware im Run-Kontext ab. Dort lesen die Tools sie aus, ohne dass das KI-Modell sie ändern kann, und die Suche läuft nur im Retrieval-Namespace dieses Kontos. Getrennte Environments halten außerdem Staging- und Produktivdaten auseinander.

Ja. Starte eine connic Bridge in deinem privaten Netzwerk. Sie baut einen ausgehenden Tunnel zu connic auf, und die Tools erreichen die API über einen Bridge-Hostnamen. Eingehende Ports musst du dafür nicht öffnen.

Das hängt vom KI-Modell, der Aufgabe und der Zahl der Tool-Aufrufe ab. Der synchrone Webhook wartet bis zu fünf Minuten. Dauert eine Funktion regelmäßig länger, nimm einen eingehenden Webhook und liefere das Ergebnis über eine ausgehende Verbindung aus.

Ja. Schreib die Konto-ID in den Run-Kontext, öffne Token Usage und gruppiere unter By Context nach diesem Schlüssel. Die REST-Endpunkte für Tageskosten und Agenten-Ranking unterstützen dieselbe Gruppierung, etwa mit group_by=context.account_id.

Die connic/* KI-Modelle brauchen keinen eigenen Schlüssel und werden über das Projektguthaben abgerechnet. Du kannst auch einmal pro Projekt eigene Schlüssel für Anbieter wie OpenAI, Anthropic oder Google Gemini hinterlegen oder einen eigenen OpenAI-kompatiblen Endpunkt anbinden.