Responses API

When a program wants to use OpenAI’s artificial intelligence, it cannot simply click on it. It needs a defined way to make a request and get a response back. Such agreed-upon handoff points between two programs are called interfaces, or APIs in English. The Responses API is OpenAI’s interface through which a program sends an input and receives the response generated by the model. It was introduced in 2025 and is meant to replace the company’s older interfaces in the long run. For users it is invisible; for developers it is the central access point.

Why OpenAI is retiring the old interfaces

The predecessor was called the Chat Completions API and was built for a simple task: text in, text out. For a long time, that was enough. Today, however, a model is supposed to do more than just answer. It should be able to search the internet, look through files, execute program code, or view images. Squeezing all of that into an interface meant for plain text became unwieldy.

The Responses API bundles these capabilities. A developer describes in a request what the model is allowed to do and receives a result at the end. The interface itself organizes the intermediate steps. This saves work that previously every team had to handle individually.

Economically, this is more than a technical cleanup. Whoever provides the standard interface to which thousands of companies connect their products binds customers to it. Switching to a competitor then means restructuring one’s own program. Such switching costs are an important competitive advantage in the AI market.

What happens during a call

At its core, a call consists of two pieces of information: which model should respond and what the input is. In addition, a developer can specify a list of allowed tools, such as web search or file search. The program sends this package as a message to a server run by OpenAI. From there, a structured response comes back.

What’s interesting is what the model is allowed to do in between. If it determines that it needs current information, it triggers a search on its own. The result feeds into its further reasoning. Only afterward is the text for the user generated. These rounds of thinking and tool use take place within a single call.

A second difference is memory. With the old interface, the program had to resend the entire conversation history each time. The Responses API can keep the state on the server. The program then simply refers to the previous response. This shortens the requests and reduces errors when assembling long conversation histories.

From customer chats to developer news

The interface becomes visible mainly in other companies' products. A bank’s chatbot, the search function in a piece of software, the writing assistant in a text program: behind these there is often a call to such an API. The user only sees an input field. The computational work happens in a data center owned by the model provider.

In trade news, the term usually comes up in connection with OpenAI’s announcements. When a new model is introduced, it is stated there from when it will be accessible via the Responses API. For developers, that is the decisive date. Before that, they cannot integrate it into their own products.

A common misconception: the Responses API is not an AI model. It is merely the pathway through which a model is reached. You can think of it as an order counter, not the kitchen. Other providers have their own counters with different rules. That’s why switching between providers always involves programming effort.