Why Everyone Imitates the OpenAI API
OpenAI's market dominance made its API the archetype of what competitors want to offer.
The next best thing to having a large customer base is seeing your competitors copy your product. In the case of OpenAI, both things have been happening with their products, API, and SDK. Other companies have been looking at how OpenAI exposes its features programmatically. Then, they build their product along the same lines so their API becomes compatible with OpenAI's. Why is this happening, and how does it affect the AI market?
This article is brought to you with the help of our supporter: Speakeasy.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations.
The first time I noticed how OpenAI's way of doing things was influencing other products was a couple of months ago. At the time, I was experimenting with some AI models locally on my laptop. I was using Ollama, a tool that lets you run different models locally. It runs in the background and exposes an API you can call to add models and to ask questions to any of the available models. It's a great way of getting up and running locally very easily.
What made things even easier for me was how compatible it is with the existing OpenAI API and SDK. To the point that you can simply install the OpenAI SDK for your favorite programming language and simply replace the API URL with the one of your local Ollama instance. The announcement, from February 2024, says that there's built-in compatibility with OpenAI's Chat Completions API. Looking at the documentation shows they're committed to maintaining compatibility, even if that requires accommodating breaking changes.
Mistral, an OpenAI direct competitor, follows a similar approach. Just look at their Chat Completion API documentation, and you'll notice it's identical to OpenAI's—even the feature name is similar. The path is /v1/chat/completions on both products. It uses a similar Bearer API key authorization scheme. The payload of both APIs is similar, with at least the same required attributes (model and messages) and many of the same optional ones, such as stream, which makes the API stream partial progress to the consumer.
Again, in this case, you could simply use OpenAI's SDK and replace the API URL and the AI model with Mistral's. You'd be able to use Mistral directly from the OpenAI SDK without much effort. Even though there's no official support from Mistral for keeping their API compatible with OpenAI's, doing so makes it easier for users to migrate—or use both products. It looks like this was done intentionally.
Another AI API that follows the same approach as Mistral and Ollama is the one offered by Groq. GroqCloud, one of its products, provides online access to an AI chat system similar to the one OpenAI offers. It also provides an API—who doesn't?—that is identical to OpenAI's. This time, you can see in Groq's marketing they're not being shy about it. One of Groq's official benefits to users is that with their "OpenAI endpoint compatibility, simply set OPENAI_API_KEY to your Groq API Key." They position themselves as a way to "move seamlessly from other providers like OpenAI by changing three lines of code." Three lines of code.
Those three lines of code are from OpenAI's SDK. They let you specify Groq's API URL, its API key, and the name of the AI model you want to use. I'm seeing a pattern here where companies offering AI products make their API identical to OpenAI's so consumers can easily migrate. If you extrapolate this behavior, it's easy to imagine a service that lets you connect to different AI APIs using the same interface. OpenAI's, of course.
AI/ML API is such a service. Unlike Ollama, which lets you run different models locally, it offers a single API that connects to multiple online AI systems. With AI/ML, you can, for instance, connect to existing systems like Meta Llama, Mistral, OpenAI, and Stable Diffusion. Not surprisingly, by now, their own API is an exact copy of the one OpenAI provides. AI/ML documentation is clear that they "fully support the OpenAI API structure, and you can seamlessly use the features that the OpenAI SDK provides out-of-the-box." In this case, leveraging OpenAI's precedent is what makes it easy to acquire new customers.
The big difference between AI/ML API and other OpenAI competitors is that now it can make any other AI service also compatible with OpenAI. Services that have APIs that aren't easy to use can attract more users simply by being available through the AI/ML API. You can feel the growing omnipresence of OpenAI by seeing how other services copy their API. By now, you must be thinking that if you want to succeed as an AI API, you should just copy OpenAI. So, why is this a good approach?
One of the reasons for this successful approach is the rule of familiarity I described in "The Hard Things about Naming Things" article. The APIs all these services offer follow the same shape as OpenAI because it's a familiar one. OpenAI launched its API in January 2022, but it was only on version 1.2.0, more than a year later, that they introduced the /chat/completions endpoint. From then on, it was clear, with the popularity of ChatGPT, that chat was the right way to name the API operation. The use of the term completion, however, wasn't as familiar before AI services became popular. Despite that, it quickly permeated the technical vocabulary.
By introducing a naming strategy using simple terms that are easy to understand, OpenAI made it easy for developers to use their API. The fuel that made its API familiar to people in the AI space was its incredible usage growth. With an estimated 100 million users in January 2023, ChatGPT growth almost doubled just one year later. In this scenario, it's normal that /chat/completions become a very familiar naming pattern.
Another reason behind the success of following the footprints of OpenAI has to do with the concept of API Friction. Several factors contribute to making an API complicated—or even impossible—to use. OpenAI API avoids almost all those factors. The API, specifically the /chat/completions operation, is easy to understand—due to its popularity. It's easy to test because OpenAI has been offering free credits to developers. It's always had plenty of documentation. It's fully aligned with the use case of asking questions to an AI system and getting answers. It has a strong community of developers who are very interested in the matter. It doesn't have any copyright issues because it doesn't use any protected terminology or branding.
But the two most important factors that avoid OpenAI API friction are how easy it is to use and the availability of a polyglot SDK. These two things, combined with the explosive popularity of OpenAI, are what make its API the de facto AI API. Plugging any URL into OpenAI's SDK is as easy as changing the value of the base URL option when instantiating a client. That makes the SDK connect to a different API that you can then build to mimic the input and output of the one from OpenAI.
How does this situation affect OpenAI currently? As I see it, they must be dripping users into competitors just because of how easy their API has become. I feel they can be in a tough situation if the number of departing users impacts their business. They wouldn't be able to introduce breaking changes that could hurt competitors because they'd also hurt their own API consumers. Not having any branded terminology—at least on the /chat/completions operation—makes it hard to control unwanted usage of the interface. It looks like they became a victim of their own success. One solution is to move forward by introducing new API features that are more exclusive to what they offer and less appealing to be copied by competitors.