Unified APIs Collapse Under Complexity
Zachary Kirby, co-founder of Vessel, on building the Vercel for integrations
The core weakness of a unified API is that it hides the exact shape of the underlying system until an important customer asks for something the common model does not cover. That works for simple reads like contacts or deals, but breaks when a product needs Salesforce cases, custom objects, special permissions, or tenant specific logic. At that point, teams can misread fields, show wrong data, and end up learning the source API anyway.
-
Vessel’s answer is to pair a common model with provider specific actions. The common model handles the broad path, then an action exposes the real Salesforce or HubSpot option set when a customer needs something deeper, without forcing the team to rebuild auth, syncing, and ETL from scratch.
-
This is a recurring pattern across the category. Ampersand describes unified APIs as good for the first 10 fields, but says enterprise integrations quickly run into the 11th, 12th, and 23rd field, where custom objects, rate limits, and per tenant differences matter more than a neat shared schema.
-
The tradeoff depends on the market. In fragmented sectors like payroll and HR, companies like Finch and Pinwheel can justify a heavier abstraction because the main value is unlocking hard to access systems. In open SaaS categories like CRM and GTM tools, the harder problem is often maintenance, correctness, and depth, not basic field mapping.
The market is moving toward hybrid integration stacks, where a unified layer handles the common path and a deeper native layer handles the revenue critical edge cases. The winners are likely to be the platforms that let product teams start fast, then go field by field and tenant by tenant without forcing a rewrite once bigger customers demand more exact behavior.