Unified APIs Fail at Edge Cases
Zachary Kirby, co-founder of Vessel, on building the Vercel for integrations
This is the core weakness of the unified API model, it works for the common 80 percent of fields and actions, then breaks exactly where enterprise software gets valuable. CRM systems like Salesforce have custom objects, odd permissions, case workflows, and account specific rules, so a flat common schema eventually forces the developer back into raw vendor docs. Vessel’s answer is to keep the fast common layer, but add a typed vendor specific layer before the customer outgrows the product.
-
The breakage shows up fast in practice. Teams start with simple reads like contacts or deals, then a customer asks for something like Salesforce cases or custom scope rules, and within months the team is making pass through requests anyway. That is the moment a unified API stops saving work and starts creating integration debt.
-
This is a recurring pattern across native integration infrastructure. Ampersand describes the same problem as the missing 11th and 12th fields problem. A unified model hides complexity at first, but as soon as customers need tenant specific fields, custom objects, or deeper workflows, the abstraction becomes a patchwork.
-
The strategic point is that the durable product is not the schema alone, it is the escape hatch plus the infrastructure around it. Vessel pairs a unified API with action APIs, ETL, caching, webhooks, and hosted data sync, so the developer can stay inside one system even when the integration stops being uniform.
The market is moving toward hybrid integration products that start shallow and then go deep without forcing a rewrite. As customer facing integrations become part of winning deals, the vendors that keep developers out of raw Salesforce and HubSpot documentation, even for edge cases, will be the ones that replace in house integration teams.