Every company runs dozens of systems (ERP, CRM, DMS, HR, shop, banking) that must exchange data, and every pair needs a connector that someone has to write, test and keep alive as APIs change. LLMs and coding agents can read API specifications and documentation, generate typed clients, mappings and adapters, create contract tests and expose APIs to AI agents as MCP servers. Typical benefit: the first working connector in hours instead of days, with humans reviewing mappings and security.
Problem & value
- Today: integration is a large share of IT project work. Developers read inconsistent vendor docs, hand-write HTTP clients, handle authentication (OAuth2, API keys, mTLS), pagination, rate limits and retries, map fields between data models and fix breakage when a vendor ships a new API version. Long-tail systems (regional ERPs, industry software, legacy SOAP services) have no ready connector.
- AI value: spec-to-code generation, drafting of field mappings from sample payloads, generation of tests and mock servers, automatic update proposals on API changes, and exposing existing APIs to LLM agents via the Model Context Protocol (MCP) without hand-coding each tool.
- Regulatory pull: the EU Data Act (applicable since 12 Sept 2025) requires cloud/data-processing providers to enable switching and portability via open interfaces, and connected-product makers to provide data access, which increases demand for standardised connectors [1].
- Public, independent figures on time savings for connector generation are scarce; measure your own baseline.
Variants
- SDK generation from OpenAPI (client libraries for API providers).
- Custom connector for iPaaS / low-code (Power Platform custom connector, n8n node, Zapier app).
- ELT source connectors for data platforms (see CODE-022).
- MCP servers wrapping internal and SaaS APIs so agents can call them (see AGENT-003 for UI-level fallback).
- Legacy adapters (SOAP/WSDL, EDI, flat files, database views) wrapped as REST — see CODE-005.
- Public sector: adapters to registries and portals (e.g. XÖV standards, X-Road style exchange).
- Private use: home-automation or personal-finance scripts that glue consumer APIs.
How it works
- API spec / docs / sample payloads
- ingestion & normalisation (OpenAPI lint, doc crawl, sandbox probing)
- plan: endpoints needed, auth flow, pagination, error model
- code generation (deterministic generator for client + LLM for glue, mapping, retries)
- mapping proposal (source field
- target field, transformations, confidence)
- automated tests (contract tests against spec, mock server, sandbox run)
- human review (mappings, scopes, secrets handling, security)
- deploy (CI/CD, secrets vault, monitoring)
- drift detection on spec changes
- Hybrid generation is the robust pattern: deterministic generators (OpenAPI Generator, Kiota, Speakeasy, Stainless, Fern) produce the typed client; the LLM writes only what is not mechanical (business mapping, orchestration, edge cases). This avoids hallucinated endpoints.
- Agentic loop: a coding agent (see CODE-002) runs the connector against a sandbox, reads errors and iterates until contract tests pass.
- MCP generation: tools convert OpenAPI operations into MCP tools. A one-tool-per-endpoint mapping often floods the model context; curated, task-level tools or code-execution/search tool designs work better [2][3].
- Human-in-the-loop: developers approve scopes/permissions, data mappings for financial or personal data, and production credentials. Agents never receive production secrets directly.
Data preparation
The inputs are API descriptions and target data models rather than large datasets. They live in vendor portals (HTML, PDF), OpenAPI or WSDL files, ERP interface documentation, old integration scripts, wikis and the heads of integration developers. Typical gaps: missing or outdated specs, PDF-only documentation, no sandbox credentials, undocumented field semantics, unclear target schemas, and secrets in scripts.
Preparation steps: 1. Collect specs in one repository and lint them (Spectral); where only PDFs or HTML exist, convert them to Markdown or draft an OpenAPI file by hand. 2. Obtain sandbox access and anonymised sample payloads, never production data (PREP-022). 3. Document the target schema and field meanings in a data dictionary (PREP-012, PREP-015). 4. Gather existing mappings and working connectors as examples for the agent (PREP-016). 5. Set up a secrets vault (Vault, OpenBao) so agents never see production credentials. 6. Build contract tests and a mock server as acceptance criteria (PREP-018).
Rough share of total effort: 10-20 percent. For extracting data from ERP and legacy systems see PREP-005 and DATA-007, and use GUIDE-003 for a readiness check.
Implementation paths
Which path for whom
- SMB: B. Integrations must connect your own ERP, shop and DMS, and a coding agent with OpenAPI Generator builds them faster than waiting for vendor connectors; if a maintained connector or n8n template exists, use that instead.
- Enterprise: B. Integration is core to the estate, volume and customisation justify an agent in your CI pipeline with internal mapping repositories and review processes.
- Developer: B. Frontier code models with deterministic generators and contract tests give the best quality; open-weight models are a fallback.
- Public sector: C. Interfaces to specialist procedures handle citizen data and procurement favours sovereignty, so open-weight code models with self-hosted n8n or Airbyte on a sovereign cloud fit.
Path A — Buy (off-the-shelf)
- iPaaS with AI assistance: Microsoft Power Platform / Copilot Studio (custom connectors from OpenAPI), Workato, Boomi, MuleSoft, Zapier, Make; EU-based options: SEEBURGER, Lobster, and n8n (Berlin, also self-hostable) where EU residency is required.
- SDK / MCP generators: Speakeasy, Stainless, Fern, Kiota (Microsoft, open source) — mostly for API providers.
- ELT connector builders: Airbyte Connector Builder (AI assistant) and Fivetran/Nango for SaaS APIs.
- Choose A when: the systems are popular and a maintained connector exists; custom code is a last resort.
Path B — Build on cloud APIs (recommended)
- Models: a strong code model — Claude (Sonnet/Opus), GPT-class, Gemini, or EU provider Mistral (Codestral / Devstral) — in an EU region where available.
- Tooling: coding agent in IDE/CLI/CI (Claude Code, Cursor, GitHub Copilot agent) with the OpenAPI spec as context, plus OpenAPI Generator/Kiota for the typed client.
- Test harness: Schemathesis or Dredd for contract tests, Prism or WireMock mock servers, Pact for consumer-driven contracts.
- Choose B when: you have developers, need custom mappings, and the spec contains no personal data.
Path C — Self-host (open source)
- Models: open-weight code models such as Qwen3-Coder, Devstral, DeepSeek-Coder-V2/V3 family, served via vLLM or Ollama; agent harnesses such as Aider, OpenHands, Continue, Cline.
- Stack: OpenAPI Generator, Kiota, Airbyte (self-hosted), n8n (self-hosted), official MCP SDKs (TypeScript, Python, Java, C#), HashiCorp Vault/OpenBao for secrets.
- Hardware: HW2 (24–32 GB GPU) suffices for ~30B quantised code models for single teams; HW3 for stronger agentic quality or many users.
Path D — Custom training
Rarely worthwhile. Consider fine-tuning only for proprietary DSLs, EDI dialects or a large in-house integration estate (thousands of historic mappings as training data). Retrieval over your own connector repository and mapping history usually gives most of the gain.
State of the art (2026)
- MCP (introduced by Anthropic in late 2024, now broadly adopted by major AI vendors and hosted under open governance) is the de-facto standard for exposing tools and APIs to agents; official SDKs and a server registry exist [2].
- OpenAPI 3.1/3.2 remains the primary machine-readable contract; quality of the spec bounds quality of generation. Poorly described operations produce poor tools [3].
- Coding agents can reliably build connectors for well-documented REST APIs with sandbox access; research and vendor benchmarks for agentic coding (e.g. SWE-bench variants) show strong progress but do not measure integration-specific success.
- Failure modes: hallucinated endpoints or parameters when only prose docs are available; wrong pagination or idempotency handling; silent field-mapping errors (units, time zones, tax codes); insecure scopes; prompt injection via API responses or docs when an agent consumes untrusted content; version drift after vendor changes.
- Mitigation pattern: generate from the spec, test against sandbox, pin versions, monitor schema drift.
Shared resources & combinations
- Same stack (llm-code + agent-framework): CODE-001 IDE assistant, CODE-002 autonomous agents, CODE-004 test generation, CODE-021 dependency upgrades; one coding-agent platform and one self-hosted code-model server serve all.
- Combines with: CODE-005 (legacy adapters/strangler pattern), CODE-006 (integration documentation), CODE-009 (deployment as IaC), CODE-022 (ELT source connectors), DATA-004 (scraping when no API exists), AGENT-003 (browser agents as last-resort integration).
- Workflow engine (n8n/Camunda) shared with back-office automation use cases.
Effort, cost & KPIs
- Path A: days; licences per connector, task or user.
- Path B: 2–6 weeks for a pipeline plus guardrails and CI; token cost per connector is small relative to developer time.
- Path C: 1–3 months incl. GPU server and ops.
- KPIs: lead time per connector, share of generated code merged unchanged, mapping error rate in production, contract-test coverage, mean time to adapt after API change, incident count from integrations.
People & change
Involve early: IT (integration owner and developers), the department lead whose process is connected, data owners of the source and target systems (ERP, shop, DMS), and IT security for scopes, tokens and prompt injection (GUIDE-013). Suppliers or partners whose APIs are used should be informed about volumes and keys. Management approves budget and which systems may be connected.
Works council: no, usually. Connector generation is a developer tool and not suited to monitoring employees, so §87(1) no. 6 BetrVG is normally not triggered. Exceptions: the connected interface moves HR, time-tracking or performance data, or the coding assistant logs individual developer prompts; then treat it as "depends". Even without co-determination, inform the works council early under §90(1) no. 3 where work processes are planned with AI, which builds trust (GUIDE-004). Public sector: inform the Personalrat.
Data protection: the spec itself is not personal, but mappings of customer, employee or patient data are. Involve the DPO, conclude an AVV with the model provider, document the legal basis for the data flow, and run a DPIA when sensitive data is mapped at scale (GUIDE-005).
AI literacy: train developers on reviewing generated mappings, hallucinated endpoints and secret handling (GUIDE-006).
Pilot and communication: pick one non-critical integration and a small developer group, with go/no-go criteria from passing contract tests (GUIDE-009). A typical concern is quality and accountability for generated code; address it with mandatory human review of scopes and mappings (GUIDE-008).
Risks, regulation & compliance
- EU AI Act: minimal risk for developer tooling; AI literacy (Art. 4) applies. If generated integrations feed Annex III systems (e.g. HR, credit scoring), the downstream system carries the high-risk obligations, not the generator.
- GDPR: generated mappings move personal data between systems — document purposes, legal basis and processors (Art. 28, 30); avoid sending real customer payloads to non-EU model APIs; use synthetic samples; minimise data in logs.
- Data Act / contracts: check API terms of use, rate limits and licence restrictions before scraping or reverse-engineering; Data Act access rights may help for connected products [1].
- Security: least-privilege OAuth scopes, secrets in a vault, SBOM and dependency review of generated code, OWASP API Security Top 10 review, human sign-off before production; treat agent-accessible MCP servers as an attack surface (tool poisoning, over-broad permissions) [2]. For NIS2/DORA-regulated entities include integrations in third-party and change management.
- Cyber Resilience Act: products with digital elements sold in the EU must meet security requirements; generated code needs the same vulnerability handling.
Getting started
- Inventory top integrations and pick one well-documented REST API with a sandbox.
- Lint the OpenAPI spec; generate a typed client deterministically, then let an agent write mapping and glue code.
- Add contract tests and a mock server before the first production call.
- Expose the connector as an MCP server with a few task-level tools and least-privilege scopes.
- Track lead time and defects; add schema-drift monitoring in CI.
Sources
- Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
- Model Context Protocol — specification and docs — https://modelcontextprotocol.io/specification
- Stainless — Generate MCP servers from OpenAPI specs — https://www.stainless.com/docs/mcp
- Speakeasy — Standalone MCP server generation — https://www.speakeasy.com/docs/standalone-mcp
- OpenAPI Initiative — OpenAPI Specification — https://spec.openapis.org/oas/latest.html
- Microsoft Kiota — https://github.com/microsoft/kiota
- OpenAPI Generator — https://github.com/OpenAPITools/openapi-generator
- 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
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj