A major provider approaches you with a special API they've built just for you. Custom fields, custom status codes, custom everything. "White-glove integration," they call it. It sounds great. It's usually a trap.
The allure of custom integrations
Custom integrations feel like a win. You get special treatment. The provider is investing in you. You get exactly what you need, no compromises.
What you're actually getting is a liability.
Here's why: the moment you build around a custom API, you're locked. The provider has no incentive to maintain standards — they have an exclusive relationship with you. If they go down, only you suffer. If they change the API, only you have to adapt. If they go out of business, you're stuck maintaining the integration alone.
You also can't easily add a second provider because you've optimized your system around Provider A's quirks. Adding Provider B means re-architecting.
Custom integrations feel like a partnership. They're actually a dependency with a premium label.
When custom actually makes sense
Custom integrations do make sense in specific cases:
- True mutual benefit: The provider is so large and you're such a valuable customer that they're willing to maintain the custom API indefinitely. This is rare. Usually only applies to Tier 1 providers and Tier 1 customers.
- Temporary bridge: You're working with a provider whose standard API is inadequate, but you're building a generic adapter on top of the custom one. The custom integration is temporary scaffolding, not permanent architecture. Once the generic adapter is done, you can switch providers without changing your platform.
- Niche capability: The provider has a capability that's genuinely unique and valuable, and it's unavailable in any standard interface. You're paying for that uniqueness. You've accepted the lock-in because the benefit justifies it. And you've documented the tradeoff.
Everything else is debt. You're paying now to be locked in later.
The technical debt trap
Custom integrations accumulate like technical debt. At first, one custom API feels manageable. Then you have two. Three. Suddenly you're managing a portfolio of custom integrations, each with their own quirks, upgrade cycles, and failure modes.
You hire specialists to manage them. You document each one. You burn cycles every quarter handling provider API changes. And you're stuck — you can't easily diversify because each provider expects you to use their custom interface.
Compare that to a platform with standard adapters:
- New provider? Write a standard adapter. A week of work, not a month.
- Provider API changes? Update the adapter, not your platform. Your routing logic is unchanged.
- Provider goes down? Automatically failover to another. Your system doesn't know the difference.
- Provider quality degrades? Evaluate alternatives without re-architecting.
The difference compounds over time. After five years, you've either built a platform that can onboard new providers in days, or you've built a Frankenstein held together with custom integrations.
A better approach: standard + custom
This is where Oruve's approach is different. We have a standard adapter interface. Most providers can be integrated via that standard interface in a few days of work.
But for that rare case where a provider really does offer something unique, we offer a path: build the custom integration if you want it. But build it on top of the standard interface. The custom adapter translates their API to the standard one. Your platform never sees the custom API directly.
This preserves your optionality. If that provider goes down, you can swap them for a standard provider without changing your platform. If they change their API, it's an adapter update, not a platform redesign.
And it lets you take advantage of truly differentiated providers without the lock-in tax.
The key principle: your platform should never be tightly coupled to any single provider, even a "strategic" one. That coupling is what kills innovation and locks you in.
Custom integrations have a place. But make sure you're building them for the right reasons — genuine mutual benefit, not just because a provider asked for special treatment.