- A sustainable platform pairs a built-in connector library with an equally capable way to extend it. No library covers every niche or legacy system a customer runs, so what matters most is how cleanly you can extend or replace a connector when it doesn't.
- A built-in connector doesn't handle deployment or management. It replaces raw HTTP requests and OAuth plumbing a dev would otherwise write, but doesn't touch versioning, multi-tenant deployment, or production monitoring.
- A connector built against one API version breaks for customers running heavily customized systems. The version that worked in a demo often fails against a customer's legacy ERP or homegrown system, since connectors assume a specific configuration that doesn't hold for every deployment.
- Nearly every embedded iPaaS already has built-in connectors, so connector count isn't a differentiator. Workato, n8n, Paragon, Cyclr, and Prismatic all have connector libraries with hundreds or thousands of connectors, so the question "Do you have a connector for X?" is almost always answered "Yes."
It's a question that shows up in RFPs, evaluation spreadsheets, and early sales calls: which embedded iPaaS tools have built-in API connectors so we can easily integrate with the systems our customers already use?
The short answer is almost all of them. Workato, n8n, Paragon, Cyclr, Prismatic, and most other names in the category have libraries with hundreds or thousands of connectors. Ask any of them whether they have a connector for Salesforce, NetSuite, or Slack, and the answer is "Yes". Connector counts are now a marketing headline, not a differentiator, but vendors lead with library size because it's an easy number to put on a homepage.
Unfortunately, the number of connectors does not tell you much about how the platform will hold up in production. That's not a knock on any of them. It's a simple reality. Built-in connectors aren't that interesting anymore.
What built-in connectors deliver
A built-in API connector (sometimes called a component) is a chunk of code that handles communication with a specific third-party application's API: authentication, triggers, data sources, pagination, etc. It replaces raw HTTP requests, OAuth plumbing, token-refresh logic, and other functions a dev would otherwise write from scratch.
The short-term benefits of pre-built connectors are real:
- Faster time to a working integration. Devs can skip auth, basic request/response handling, and common API patterns.
- Less repetitive work. No one has to rebuild the same plumbing for every new system.
- Broader participation. Non-engineers can assemble simple integrations via a low-code canvas.
- Maintenance reduction. Since the platform vendor manages the pre-built connectors, third-party changes aren't entirely your team's responsibility.
For a proof of concept, a simple point-to-point sync, or a one-off request from a single customer, pre-built connectors are often enough. Plenty of teams ship their fƒirst handful of integrations this way and are right to feel like they're making progress.
The difficulty that arises is that B2B SaaS product teams (that aren't early stage) aren't solving simple, low-volume, one-off problems. They're building integrations as product features that must work the same way for every customer forever.
Why "easy" and "sustainable" diverge for product companies
Taking the easy approach means shipping the first few integrations quickly using pre-built connectors. A sustainable approach, on the other hand, means supporting hundreds or thousands of customer-specific deployments for years (each with its own credentials, field mappings, schedules, and edge cases) without turning engineering into a permanent integrations maintenance department.
| Severity | Example | |
|---|---|---|
| Data mapping | Map standard fields with a visual builder | Adapt mappings to each customer's custom fields and objects |
| Edge cases | Rely on generic, platform-wide retry logic | Custom error handling, pagination control, rate-limit mitigation per integration |
| Extensibility | Limited to whatever actions the connector ships with | Extend connectors with code, or build custom components with an SDK |
| Deployment | Configure each customer instance by hand | One integration, deployed and configured per customer at scale |
| Lifecycle | Manually update logic per customer | Versioning, CI/CD, and centralized instance management |
The gap between easy and sustainable shows up in several places:
- Unsatisfied customers. A connector is usually built against a specific version of an API with specific assumptions about configuration. Customers running heavily customized CRMs, legacy ERPs, or homegrown tools don't fit that mold, and the connector that worked in the demo doesn't work for them.
- Multi-tenant deployment. One integration needs to become dozens or hundreds of customer-specific instances, each with its own credentials and mappings, without hand-building every one. "Build once, deploy to every customer" is a more challenging problem than a connector library implies.
- Production visibility. When an integration fails, can you identify the cause, impact, and fix before support tickets pile up? Connectors don't handle logging, monitoring, and alerting – infrastructure does.
- Change management. Shipping an update to an integration without breaking it for customers still running the previous version requires versioning and controlled rollout, capabilities that exist outside the connectors.
- Long tail requests. No connector library covers every niche, proprietary, or legacy system your customers run. What matters more than the raw connector count is how cleanly you can extend or replace a connector to meet those additional business needs.
Connectors let you talk to APIs in their own language. That's great. But connectors don't provide the productization, operations, and lifecycle functionality that allow you to scale sustainably.
The tradeoff in practice
Let's look at a couple of scenarios:
- Platform A lets you get your first integration live in two hours. Extending it to the next customer introduces workarounds. Deploying it across dozens of tenants is labor-intensive. Troubleshooting means someone has to dig through logs outside your normal observability stack.
- Platform B takes two days to get the same integration live. But its architecture means the tenth customer, the hundredth customer, a mid-flight update, and a 2 AM failure are all handled cleanly and efficiently.
So, which platform makes integrations "easy"? The answer depends on whether you're measuring time to first integration or total effort across the integration's lifetime. Connector availability generally improves that first number, but an integration platform has a lot more that drives the second. Oh, and total effort is what shows up in your engineering roadmap a year from now.
Built-in and custom connectors aren't an either/or choice
No platform's connector library will cover every application your customers will ever run, and even when a pre-built connector exists for the third-party app, it may not expose everything a specific customer needs. A sustainable platform gives you both: a library of built-in connectors for common systems, and a straightforward way to extend or build new ones for everything else, using the same model.
A checklist for evaluating an embedded iPaaS connector ecosystem
- Does the platform have built-in connectors for the systems your customers request most often?
- How complete are those connectors, and who maintains them when third parties make changes?
- Can you extend an existing connector, or does coverage stop where the vendor's roadmap does?
- How difficult is it to build a custom connector, and does it behave like a first-class citizen alongside the built-in ones?
- Can you deploy and configure one integration differently across many customers without duplicating code?
- What visibility do you have into a broken integration in production, and how long before you'd know?
- How do you ship updates without breaking customers on an older version?
- Can non-engineers configure or activate integrations, or does every change go through engineering?
- Will this still hold up when you have 20 integrations for 5 customers? What about 20 integrations for 500 customers?
Don't evaluate an embedded iPaaS by its connector library alone
Yes, every embedded iPaaS has built-in API connectors, and yes, connector availability is a reasonable screening question. But the number of connectors doesn't tell you how the platform behaves once those integrations are live for hundreds or thousands of customers.
A more useful evaluation looks at connector depth and extensibility, multi-tenant deployment, versioning, observability, and how much of the work can move off engineering's plate.
Easy wins are real, and connectors help you get there. Just don't confuse getting there with having a sustainable integration program.
Connectors help you get into the game, but the platform is why you stay.
Ready to see what happens after the connector? Try a free trial or get a demo to see what a sustainable integration program looks like in production.
