Updated: | Originally published: | By Fraser Davidson
Recently Prismatic took the brave decision of open sourcing their connector library. They also made the bold assertion that ‘Connectors are the commodity’.
We thought we might take the time to make the counter argument.
The first thing to point out is the difference in approach.
Prismatic have built c200 connectors as code. Each individual, each compiled differently. Probably by different developers. Logic and function are hardcoded into the connector. Inconsistently.
Cyclr builds connectors as data. A connector is a set of instructions for our platform to respond to. All of our platform logic, for example approach to pagination and retries, are built into our core platform code. The platform ingests the data and then performs the connector task according to instructions received from the data. Every single one of our 700+ connectors is built the same way.
We view this as a ‘clean’ approach. The platform processes, the connectors instruct. There is no ball of multi-coloured tangled wool in Cyclr.
| Cyclr | Prismatic | |
|---|---|---|
| Connector library Size | 700+ | c200 |
| Approach to connector build | Connector as data | Connector as code |
| Standardisation | Consistent | Inconsistent |
| Responsibility for extension of connector | Cyclr | You |
| Connector Pagination | Defined in Cyclr platform, all connectors operate under same rules, pagination just happens | Defined in each connector and loops handled by the user building the workflow |
| Connector Rate limits | Connectors configured with API rate limits will throttle calls preventing rate limit errors | Relies on 429 errors and back off retries |
| Connector changes | Cyclr will extend, Cyclr retains responsibility | You fork it, it’s your issue |
We took the design decision to have connectors as data over 10 years ago. Our dedicated team operates around a standardized ontology and a consistent approach to every single connector.
We used AI to review Prismatic’s library. Only 30/170 connectors implement pagination. Only 2/170 handle a rate limit error (HTTP 429). In Cyclr rate limiting and pagination are declared once in the connector and handled at the platform level automatically.
Depth of connectivity is also different. Due to our approach, deepening and expanding a connector is a minor technical challenge. Our Hubspot connector carries 337 actions compared to c50 for Prismatic’s Hubspot connector. Salesforce we have 339 to 89 for Prismatic.
Fork a Prismatic connector and it’s yours, unsupported. The flexibility they sell is real, but so is the maintenance tail. If you want one of our Cyclr connectors extended, we will do it (typically in 24-48hrs, typically free of charge) and we will retain responsibility and support obligations. Want your own entirely proprietary Cyclr connector? We have a toolkit for that, but the boundaries are clear. Our connector = our responsibility. Your proprietary connector = your responsibility. In Cyclr adapting connectors remains a light-touch job for you and your team. No code skills required. Prismatic’s own documentation is honest about this: fork a connector and that version is yours, unsupported. The flexibility they sell — take the Salesforce connector, extend it, publish it as your own — transfers the entire maintenance burden to the customer’s engineering team.
Prismatic’s fundamental model is connectors as TypeScript code. That sounds developer-friendly until you consider what it actually requires to ship and maintain one: a build pipeline, TypeScript compilation, webpack bundling, and a deployment process. Every update goes through that cycle.
Cyclr connectors are configuration — a file that describes an API. No compilation, no bundling. A connector can be patched and shipped with far less overhead. When an API changes a field name or deprecates an endpoint, Cyclr can turn that around faster precisely because there’s no code to rebuild.
That gap compounds over time. At 700 connectors versus ~170, the maintenance burden Prismatic carries per connector is structurally heavier than Cyclr’s. They’ve open-sourced that problem to the community.
Lastly, this approach that we have taken of ‘Connector as Data’ has a secondary but fundamentally important benefit in the current climate. We have 700+ connectors, 50,000+ tools, all defined with rich metadata in a form that can be readily passed to an LLM. Our MCP proposition is phenomenal, primarily because our connectors are data, consistent and rich in description. Packaged into an MCP package they are intuitive and descriptive.
Connectors are not the commodity, connectors are the asset. It all depends on how you have built them.
