David Cummings on Startups

Why No Universal API Middleware

Written by

David Cummings

in

,

Recently I was talking to an entrepreneur about APIs (ways for apps to communicate with other apps automatically) as he was looking for a way to connect his app, and corresponding customers, with a number of other apps. Only, he couldn’t find anything on the market. Successful startups like MuleSoft and Zapier have numerous integrations but require going through their respective apps to make the connectors work — you can’t readily whitelabel them or use their APIs to connect to other APIs.

Why hasn’t a universal API middleware emerged? Here are a few ideas:

  • APIs constantly change. Facebook was notorious about constantly breaking their API, yet their motto at the time (“move fast and break things”) made their priority clear. As a vendor connecting to another vendor’s API, it takes on-going resources and money to keep APIs working, which is more expensive than it looks.
  • APIs aren’t as strategic as expected for most cloud-based apps. While companies like Salesforce have amazing APIs, many cloud-based apps don’t prioritize their APIs and thus the API doesn’t have parity with the user interface and bugs don’t get fixed quickly.
  • The long tail is really long. While there are 25-50 apps in the mainstream category (> $100MM ARR), there are hundreds and hundreds more in the near-mainstream category (> $25MM ARR), not counting the thousands more that have at least some scale (> $10M ARR). Outside of the mainstream apps, the next tier of apps, while having a large number of customers, doesn’t have enough overlapping customers with any other non-mainstream apps, making for a limiting number of useful integrations.
  • APIs constantly have problems. Whether it’s an API going down, user authentication expiring, or invalid data with limited error codes, APIs constantly have challenges. This makes for a less-than-ideal end user experience and a challenge to support a large number of APIs at scale.

Bottom line: APIs are much more complicated than they seem and only a handful are needed to make most customers happy, so vendors just write their own hand-crafted integrations. It doesn’t fulfill the ideals of a universal API middleware platform but it’s good enough for most apps.

What else? What are some more thoughts on why a universal API middleware hasn’t emerged?

Comments

2 responses to “Why No Universal API Middleware”

  1. geraldtj Avatar
    geraldtj

    David,

    A very interesting blog, and one that has a wider applicability, namely to the Intermet of Things. I see the lack of the universal API and middleware as a barrier to the growth of the true Internet of Things. If we look back at the history of the physical Internet, it was and remains successful because of the use of open easily deployed standards which in turn enabled the growth of a massive ecosystem that reached critical mass quickly.

    Unless we achieve the same for the IoT it will become just another tech fad with numerous spot and incompatible solutions based around individual applications and services. There is some activity in this area, one being Signal K, an open source project. Signal K has been developed for the marine leisure industry to provide that underlying common infrastructure (in its widest sense) for marine leisure solutions but I believe it has the genesis to be something much larger and with more widespread applicability.

    You did not mention they type of API and middleware solution you envisage as the solution to the problem. You infer a “traditional” approach, although my guess is that micro services based solutions will be more likely to be successful.

    Reply
  2. ratedsar Avatar
    ratedsar

    An API for API’s is also a tricky sales problem, especially if it’s for an often used / well documented API. The implementation of your client / SDK has to work better than integrating with the SDKs of the original API themselves, and business logic needs to be predictable or manageable.

    Recently, I’ve been impressed with Segment, which provides an API of APIs for tracking user interactions to MixPanel, CustomerIO, and others. The trick here is that these are all similar – based off of events with data -that feed into the other systems. But even in this use case, there are tricks or annoyances, such as update/delete capabilities.

    Reply

Leave a reply to geraldtj Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts