A GPT that only responds with text is a chatbot. A GPT with Actions can check your inventory, create a ticket, or schedule a real appointment. Here's how to design Actions that work safely in production.
An Action is the connection between a GPT and an external HTTP API, defined via an OpenAPI schema (3.0 or 3.1) that describes endpoints, parameters, and expected responses. When the user types something in the conversation, the model evaluates whether any available operation is relevant, builds the necessary parameters from context, makes the real HTTP call, and uses the response to formulate its final answer.
It's the same conceptual mechanism as function calling in the API, but with a visual configuration layer (GPT Builder) instead of explicit code, and with the restriction that it only works within the ChatGPT environment.
The schema needs to be precise: clear descriptions on every `operationId` and parameter, because the model uses them as semantic guidance for deciding when to invoke each endpoint. A schema with vague descriptions produces incorrect invocations, or the model simply ignores the available Action.
Actions support three authentication modes: no authentication (public endpoints), API key (sent as a header, configured once by whoever creates the GPT), and OAuth 2.0 (where each user authorizes their own session, ideal when the action needs to run "as" that specific user, not with a shared credential).
For sensitive operations (creating records, modifying data, processing payments), per-user OAuth is the right choice because it enables individual auditing and granular revocation. Using a single shared API key for the whole GPT means that, from your backend's perspective, every action looks like it comes from the same "user," which complicates traceability.
The recommended practice is not to point the Action directly at your internal production API, but at an intermediate layer (an API gateway or dedicated microservice) that: validates and sanitizes received parameters (the model can generate unexpected or malformed values), applies rate limiting specific to traffic coming from ChatGPT, exposes only explicitly allowed operations (ideally read-only for query cases), and logs each call with the context of which GPT and which conversation originated it, when possible.
If the GPT gets published to the public GPT Store, OpenAI requires a valid privacy policy URL for any Action that sends or receives user data. For internally used GPTs (a private Team/Enterprise workspace) this requirement is more relaxed, but it's still good practice to document what data gets sent to external systems.
The model can chain multiple calls to different Actions within a single response, but each call adds perceptible latency for the user (several seconds per external HTTP request), so Actions with many sequential dependencies feel slow. Also, the size of the response the Action returns is limited — very large responses (full database dumps) need to be paginated or summarized in the endpoint itself before being returned to the model.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel