GPT Actions

What a GPT Action is

A GPT Action is a way of giving a custom GPT the ability to reach outside the conversation. OpenAI's definition is compact: an action is defined by making one or more APIs available to the GPT ^[1]. Once an API is attached, the GPT can integrate external data or act inside another application — the examples OpenAI gives are a database, an email inbox and an e-commerce order flow ^[1]. Actions were introduced on 6 November 2023, the same day OpenAI launched custom GPTs ^[1].

How it works

A user asks for something in ordinary language. The action layer's job is to convert that natural language into the JSON that an API call requires ^[2]. At the core of this sits function calling, the mechanism that picks the relevant API call and generates its JSON input ^[2]. The model is not handed a fixed script; it chooses among the calls the developer has exposed and fills in the arguments.

To make that possible, every action needs an OpenAPI schema describing the parameters of the call. OpenAI's documentation calls OpenAPI a standard for describing APIs ^[3]. The schema, in other words, is the contract that tells the model what the endpoint expects.

Developers also configure the authentication mechanism for an action. When the GPT calls the third-party app, it does so with that authentication ^[2].

Where it came from

Actions did not start from a blank page. OpenAI said the design builds on insights from its plugins beta, and that the aim was to give developers greater control over how their APIs are called ^[1]. The continuity was practical as well as conceptual: existing plugin manifests could be reused to define actions for a GPT ^[1].

A worked example

OpenAI's getting-started material walks through a small, concrete case. The schema is written in OpenAPI 3.1.0 and describes two weather.gov endpoints; with that description in place, a GPT can answer a packing question for a trip — what to bring, given the forecast ^[3]. The example is deliberately mundane, but it shows the shape of the thing: a written description of an interface goes in, and a model that can turn a question into a valid call comes out.

Why it matters

The interesting move is where the integration work sits. Instead of writing bespoke glue for every service, a developer describes the API in a schema, sets the authentication, and the model handles the step of matching a user's request to a call and filling in its parameters ^[2][3]. That is what lets a single custom GPT touch a database, an inbox or an order system without those systems being rebuilt for it ^[1].

It also keeps a good deal of control on the developer's side: which endpoints are exposed, what the parameters are, and what credentials the call carries are all decisions made when the action is configured ^[2][3].

The boundaries follow from the same design. An action can only do what the underlying API already allows, and it can only be as precise as the schema that describes it — the model's freedom is bounded by the calls the developer has made available ^[1][2]. Actions are, in that sense, less a new capability of the application than a new way of addressing capabilities that were already there.