API-Integration und Erzeugung von Konnektoren

Jedes Unternehmen betreibt Dutzende Systeme (ERP, CRM, DMS, HR, Shop, Bank), die Daten austauschen müssen, und jedes Paar braucht einen Konnektor, den jemand schreiben, testen und bei API-Änderungen am Leben halten muss. LLMs und Coding-Agenten können API-Spezifikationen und -Dokumentation lesen, typisierte Clients, Zuordnungen und Adapter erzeugen, Vertragstests anlegen und APIs als MCP-Server für KI-Agenten bereitstellen. Typischer Nutzen: der erste funktionierende Konnektor in Stunden statt Tagen, wobei Menschen Zuordnungen und Sicherheit prüfen.

Problem & Nutzen

• Heute: Integration macht einen großen Teil der IT-Projektarbeit aus. Entwickler lesen uneinheitliche Herstellerdokumentation, schreiben HTTP-Clients von Hand, behandeln Authentifizierung (OAuth2, API-Schlüssel, mTLS), Paginierung, Ratenbegrenzungen und Wiederholungen, ordnen Felder zwischen Datenmodellen zu und beheben Brüche, wenn ein Hersteller eine neue API-Version ausliefert. Für Systeme im „Long Tail“ (regionale ERPs, Branchensoftware, alte SOAP-Dienste) gibt es keinen fertigen Konnektor.
• Nutzen durch KI: Code-Erzeugung aus der Spezifikation, Entwurf von Feldzuordnungen aus Beispiel-Nutzdaten, Erzeugung von Tests und Mock-Servern, automatische Aktualisierungsvorschläge bei API-Änderungen und Bereitstellung bestehender APIs für LLM-Agenten über das Model Context Protocol (MCP), ohne jedes Werkzeug von Hand zu programmieren.
• Regulatorischer Sog: Der EU Data Act (anwendbar seit 12. September 2025) verpflichtet Anbieter von Cloud-/Datenverarbeitungsdiensten, Wechsel und Portabilität über offene Schnittstellen zu ermöglichen, und Hersteller vernetzter Produkte, Datenzugang bereitzustellen, was die Nachfrage nach standardisierten Konnektoren erhöht [1].
• Öffentliche, unabhängige Zahlen zu Zeitersparnissen bei der Konnektor-Erzeugung sind selten; ermitteln Sie Ihre eigene Ausgangsbasis.

Varianten

• SDK-Erzeugung aus OpenAPI (Client-Bibliotheken für API-Anbieter).
• Eigener Konnektor für iPaaS / Low-Code (Power-Platform-Konnektor, n8n-Node, Zapier-App).
• ELT-Quellkonnektoren für Datenplattformen (siehe CODE-022).
• MCP-Server, die interne und SaaS-APIs kapseln, damit Agenten sie aufrufen können (siehe AGENT-003 für den Rückfall auf Oberflächenebene).
• Alt-Adapter (SOAP/WSDL, EDI, Flat Files, Datenbank-Views), als REST gekapselt — siehe CODE-005.
• Öffentlicher Sektor: Adapter zu Registern und Portalen (z. B. XÖV-Standards, Austausch im Stil von X-Road).
• Private Nutzung: Heimautomatisierungs- oder Finanzskripte, die Verbraucher-APIs verbinden.

So funktioniert es

1. API spec / docs / sample payloads
2. ingestion & normalisation (OpenAPI lint, doc crawl, sandbox probing)
3. plan: endpoints needed, auth flow, pagination, error model
4. code generation (deterministic generator for client + LLM for glue, mapping, retries)
5. mapping proposal (source field
6. target field, transformations, confidence)
7. automated tests (contract tests against spec, mock server, sandbox run)
8. human review (mappings, scopes, secrets handling, security)
9. deploy (CI/CD, secrets vault, monitoring)
10. drift detection on spec changes

• Hybride Erzeugung ist das robuste Muster: Deterministische Generatoren (OpenAPI Generator, Kiota, Speakeasy, Stainless, Fern) erzeugen den typisierten Client; das LLM schreibt nur, was nicht mechanisch ist (fachliche Zuordnung, Orchestrierung, Sonderfälle). So vermeiden Sie erfundene Endpunkte.
• Agentenschleife: Ein Coding-Agent (siehe CODE-002) lässt den Konnektor gegen eine Sandbox laufen, liest Fehler und iteriert, bis die Vertragstests bestehen.
• MCP-Erzeugung: Werkzeuge wandeln OpenAPI-Operationen in MCP-Werkzeuge um. Eine Zuordnung von einem Werkzeug je Endpunkt überflutet oft den Modellkontext; kuratierte Werkzeuge auf Aufgabenebene oder Entwürfe mit Code-Ausführung/Suche funktionieren besser [2][3].
• Mensch-in-der-Schleife (Human-in-the-Loop): Entwickler geben Berechtigungsbereiche/Rechte, Datenzuordnungen für Finanz- oder personenbezogene Daten und Produktions-Zugangsdaten frei. Agenten erhalten Produktionsgeheimnisse nie direkt.

Datenaufbereitung

Die Eingaben sind eher API-Beschreibungen und Zieldatenmodelle als große Datensätze. Sie liegen in Herstellerportalen (HTML, PDF), OpenAPI- oder WSDL-Dateien, Schnittstellendokumentation von ERP-Systemen, alten Integrationsskripten, Wikis und in den Köpfen der Integrationsentwickler. Typische Lücken: fehlende oder veraltete Spezifikationen, Dokumentation nur als PDF, keine Sandbox-Zugangsdaten, undokumentierte Feldsemantik, unklare Zielschemata und Geheimnisse in Skripten.

Schritte der Aufbereitung: 1. Spezifikationen in einem Repository sammeln und mit Spectral prüfen; wo nur PDFs oder HTML vorliegen, diese in Markdown umwandeln oder eine OpenAPI-Datei von Hand entwerfen. 2. Sandbox-Zugang und anonymisierte Beispiel-Nutzdaten beschaffen, niemals Produktionsdaten (PREP-022). 3. Das Zielschema und die Feldbedeutungen in einem Datenwörterbuch dokumentieren (PREP-012, PREP-015). 4. Bestehende Zuordnungen und funktionierende Konnektoren als Beispiele für den Agenten sammeln (PREP-016). 5. Einen Tresor für Geheimnisse einrichten (Vault, OpenBao), damit Agenten nie Produktions-Zugangsdaten sehen. 6. Vertragstests und einen Mock-Server als Abnahmekriterien aufbauen (PREP-018).

Grober Anteil am Gesamtaufwand: 10-20 Prozent. Zum Extrahieren von Daten aus ERP- und Altsystemen siehe PREP-005 und DATA-007, für einen Bereitschaftscheck GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: B. Integrationen müssen Ihr eigenes ERP, Ihren Shop und Ihr DMS verbinden, und ein Coding-Agent mit OpenAPI Generator baut sie schneller, als auf Hersteller-Konnektoren zu warten; falls ein gepflegter Konnektor oder eine n8n-Vorlage existiert, nutzen Sie stattdessen diese.
• Großunternehmen: B. Integration ist zentral für die Systemlandschaft, Umfang und Anpassungsbedarf rechtfertigen einen Agenten in Ihrer CI-Pipeline mit internen Zuordnungs-Repositories und Prüfprozessen.
• Entwickler: B. Führende Code-Modelle mit deterministischen Generatoren und Vertragstests liefern die beste Qualität; Open-Weight-Modelle sind eine Rückfalloption.
• Öffentlicher Sektor: C. Schnittstellen zu Fachverfahren verarbeiten Bürgerdaten, und die Beschaffung bevorzugt Souveränität; daher passen Open-Weight-Code-Modelle mit selbst betriebenem n8n oder Airbyte in einer souveränen Cloud.

Weg A — Kaufen (Standardsoftware)

• iPaaS mit KI-Unterstützung: Microsoft Power Platform / Copilot Studio (eigene Konnektoren aus OpenAPI), Workato, Boomi, MuleSoft, Zapier, Make; Optionen aus der EU: SEEBURGER, Lobster und n8n (Berlin, auch selbst betreibbar), wo EU-Residenz verlangt wird.
• SDK-/MCP-Generatoren: Speakeasy, Stainless, Fern, Kiota (Microsoft, Open Source) — überwiegend für API-Anbieter.
• Baukästen für ELT-Konnektoren: Airbyte Connector Builder (KI-Assistent) sowie Fivetran/Nango für SaaS-APIs.
• A wählen, wenn: die Systeme verbreitet sind und ein gepflegter Konnektor existiert; Eigencode ist der letzte Ausweg.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Modelle: ein starkes Code-Modell — Claude (Sonnet/Opus), GPT-Klasse, Gemini oder der EU-Anbieter Mistral (Codestral / Devstral) — in einer EU-Region, sofern verfügbar.
• Werkzeuge: Coding-Agent in IDE/CLI/CI (Claude Code, Cursor, GitHub-Copilot-Agent) mit der OpenAPI-Spezifikation als Kontext, dazu OpenAPI Generator/Kiota für den typisierten Client.
• Testumgebung: Schemathesis oder Dredd für Vertragstests, Prism- oder WireMock-Mock-Server, Pact für verbrauchergetriebene Verträge.
• B wählen, wenn: Sie Entwickler haben, eigene Zuordnungen brauchen und die Spezifikation keine personenbezogenen Daten enthält.

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-Code-Modelle wie Qwen3-Coder, Devstral, die DeepSeek-Coder-V2/V3-Familie, betrieben über vLLM oder Ollama; Agenten-Umgebungen wie Aider, OpenHands, Continue, Cline.
• Stack: OpenAPI Generator, Kiota, Airbyte (selbst betrieben), n8n (selbst betrieben), offizielle MCP-SDKs (TypeScript, Python, Java, C#), HashiCorp Vault/OpenBao für Geheimnisse.
• Hardware: HW2 (GPU mit 24–32 GB) genügt für quantisierte Code-Modelle mit ca. 30B für einzelne Teams; HW3 für stärkere Agentenqualität oder viele Nutzer.

Weg D — Eigenes Training

Lohnt sich selten. Feintuning ist nur für proprietäre DSLs, EDI-Dialekte oder eine große hauseigene Integrationslandschaft (Tausende historische Zuordnungen als Trainingsdaten) in Betracht zu ziehen. Retrieval über Ihr eigenes Konnektor- Repository und die Zuordnungshistorie bringt meist den größten Teil des Gewinns.

Stand der Technik (2026)

• MCP (Ende 2024 von Anthropic eingeführt, inzwischen von großen KI-Anbietern breit übernommen und unter offener Governance geführt) ist der De-facto-Standard, um Werkzeuge und APIs für Agenten bereitzustellen; offizielle SDKs und ein Server-Verzeichnis existieren [2].
• OpenAPI 3.1/3.2 bleibt der wichtigste maschinenlesbare Vertrag; die Qualität der Spezifikation begrenzt die Qualität der Erzeugung. Schlecht beschriebene Operationen erzeugen schlechte Werkzeuge [3].
• Coding-Agenten können für gut dokumentierte REST-APIs mit Sandbox-Zugang zuverlässig Konnektoren bauen; Forschungs- und Anbieter-Benchmarks für agentisches Programmieren (z. B. SWE-bench-Varianten) zeigen starke Fortschritte, messen aber nicht den integrationsspezifischen Erfolg.
• Fehlerbilder: erfundene Endpunkte oder Parameter, wenn nur Fließtext-Dokumentation vorliegt; falsche Paginierung oder Idempotenz-Behandlung; stille Fehler bei Feldzuordnungen (Einheiten, Zeitzonen, Steuerschlüssel); unsichere Berechtigungsbereiche; Prompt Injection über API-Antworten oder Dokumentation, wenn ein Agent nicht vertrauenswürdige Inhalte verarbeitet; Versionsdrift nach Änderungen beim Hersteller.
• Gegenmuster: aus der Spezifikation erzeugen, gegen die Sandbox testen, Versionen festlegen, Schema-Drift überwachen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework): CODE-001 IDE-Assistent, CODE-002 autonome Agenten, CODE-004 Testerzeugung, CODE-021 Abhängigkeits-Updates; eine Coding-Agenten-Plattform und ein selbst betriebener Code-Modell-Server bedienen alle.
• Kombiniert sich mit: CODE-005 (Alt-Adapter/Strangler-Muster), CODE-006 (Integrationsdokumentation), CODE-009 (Bereitstellung als IaC), CODE-022 (ELT-Quellkonnektoren), DATA-004 (Scraping, wenn keine API existiert), AGENT-003 (Browser-Agenten als letzte Integrationsmöglichkeit).
• Workflow-Engine (n8n/Camunda) gemeinsam mit Anwendungsfällen der Back-Office-Automatisierung.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage; Lizenzen pro Konnektor, Aufgabe oder Benutzer.
• Weg B: 2–6 Wochen für eine Pipeline mit Leitplanken und CI; die Token-Kosten je Konnektor sind im Verhältnis zur Entwicklerzeit gering.
• Weg C: 1–3 Monate einschließlich GPU-Server und Betrieb.
• Kennzahlen: Durchlaufzeit je Konnektor, Anteil des erzeugten Codes, der unverändert gemergt wird, Fehlerquote der Zuordnungen in der Produktion, Abdeckung durch Vertragstests, mittlere Zeit bis zur Anpassung nach einer API-Änderung, Zahl der Störungen durch Integrationen.

Menschen & Veränderung

Früh einbinden: die IT (Integrationsverantwortliche und Entwickler), die Abteilungsleitung, deren Prozess angebunden wird, die Dateneigentümer der Quell- und Zielsysteme (ERP, Shop, DMS) und die IT-Sicherheit für Berechtigungsbereiche, Token und Prompt Injection (GUIDE-013). Lieferanten oder Partner, deren APIs genutzt werden, sollten über Volumen und Schlüssel informiert werden. Die Geschäftsführung genehmigt das Budget und legt fest, welche Systeme angebunden werden dürfen.

Betriebsrat: in der Regel nein. Die Erzeugung von Konnektoren ist ein Entwicklerwerkzeug und nicht zur Überwachung von Beschäftigten geeignet, daher wird §87 Abs. 1 Nr. 6 BetrVG normalerweise nicht ausgelöst. Ausnahmen: Die angebundene Schnittstelle bewegt Personal-, Zeiterfassungs- oder Leistungsdaten, oder der Coding-Assistent protokolliert einzelne Prompts von Entwicklern; dann behandeln Sie es als „kommt darauf an“. Auch ohne Mitbestimmung sollten Sie den Betriebsrat nach §90 Abs. 1 Nr. 3 früh informieren, wo Arbeitsprozesse mit KI geplant werden, was Vertrauen schafft (GUIDE-004). Öffentlicher Sektor: Personalrat informieren.

Datenschutz: Die Spezifikation selbst ist nicht personenbezogen, die Zuordnungen von Kunden-, Beschäftigten- oder Patientendaten aber schon. Beziehen Sie die/den Datenschutzbeauftragte(n) ein, schließen Sie mit dem Modellanbieter einen AVV, dokumentieren Sie die Rechtsgrundlage für den Datenfluss und führen Sie eine DSFA durch, wenn sensible Daten in großem Umfang zugeordnet werden (GUIDE-005).

KI-Kompetenz: Schulen Sie Entwickler darin, erzeugte Zuordnungen zu prüfen, erfundene Endpunkte zu erkennen und Geheimnisse richtig zu behandeln (GUIDE-006).

Pilot und Kommunikation: Wählen Sie eine unkritische Integration und eine kleine Entwicklergruppe, mit Go/No-go-Kriterien auf Grundlage bestandener Vertragstests (GUIDE-009). Eine typische Sorge betrifft Qualität und Verantwortung für erzeugten Code; begegnen Sie ihr mit verpflichtender menschlicher Prüfung von Berechtigungsbereichen und Zuordnungen (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für Entwicklerwerkzeuge; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Speisen erzeugte Integrationen Systeme nach Anhang III (z. B. Personalwesen, Bonitätsbewertung), trägt das nachgelagerte System die Hochrisiko-Pflichten, nicht der Generator.
• DSGVO: Erzeugte Zuordnungen bewegen personenbezogene Daten zwischen Systemen — dokumentieren Sie Zwecke, Rechtsgrundlage und Auftragsverarbeiter (Art. 28, 30); senden Sie keine echten Kundendaten an Modell-APIs außerhalb der EU; nutzen Sie synthetische Beispiele; minimieren Sie Daten in Logs.
• Data Act / Verträge: Prüfen Sie Nutzungsbedingungen der API, Ratenbegrenzungen und Lizenzbeschränkungen, bevor Sie Daten scrapen oder per Reverse Engineering ableiten; Zugangsrechte nach dem Data Act können bei vernetzten Produkten helfen [1].
• Sicherheit: OAuth-Berechtigungsbereiche mit minimalen Rechten, Geheimnisse in einem Tresor, SBOM und Abhängigkeitsprüfung des erzeugten Codes, Prüfung nach den OWASP API Security Top 10, menschliche Abnahme vor der Produktion; behandeln Sie für Agenten zugängliche MCP-Server als Angriffsfläche (Tool Poisoning, zu weit gefasste Rechte) [2]. Beziehen Sie bei NIS2-/DORA-regulierten Einrichtungen die Integrationen in das Drittanbieter- und Änderungsmanagement ein.
• Cyber Resilience Act: Produkte mit digitalen Elementen, die in der EU verkauft werden, müssen Sicherheitsanforderungen erfüllen; erzeugter Code braucht dieselbe Behandlung von Schwachstellen.

Erste Schritte

1. Erfassen Sie die wichtigsten Integrationen und wählen Sie eine gut dokumentierte REST-API mit Sandbox.
2. Prüfen Sie die OpenAPI-Spezifikation; erzeugen Sie einen typisierten Client deterministisch und lassen Sie dann einen Agenten Zuordnung und Verbindungscode schreiben.
3. Ergänzen Sie Vertragstests und einen Mock-Server vor dem ersten Produktionsaufruf.
4. Stellen Sie den Konnektor als MCP-Server mit wenigen Werkzeugen auf Aufgabenebene und Berechtigungsbereichen mit minimalen Rechten bereit.
5. Verfolgen Sie Durchlaufzeit und Fehler; ergänzen Sie in der CI eine Überwachung auf Schema-Drift.

Quellen

1. Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
2. Model Context Protocol — specification and docs — https://modelcontextprotocol.io/specification
3. Stainless — Generate MCP servers from OpenAPI specs — https://www.stainless.com/docs/mcp
4. Speakeasy — Standalone MCP server generation — https://www.speakeasy.com/docs/standalone-mcp
5. OpenAPI Initiative — OpenAPI Specification — https://spec.openapis.org/oas/latest.html
6. Microsoft Kiota — https://github.com/microsoft/kiota
7. OpenAPI Generator — https://github.com/OpenAPITools/openapi-generator
8. Garrigues — Data Act and cloud switching — https://www.garrigues.com/en_GB/garrigues-digital/data-act-and-cloud-switching-keys-new-rules-changing-cloud-service-providers
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj