Warum 56 und nicht "wir machen Zapier"
Es gibt zwei verbreitete Antworten auf das Integrationsproblem. Die erste: man bietet eine Handvoll exzellenter, tief integrierter Konnektoren an und sagt allen anderen Nutzern höflich, dass ihre Tools "leider noch nicht unterstützt" werden. Die zweite: man baut eine riesige, generische iPaaS-Schicht mit 5.000 Konnektoren, von denen 4.700 nur Read-Operations beherrschen.
Wir haben uns für einen dritten Weg entschieden. ORCONIC führt heute 56 Integrationen im Katalog — jede als First-Class-Eintrag in unserer Tool-Registry: typisiert, sandboxed, auditierbar, vom Workflow-DAG aufrufbar und durch Approval-Gates absicherbar. Ein Kern-Set (u. a. Gmail, Slack, HubSpot, Salesforce, Pipedrive, Notion, Jira) bietet vollständigen Zwei-Wege-Sync; weitere Konnektoren sind per OAuth angebunden und werden laufend produktiv geschaltet.
Der Trick: alle 56 teilen sich genau drei Bausteine.
Baustein 1: Die Tool-Registry
Im Kern jeder Integration steht ein Tool-Descriptor. Pseudo-TypeScript:
interface ToolDescriptor {
id: string; // "slack.message.send"
scope: "workspace" | "user";
inputSchema: JsonSchema; // Zod-generiert
outputSchema: JsonSchema;
handler: (input, ctx) => Promise<Output>;
costEstimate?: (input) => number;
sideEffects: "none" | "external-write" | "external-read";
requiresApproval?: (input, ctx) => boolean;
}Ein Slack-Tool, ein DATEV-Tool und ein Stripe-Refund-Tool sehen aus Sicht der Registry identisch aus. Der Workflow-DAG, der Agent-Executor und das Audit-Subsystem wissen nichts über Slack oder Stripe — sie wissen nur, dass tool.handler(input, ctx) aufgerufen wird, dass ctx.audit.record(...) läuft, und dass requiresApproval über einen Gate entscheidet.
Baustein 2: Die OAuth-Schicht
OAuth ist die Hölle, wenn man jeden Provider neu durchimplementiert. Wir haben deshalb ein gemeinsames provider.ts-Modul gebaut, das die wiederkehrenden Muster kapselt:
- PKCE für public clients
- Refresh-Token-Rotation mit Schreibsperre
- Verschlüsselung der Tokens at rest via libsodium (siehe
lib/security/oauth-crypto.ts) - Webhook-Signatur-Verifikation pro Provider
- Rate-Limit-aware Retry mit Token-Bucket
Konkret: für eine neue Integration schreiben wir nur noch das Provider-Spezifische — Endpoints, Scopes, Signatur-Algorithmus —, alles Generische wird vererbt. Das Ergebnis: HubSpot lag in 1,5 Tagen drauf, Pipedrive in einem Tag, Klaviyo in einem halben.
Baustein 3: Health-Probes
Jede Integration hat eine Health-Probe, die einmal pro Stunde läuft und folgendes prüft:
- Können wir uns mit gespeicherten Credentials authentifizieren?
- Antwortet der Status-Endpoint des Providers?
- Ist unser Webhook-Endpoint vom Provider erreichbar?
- Liegen ausstehende Webhook-Events in der Queue ungelesen über dem Schwellwert?
Wenn eine Probe fehlschlägt, landet der Workspace im Degraded-Modus für diese Integration: Workflows pausieren elegant, statt mit kryptischen 401ern abzustürzen, und der Nutzer sieht im Dashboard ein klares "Slack-Token muss erneuert werden — hier klicken".
Wo die Integrationen wirklich greifen
Die spannenden Effekte ergeben sich erst, wenn mehrere Integrationen in derselben Workflow-Lauf orchestriert werden. Drei Beispiele aus echten Beta-Kunden:
Lead-Routing
Eingehende Lead-Submission über das Webseiten-Formular → Klassifikation durch Inbox-Rules-Engine → Anreicherung über Clearbit → Anlage in Pipedrive und HubSpot (Dual-Sync für Migrations-Phase) → Slack-Notification an Sales-Channel → Termin-Slot über Cal.com → Bestätigungs-E-Mail über SendGrid mit personalisierten Tracking-Links.
Sieben Integrationen, ein Workflow, durchschnittlich 4,2 Sekunden End-to-End-Latenz inklusive aller externen API-Calls.
Rechnungs-Eingang
E-Mail-Eingang mit PDF-Anhang → OCR-Extraktion über GPT-4-Vision → Validierung gegen Lieferanten-Whitelist → Buchungsvorschlag in DATEV mit Kostenstellen-Vorschlag → Approval-Gate an Buchhaltung → bei Freigabe Buchung in DATEV plus Markierung in CRM → Zahlungsempfehlung an Banking-Tool.
Was hier zählt: die einzelne LLM-Komponente macht nur OCR und Buchungsvorschlag. Alles andere ist deterministischer Code, der nachvollziehbar protokolliert wird.
Support-Auto-Reply
Ticket-Eingang über Front oder Help Scout → Klassifikation in eine von 12 Kategorien → bei "Known Issue" automatische Antwort mit Cooldown-Logik → bei "Refund-Request" Approval-Gate plus Stripe-Refund-API-Call → bei "Bug-Report" Linear-Issue-Erstellung mit verlinktem Ticket.
Was wir gelernt haben
- Schema-Drift ist real. Provider ändern Felder ohne Vorwarnung. Wir validieren jede Antwort gegen unser Zod-Schema und schicken Schema-Drift-Alerts an unseren internen Channel, bevor Kunden es merken.
- Webhooks lügen. Slack liefert ein Event manchmal dreimal, Stripe immer mit Verzögerung, Mailchimp mit Idempotency-Keys, die nicht idempotent sind. Wir deduplizieren alles am Eingang über eine Redis-basierte Bloom-Filter-Schicht.
- Rate-Limits sind Politik. HubSpot ist großzügig, Salesforce ist streng, Notion ist undokumentiert. Unsere Token-Buckets pro Tenant und pro Provider verhindern, dass ein lauter Workspace alle anderen lahmlegt.
- "Approval Required" rettet Vertrauen. Wir haben gelernt: Wenn der Agent einen Refund auslöst, ohne dass jemand explizit Ja gesagt hat, ist das nicht "schnelle Automatisierung", sondern ein Compliance-Verstoß. Approval-Gates sind nicht optional.
Was kommt als Nächstes
Der Marketplace selbst öffnet im Juli — dann können Drittanbieter ihre eigenen Tool-Descriptors einreichen und nach unserer Sicherheits-Review live schalten. Bis dahin: wenn euch eine der bisherigen 56 fehlt, schreibt uns. Wir bauen sie wahrscheinlich schneller, als ihr denkt.