superglue

superglue is an integration platform that lets AI agents build and run the API connections, ERP/CRM migrations, and data pipelines that would normally require a developer writing bespoke connector code. Instead of hand-wiring calls to Salesforce, NetSuite, Postgres, or a long-tail internal API, a user or agent describes the integration in natural language, and superglue generates the schema, authentication flow, and transformation logic needed to call it.

Under the hood, superglue ships a large catalog of pre-built connector templates (packages/shared/templates.ts) covering common systems like Salesforce, NetSuite, Stripe, and Postgres, with auto-detected auth types (OAuth, API key, basic, connection string) via regex matching. For systems without a template, a documentation-discovery pipeline takes over: it tries OpenAPI (direct URL, HTML link extraction, SwaggerHub, Swagger UI), GraphQL introspection, llms.txt, or a Playwright-rendered scrape of the docs site, then an LLM turns whatever it finds into a callable tool.

Generated tools and multi-step workflows don’t run inside the main Node process — they execute in isolated Deno subprocesses managed by a worker pool, communicating with the host over a MessagePack-encoded IPC channel. The Deno runtime dispatches to per-protocol strategy modules (HTTP, Postgres, Redis, FTP, SMB, MSSQL, and data transforms) and applies response filtering and schema validation before returning results. Every generated tool is also exposed over the Model Context Protocol, so MCP-native agents like Claude can call the same tools a REST client would use, and a Next.js web app provides a chat-based agent UI plus dashboards for systems, tools, and run history.

superglue can be self-hosted via Docker Compose (with Postgres and MinIO) or used as a hosted cloud service, and is backed by Y Combinator (W25). The core codebase is licensed under the Functional Source License (FSL-1.1-Apache-2.0) — source-available rather than OSI-approved open source — while the separate client SDKs are MIT licensed.

What You Get

• A natural-language tool builder that turns a plain-English description of an API, ERP, CRM, or database into a production-ready tool with generated schema, auth flow, and transformation logic
• A large catalog of pre-built connector templates for common systems (Salesforce, NetSuite, Stripe, Postgres, and more) with auto-detected auth types and connection fields
• An automatic documentation-discovery pipeline (OpenAPI, GraphQL introspection, llms.txt, Playwright-based scraping) for systems that don’t have a template
• A sandboxed Deno execution runtime that runs generated transformations and multi-step workflows (HTTP, Postgres, Redis, FTP, SMB, MSSQL steps) outside the main process
• An MCP server so agents like Claude can call generated tools directly, alongside a REST/GraphQL API and JS/Python client SDKs
• A web app with a conversational agent UI plus dedicated screens for managing systems, tools, and run history, with role-based access rules and org-scoped API keys

Common Use Cases

• ERP and accounting migrations (Sage Intacct, NetSuite, SAP, Business Central, Acumatica) — describing field mappings in natural language instead of hand-built spreadsheet transforms
• Connecting internal databases, CRMs, and ticketing systems to AI agents or copilots with governed, role-scoped tool access
• Customer onboarding across heterogeneous tech stacks — one integration layer instead of a bespoke connector per CRM, notetaker, or ticketing system
• Long-tail API integrations that don’t justify a dedicated iPaaS connector, generated from documentation instead of hand-coded
• Business users self-serving lightweight integrations through the web UI or agent chat without filing an engineering ticket

Under The Hood

Architecture superglue is organized as an npm/Turborepo monorepo split into a core service (Fastify REST API, MCP server, Postgres-backed datastore, and a sandboxed execution runtime), a Next.js web app, a shared package of types and connector templates, and JS/Python client SDKs. The core boots by validating environment configuration, creating a Postgres-backed datastore, bootstrapping open-source seed data, initializing worker pools, and starting the Fastify server, which wires a preHandler hook that extracts and validates auth tokens, resolves roles, and evaluates route-level access rules before dispatching to handlers registered through a plugin-style module registry. Actual workflow execution is deliberately pulled out of the main Node process: a worker pool spawns Deno subprocesses and exchanges workflow payloads over a binary IPC channel with a runtime that dispatches to per-protocol strategy modules (HTTP, Postgres, Redis, FTP, SMB, MSSQL, transform) before applying response filters and schema validation. System and connector metadata flows through a manager class that lazily fetches configuration and documentation, memoizing in-flight requests to avoid duplicate work. Separation of concerns is clean at the package boundary — orchestration and auth live in Node, step execution is isolated in Deno, and templates and types are centralized in a shared package — though authorization logic is spread across several cooperating modules, so a change to the module registry, the Deno IPC contract, or the system-manager’s lazy-fetch pattern would ripple through most of the request path.

Tech Stack The core service runs on TypeScript over Node.js using Fastify for the REST API, with Express reserved for the Model Context Protocol transport, and Vercel’s AI SDK (plus an Amazon Bedrock provider) abstracting LLM calls behind a swappable provider setting. Data persistence combines Postgres with a lightweight custom datastore abstraction, Redis for caching and queuing, and S3-compatible object storage backed by a self-hostable MinIO container. Sandboxed workflow execution runs on Deno, communicating with the Node host over a compact binary messaging format. Authentication layers a dedicated auth library with JWT handling, and the connector surface pulls in dedicated clients for relational databases, FTP/SFTP/SMB file transfer, and browser automation for scraping documentation pages, alongside schema and validation libraries for turning arbitrary API shapes into typed tools. Build and deployment are orchestrated with Turborepo across npm workspaces, packaged via a multi-stage Docker build and a Compose file with optional infrastructure profiles, and gated by continuous integration for linting, testing, and container publishing. The web app is a Next.js dashboard built on shadcn/Radix primitives, and client SDKs are offered for both JavaScript and Python.

Code Quality Testing is done with Vitest, with test files colocated next to the source they cover across the core and shared packages. A sampled suite for the access-rule evaluator favors small test-data builders and explicit per-branch assertions with descriptive ‘should X when Y’ naming over snapshot testing, suggesting deliberate behavioral coverage rather than incidental smoke tests. Error handling is centralized through a shared error-response helper and a global Fastify error handler rather than raw throws inside route handlers, matching an explicit convention documented in the project’s own contributor notes. Typing is consistent throughout, with schema-validation libraries checking API boundaries, though the base TypeScript configuration does not enable strict mode. Formatting is enforced via Prettier rather than a dedicated linter, and continuous integration runs dedicated lint and test workflows alongside separate container-publishing and open-source-sync pipelines. Overall this reads as a codebase with genuine behavioral test coverage and enforced formatting and CI discipline, held back somewhat by the absence of strict-mode typing and a proper linter.

What Makes It Unique The most distinctive engineering decision is executing LLM-generated integration and transformation code inside isolated Deno subprocesses rather than evaluating it inline in the host process — workflow payloads are handed to a runtime that dispatches to per-protocol strategy modules and applies response filtering and schema validation before returning results, giving agent-authored code a real process boundary instead of ad hoc in-process sandboxing. The second notable piece is a hybrid connector-acquisition strategy: a large hand-maintained template catalog with auto-detection and typed auth flows covers common systems, while unknown systems fall back to a documentation-discovery pipeline that tries OpenAPI, GraphQL introspection, llms.txt, or a Playwright-rendered scrape, letting an LLM synthesize a callable tool only when no template exists. Exposing every generated tool over the Model Context Protocol means the same tool a REST client calls can be picked up directly by MCP-native agents, collapsing what would otherwise be a separate integration layer. None of these techniques is individually unprecedented, but the combination — templates-first reliability, LLM-driven fallback discovery, process-isolated execution, and native agent tool exposure — is a coherent, non-generic response to letting an agent safely build and run its own integrations.

Self-Hosting

Licensing Model superglue’s core codebase is source-available under the Functional Source License (FSL-1.1-Apache-2.0), confirmed by reading the repository’s LICENSE file — this is not an OSI-approved open-source license. You may use, self-host, modify, and redistribute the code for any Permitted Purpose, which excludes operating the software (or a close derivative) as a commercial product or service that competes with superglue itself. Under the license’s ‘Grant of Future License’, each release automatically converts to the permissive Apache License 2.0 two years after its publication date. Separately, per the README, the client SDKs (the JS @superglue/client package and the Python client) are MIT licensed, so integrating against superglue from application code carries no FSL restrictions.

Self-Hosting Restrictions No source-level license-key gating was found: grepping the codebase for license-check, feature-flag, or ‘isPro’/‘isEnterprise’ style patterns turned up nothing. The repository does contain directories labeled ee (e.g. packages/core/api/ee, packages/core/datastore/ee) covering API-key scoping and multi-tenant permission hooks, but in this public repository those hooks default to allowing everything unless an additional module overrides them, so a self-hosted instance runs with the same permission logic the code ships with — no restricted functionality was found gated behind a paid tier.

Enterprise Features The README does not publish a separate paid feature list. The only documented choice is between signing up for the hosted app at app.superglue.cloud or self-hosting via Docker Compose; no enterprise-only capabilities are described in the materials available in this repository.

Cloud vs Self-Hosted Not clearly documented in the repository itself — the README presents cloud and self-hosted as parallel ‘Quick Start’ options without listing feature differences between them. Full details are referenced as living in superglue’s external documentation site, which is out of scope for this analysis.

License Key Required No. Nothing in the source requires a license key to run; self-hosting only needs the environment variables listed in .env.example (LLM provider credentials, Postgres, and MinIO/S3 configuration).