superglue: natural-language integration layer with an FSL licence and no published install path

The gap superglue is aimed at: long-tail systems nobody wants to write a connector for

Most integration platforms assume the systems on both ends are popular. Salesforce, Stripe, Slack and Postgres have maintained connectors in every iPaaS catalogue. The expensive work sits elsewhere: an ERP migration for a single client, a university's fundraising database, a construction system with a SOAP endpoint and no SDK. The README frames this directly, contrasting manual Excel transforms with 10 to 15 cleanup iterations per general ledger history and roughly 140 hours on one project against describing the mapping in plain English. Those figures come from the project's own comparison table, not from independent measurement. Treat them as the vendor's claim about the shape of the problem, which is credible, rather than as a benchmark. The audience is narrow and identifiable: implementation consultants, ERP migration teams, platform engineers wiring internal systems into AI agents, and anyone whose job is a series of one-off integrations rather than one integration maintained forever.

What the repository actually contains and what it does not

The repository is TypeScript, licensed as NOASSERTION at the metadata level, and the README resolves that by stating superglue is FSL licensed while the client SDKs are MIT licensed. FSL is the Functional Source Licence, which restricts competing commercial use until a change date, after which the code converts to an open source licence. The README does not state the change date or the permitted-use terms, and the LICENSE file is referenced but not reproduced in the material available here. That is the single largest gap for anyone doing procurement. The README also gives no install commands. Quick Start offers two options: sign up at app.superglue.cloud, or follow the self-host link at docs.superglue.cloud/getting-started/setup#self-hosted. There is a Docker image at superglueai/superglue and an npm package at @superglue/client, both visible as badges, but the README does not show how to invoke either. If you need to evaluate this without leaving the repository, you cannot. That is a deliberate choice by the maintainers and it should factor into your evaluation cost.

How the mechanism is described: knowledge in, tools out

The stated mechanism is that superglue learns how your systems work from your company's knowledge, then performs implementation work that would otherwise need human coordination. The README's phrasing is that it builds integrations and tools from natural language and produces production-grade tools for long tail and enterprise systems. The topics list confirms the shape of the output: function-calling, MCP, OAuth2, api-connector, api-orchestration, transformations. So the artefact you get is not a diagram or a mapping document. It is a callable tool, exposed through function calling or MCP, that an agent can invoke against a real system with real credentials. The supported-systems list is broad by design: REST, GraphQL, SOAP, file-based and database systems, with named coverage across ERP, CRM, databases, project management, payments, HR, DevOps, analytics, marketing, file protocols and identity. The README's closing line is that it works with any system with an API, database, or file connection. That claim is unfalsifiable as written and you should test it against your worst system, not your best one. The architecture beyond this is not visible in the supplied material, so any statement about how mappings are stored, versioned or replayed would be speculation.

Getting it running: what the material supports and what it leaves to the docs

The repository gives you two entry points and no commands. The hosted path is a signup at app.superglue.cloud. The self-hosted path is a documentation link, and the README's own description of that option is maximum control and customization, which is a marketing phrase rather than a specification. Concretely, what you can verify from the repository alone is that a Docker image is published as superglueai/superglue and a client SDK is published on npm as @superglue/client. Everything else, including environment variables, database requirements, OAuth callback configuration and the shape of the config file, lives outside the repository. For a self-hosted integration tool this matters more than usual, because the setup surface is where credential handling gets decided. A tool that holds OAuth2 tokens for Salesforce, NetSuite and Stripe needs its secret storage documented before anything else. The README does not address it. Budget an hour reading docs.superglue.cloud before you budget any time on the actual integration.

The trade-offs the README does not discuss

Natural-language integration generation moves the failure mode. A hand-written connector fails loudly, at a known line, when an upstream API changes shape. A generated mapping fails quietly, by producing a plausible value in the wrong field, and the README gives no description of validation, dry-run or diffing before a mapping is applied to production data. For a general ledger migration that is the difference between a bad afternoon and a restated quarter. The second undocumented area is determinism. If the same plain-English description can produce different tool definitions on different runs, you have a reproducibility problem in anything that touches audit. The third is scope. The README lists a very long set of supported systems, which is a claim about breadth, and breadth in integration tooling usually comes at the cost of depth on the awkward parts: pagination quirks, rate limits, eventual consistency, and the vendor-specific fields that never appear in the public API docs. Nothing in the material says how those are handled. The fourth is the licence itself. FSL is source-available, not open source, until the change date. If your organisation has a blanket policy against non-OSI licences, this project fails that check before any technical evaluation begins.

Where a deterministic framework is the better answer

Airbyte is the honest comparison point, and the difference is not quality, it is where the intelligence sits. Airbyte connectors are hand-written and versioned: a Salesforce source is code, reviewed and released, and it behaves identically on every run. superglue generates the connector from a description, which is what lets it reach systems that will never have a maintained connector. The trade is determinism for coverage. If your integration is one well-known SaaS API and you need byte-identical behaviour across runs, Airbyte's model is the safer one and superglue's flexibility buys you nothing. If your integration is a client's Sage Intacct instance with a bespoke chart of accounts and a legacy export format, no connector catalogue will have it, and generation is the only path that does not start with three weeks of reading SOAP schemas. The same logic applies against writing the connector yourself. For a single stable API, a few hundred lines of TypeScript is a known quantity with a known maintenance cost. superglue's value appears when the count of one-off integrations is high enough that per-connector engineering time dominates.

Maintenance, licence and the questions to settle before adoption

The repository was last pushed on 2026-08-19 and is not archived, so it is actively maintained at the time of writing. No releases were retrieved, which means there is no changelog in the material to judge upgrade cadence or breaking-change history. For a tool that sits between your production systems and their credentials, upgrade cadence is not a minor detail. The licence position is the clearest thing you can act on: FSL for the main project, MIT for the client SDKs, with the change date and permitted-use terms in the LICENSE file that the README points to. Read that file before anything else. If your use case is internal integration work, FSL's restriction on competing commercial use is unlikely to bind you, but that is a determination for your legal team and not something this article can make. The practical next step is narrow: open LICENSE, confirm the change date, then open the self-host setup page and check whether the credential storage and data-usage tracking described there match what your security review requires. If either of those two documents is silent on credential handling, stop there.

Editorial conclusion

Adopt superglue if you are replacing hand-written connectors across long-tail systems and you accept the FSL terms and the external docs dependency. Do not adopt it if you need an install path you can read in the repository, or if your integration surface is one stable vendor API that a few hundred lines of code would cover. Verify first: the actual FSL change date and permitted-use terms in the LICENSE file, the self-host prerequisites at docs.superglue.cloud/getting-started/setup#self-hosted, and whether the credential and data-usage model matches your compliance requirements.

Official sources

1. Issues
2. Project website
3. README
4. superglue-ai/superglue on GitHub