The M:N API Problem
The proliferation of SaaS applications has created a difficult problem: m services must connect and flow data to n different services. Each has it's own constantly changing and independently maintained API. Consumers need to write and maintain m × n connectors, which are expensive, error-prone and require never-ending maintenance. What's the solution?
There have been many attempts at solving this problem: e.g., Zapier for consumers, Mulesoft for enterprises, and Fivetran for data. The idea is to outsource the work to a third party, who then diligently keeps the connectors updated. There are variations on this theme – outsource the work to open source developers (plugin system) or try to develop a universal standard.
However, this problem will never be solved for most use cases. Sure, engineering best practices can improve – semantic versioning and backward compatibility. But for many use cases, API publishers have no incentive to make this easy on the integrators. If they did want to support mission-critical API consumers, they would rather have a direct enterprise relationship with the end-user. But in many cases, the scope of the API is limited to filling in the gaps in a product suite. They don't want you checking Mulesoft for your observability dashboards when they are most likely selling their own managed product dashboards.