Zapier, Make, Workato, MuleSoft, and Boomi connect software with APIs. Most vertical software has none. How the two layers fit, and what covers the gap.

iPaaS earned its place in the stack. Zapier and Make made integration a drag-and-drop job; Workato, MuleSoft, and Boomi made it an enterprise discipline with governance, retries, and monitoring. If both systems in your workflow expose an API, one of these is almost certainly the right tool, and this post won't talk you out of it.
The catch sits underneath all of them: an iPaaS connector is a wrapper around a vendor's API. No API, no wrapper, no connector. And roughly 90% of enterprise software, concentrated in exactly the vertical systems that run real industries, publishes no API at all.
Keep your iPaaS for orchestration. Add a connectivity layer that manufactures a real API for the systems that lack one, and the two compose through a plain HTTP action: the no-API portal becomes one more node in the flow you already built.
Look at any iPaaS catalog and you'll find thousands of connectors for horizontal SaaS: CRMs, help desks, spreadsheets, chat. Now look for the systems your customers' businesses actually run on: the property management platform, the dealer management system, the claims clearinghouse, the legal practice suite, the state licensing portal. Mostly absent, because there's no API to wrap. The workflow that matters most ends at a login screen the iPaaS can't cross.
| Layer | What it does | Examples |
|---|---|---|
| Orchestration (iPaaS) | Moves data between systems that expose APIs; owns triggers, mapping, retries, governance | Zapier, Make, n8n, Workato, MuleSoft, Boomi, Power Automate |
| Connectivity (managed APIs) | Creates the API where none exists, from the portal's own backend calls, and maintains it | Supergood |
These compose cleanly because a generated endpoint is ordinary REST. Every iPaaS on the list has an HTTP action, so the no-API system becomes one more node in the flow you already built: trigger in your CRM, HTTP call to the portal's endpoint, result posted to Slack. The iPaaS keeps doing what it's best at; the missing connector stops being missing.
Teams facing the gap usually try one of three patches. Vendor SFTP or nightly CSV exports: batch cadence, vendor-defined fields, painful for anything a user waits on. RPA bolted to the side of the flow: reintroduces UI fragility inside an otherwise API-clean pipeline. Partner API applications: worth pursuing when you qualify, with approval timelines measured in months and coverage decided by the vendor. The durable fix is giving the orchestration layer what it wanted all along, a real API for the system that had none, with someone accountable for keeping it alive. That last part matters: the portal's backend does change occasionally, and a managed integration detects it in production telemetry and ships the fix before your flow notices.
Is Supergood an iPaaS competitor? No. iPaaS orchestrates between APIs; Supergood manufactures the API for systems that lack one. Most Supergood customers call their endpoints from an orchestrator or their own backend.
Which iPaaS does this work with? Anything that can make an HTTP request, which is all of them: Zapier, Make, n8n, Workato, MuleSoft, Boomi, Power Automate. For AI-agent stacks, the same integrations are exposed as MCP tools.
What about the 90% figure? It's our working estimate for enterprise software without a usable public API, and it skews higher in vertical industries. Whatever the exact number, the test that matters is simpler: is your system in the connector catalog? If it isn't, you're in the gap this post is about.
Updated July 2026.