--- type: "article" title: "Workflows as Abstractions to Capabilities" summary: "How to escape the integration maintenance hell." newsletter: "The API Changelog" newsletter_handle: "apichangelog" newsletter_url: "https://usecommune.com/n/apichangelog" author: "Bruno Pedro (@bpedro)" published: "2026-01-30T14:13:34.000Z" canonical_url: "https://usecommune.com/n/apichangelog/a/workflows-as-abstractions-to-capabilities" markdown_url: "https://usecommune.com/n/apichangelog/a/workflows-as-abstractions-to-capabilities.md" chat_url: "https://usecommune.com/n/apichangelog/a/workflows-as-abstractions-to-capabilities/chat" source_url: "https://apichangelog.substack.com/p/workflows-as-abstractions-to-capabilities" body_source: "imported" likes: 0 replies: 0 body_words: 1023 --- # Workflows as Abstractions to Capabilities Integrating with multiple APIs feels like maintenance hell. The more APIs you integrate with, the higher the chances of something bad happening are. Every time one of the APIs you integrate with changes, you need to change something on your side. If your integrations are baked into your code, you have a recipe for long-term frustration. But it doesn’t have to be like that, does it? I certainly don’t think so. Keep reading to learn why I think workflows can be a way to abstract the way you do API integrations. *** > This article is brought to you with the help of our supporter, **[n8n](https://n8n.io/)**. > > **[n8n](https://n8n.io/)** is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows. *** "I give up. There are too many conditional branches in my integration code," shared a Lead Software Engineer of an AI company during a call we recently had. The product they're building simplifies access to more than a dozen different services. Since every service needs a different API integration, imagine the complexity of maintaining all the options. To make things worse, they were putting all the integration logic into code. Every time one of those APIs changed, they had to make changes in their code. That code change, in turn, would probably break the integration with some other API. And, from there, you can see how easy it is to get frustrated. Unfortunately, they're not the only ones in this situation. I've been there myself a few times, and I'm sure some of you have as well. Things usually start with one or just a couple of API integrations. At that point, it feels manageable to code everything. The pitfall, however, lies in the compounding risk of changes occurring across each underlying API. Take a look at the following chart, where I’m using the formula P = 1 - (1 - p)^n. This is a classic probability model used to find the likelihood of "at least one" event occurring. In our case, it's the probability that at least one API will change and potentially break an integration. [![](https://substackcdn.com/image/fetch/$s_!PXp-!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5e3409df-3777-4bfd-a2b7-658f2c6710c9_1000x600.png)](https://substackcdn.com/image/fetch/$s_!PXp-!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5e3409df-3777-4bfd-a2b7-658f2c6710c9_1000x600.png) It’s not hard to see that, as the number of APIs grows, the probability of having at least one breaking change can quickly approach 100%. And, while the probability of a single API changing is low for well-established services, the opposite happens for those that have recently launched. So, if you integrate with APIs from new services, you can expect them to change quite often. The ability to manage those frequent changes is what defines how successful your integration strategy is. So, how can you navigate this sea of change in an efficient way? One way to decrease the amount of risk with each integration is to make it a “first-class citizen” of your system. You stop managing a catalog of API operations and all their possible combinations. Instead, what you have is a set of easy-to-understand integrations. This makes it easier to navigate issues and isolate problems when they appear. The second step is mapping each integration to a capability that makes sense from the perspective of your business. Here, instead of seeing integrations as technical tools, you operate them from a business angle. As an example, if your business has to process a payment to close a sale, create an integration for a capability called “sale close.” Don’t map the integration to the capability of processing a payment. Map it to what your business needs. This all looks nice, but how does it actually decrease the risk of integration failure? [![](https://substackcdn.com/image/fetch/$s_!Ff80!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcc87f1e7-91c1-4bf4-a5c2-dbf8036b86f6_2000x2000.png)](https://substackcdn.com/image/fetch/$s_!Ff80!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcc87f1e7-91c1-4bf4-a5c2-dbf8036b86f6_2000x2000.png) When you manage a raw catalog of API operations, a single failure creates a “needle in a haystack” scenario where it’s not easy to trace technical errors back to business impacts. Mapping integrations to a capability like “sale close” creates a protective abstraction layer. This decreases risk in three ways: 1. **Simplified Troubleshooting:** If “sale close” fails, the context is immediate. You aren’t guessing which business process is broken, allowing for faster triage and recovery. 2. **Reduced Complexity:** Managing a few high-level capabilities is less prone to human error than managing hundreds of individual API permutations. 3. **Vendor Decoupling:** If you change a technical provider, e.g., switching payment processors, the business capability remains constant. This prevents a “house of cards” effect where a technical change ripples through and breaks unrelated parts of your system. Essentially, you are moving from a fragile web of connections to a modular system where problems are easier to find, contain, and fix before they escalate into systemic failures. This approach has even higher benefits when your capabilities require an integration with multiple API operations. In those scenarios, having a high level of abstraction can even offer more advantages. One advantage of using capabilities to abstract complex integrations with several operations is that you can describe them as workflows. So, instead of implementing those integrations purely in code, you can use your favorite workflow technology. And now, the advantages are enormous. You can now use a low-code (or even no-code) technology. You can see your workflow visually. You can assign its execution to a particular team or even outsource it to an external partner. You can understand whenever it fails and how each failure contributes to a business loss. In summary, you can treat it as an individual piece of technology and manage it following a lifecycle approach. Workflows can act as abstractions to business capabilities because they map the complexity of integrations into a repeatable process. Why aren’t you following this approach yet? Traditionally, API integrations are the responsibility of technical teams. It’s easy to assume that anything that has to do with connecting systems to external APIs needs developers and involves code. In addition to this, business people aren’t always equipped with the right tools to help them manage these types of solutions. Perhaps it’s time you start experimenting with workflow technologies and then follow the capability abstraction model. I’m sure there will be some effort in making the transition, but the long-term benefits aren’t negligible. *** ## Discussion No replies yet.