+190 XP

GPT Actions: ChatGPT Ihre APIs aufrufen lassen

# GPT Actions: ChatGPT Ihre APIs aufrufen lassen

GPT Actions erlauben einem Custom GPT, externe APIs aufzurufen, die Sie beschreiben. Statt zu raten, holt ChatGPT damit Live-Daten oder löst in Ihrem Namen ein echtes System aus. Sie schreiben eine kleine OpenAPI-Spec, richten sie auf Ihren Endpoint, konfigurieren die Auth, und das Modell entscheidet im Gespräch, wann es den Aufruf macht.

Das ist dieselbe Mechanik wie Function Calling in der API, nur verpackt für den No-Code-Builder für Custom GPTs. Sie definieren die *Tools*, ChatGPT übernimmt das *Wann* und *Wie*.

Was eine Action tatsächlich ist

Eine Action besteht aus einem oder mehreren HTTP-Endpoints, die einem GPT über eine OpenAPI-Spezifikation zugänglich gemacht werden. OpenAPI (früher Swagger) ist eine standardisierte, maschinenlesbare Beschreibung einer REST-API: Pfade, Parameter, Request Bodies und Responses.

Wenn Sie eine Action zu einem GPT hinzufügen, passieren zur Laufzeit drei Dinge:

1. Das Modell liest Ihre Operationsbeschreibungen und entscheidet, dass ein Aufruf nötig ist.

2. ChatGPT baut den HTTP-Request (füllt Parameter aus dem Gespräch), hängt die Auth an und sendet ihn.

3. Ihre API antwortet mit JSON, und das Modell liest dieses JSON, um seine Antwort zu formulieren.

Das Modell sieht Ihren Server nie. Es sieht nur das Schema, das Sie ihm gegeben haben, und die zurückkommende Response. Das heißt: Ihre description-Felder sind keine Dokumentation, sie sind *Prompt*. Vage Beschreibungen führen zu falschen Aufrufen.

Wo Actions liegen

Actions werden im GPT-Editor auf chatgpt.com konfiguriert (Explore GPTs, Create, dann der Configure-Tab). Scrollen Sie zu Actions und klicken Sie auf Create new action. Sie fügen ein Schema ein, wählen einen Authentifizierungstyp, und ChatGPT validiert das direkt.

Verwechseln Sie Actions nicht mit Connectors. Connectors sind vorgefertigte, von OpenAI verwaltete Integrationen (Google Drive, SharePoint, GitHub und andere), die Daten *in* ChatGPT bringen, für Suche und Retrieval. Actions sind *Ihre* eigenen API-Aufrufe, von Ihnen definiert. Nutzen Sie einen Connector, wenn es für die Quelle einen gibt; bauen Sie eine Action, wenn Sie Ihr eigenes Backend ansprechen oder etwas auslösen müssen.

Ein konkretes Beispiel: Bestellstatus abfragen

Angenommen, Ihr Support-Team will ein GPT, das die Frage „Wo ist Bestellung 10428?“ beantwortet, indem es Ihre interne Orders-API aufruft. Ihr Endpoint existiert bereits:

GET https://api.acme-shop.com/v1/orders/{orderId}

Er liefert etwa Folgendes:

json
{
  "orderId": "10428",
  "status": "shipped",
  "carrier": "DHL",
  "trackingNumber": "JD0149...",
  "estimatedDelivery": "2026-02-14"
}

Nun beschreiben Sie diesen Endpoint für das GPT. Hier ist ein sauberes, minimales OpenAPI-3.1-Schema, das Sie direkt in den Actions-Editor einfügen können:

yaml
openapi: 3.1.0
info:
  title: Acme Orders API
  version: 1.0.0
servers:
  - url: https://api.acme-shop.com/v1
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      summary: Get the current status and tracking info for one order.
      description: >
        Look up a single order by its numeric ID. Use this whenever a
        user asks where their order is, its delivery date, or its
        shipping status. Returns status, carrier, and tracking number.
      parameters:
        - name: orderId
          in: path
          required: true
          description: The order's numeric ID, e.g. 10428.
          schema:
            type: string
      responses:
        "200":
          description: Order found.
          content:
            application/json:
              schema:
                type: object
                properties:
                  orderId: { type: string }
                  status: { type: string }
                  carrier: { type: string }
                  trackingNumber: { type: string }
                  estimatedDelivery: { type: string, format: date }
        "404":
          description: No order with that ID exists.

Ein paar Punkte machen dieses Schema gut und nicht nur gültig:

  • `operationId` ist beschreibend. getOrderStatus liest sich für das Modell besser als get1. Das wird der Funktionsname.
  • Die `description` sagt dem Modell, wann es sie nutzen soll. Beachten Sie den Satz „Use this whenever a user asks...“. Das ist Intent-Routing.
  • Der `404` ist dokumentiert. Wenn das Modell einen 404 erhält, kann es dem Nutzer sagen „Ich konnte diese Bestellung nicht finden“, statt einen Status zu halluzinieren.

Nach dem Speichern zeigt ChatGPT die verfügbare Operation. Testen Sie sie, indem Sie dem GPT eine natürliche Frage stellen. Beim ersten Aufruf einer neuen Domain fragt ChatGPT beim Nutzer nach Bestätigung und sendet dann den Request.

Authentifizierung

Actions unterstützen im Builder drei Auth-Modi: None, API Key und OAuth. Das Schema oben legt fest, *was* aufgerufen wird; die Auth steuert, *wie Sie belegen, wer Sie sind*.

API Key

Die einfachste gesicherte Option. Sie fügen einen Key im GPT-Editor ein, wählen, wie er gesendet wird (Bearer-Header, Basic oder ein eigener Header), und OpenAI speichert ihn verschlüsselt. ChatGPT hängt ihn an jeden Aufruf. Fügen Sie Ihrem Schema einen passenden securitySchemes-Block hinzu:

yaml
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
security:
  - bearerAuth: []

Den Key teilen alle, die das GPT nutzen. Für einen Read-only-Endpoint im internen Netz mit eigenen Zugriffskontrollen ist das in Ordnung. Es ist *nicht* in Ordnung, wenn jeder Nutzer nur seine eigenen Daten sehen soll, denn das Modell würde mit einer gemeinsamen Identität agieren.

OAuth

Wenn Sie Identität pro Nutzer brauchen (jeder Support-Agent oder jeder Kunde authentifiziert sich selbst), nutzen Sie OAuth. Sie geben Authorization-URL, Token-URL, Client-ID, Client-Secret und Scopes an. ChatGPT führt den Standard-OAuth-Flow aus: Der Nutzer klickt Sign in, genehmigt den Zugriff auf Ihrem Auth-Server, und ChatGPT speichert das Token dieses Nutzers. Aufrufe tragen dann *die Berechtigungen dieses Nutzers*.

Das ist die richtige Wahl für alles, was Daten schreibt oder private Datensätze offenlegt. Das komplette Setup steht in der Actions-Authentifizierungs-Dokumentation.

Build a Custom GPT with Actions

Watch on YouTube

Eine Anmerkung zu Secrets und Rate Limits

Legen Sie Zugangsdaten niemals ins Schema selbst oder in die Instructions des GPT. Wer ein GPT nutzen kann, kann es manchmal dazu bringen, seine Konfiguration zu verraten. Bewahren Sie Secrets in den dafür vorgesehenen Auth-Feldern und schützen Sie Ihren Endpoint mit eigenem Rate Limiting. Ein beliebtes GPT kann echten Traffic erzeugen, und das Modell kann bei Fehlern erneut versuchen.

Die API für ein Modell entwerfen, nicht für einen Menschen

Eine REST-API für Engineers und eine für ein LLM unterscheiden sich in Feinheiten. Ziehen Sie hier an:

  • Liefern Sie kleines, flaches JSON. Die Response landet im Context Window und kostet Tokens. Streichen Sie Felder, die das Modell nicht braucht. Eine Bestellabfrage braucht nicht das komplette Audit-Log.
  • Nutzen Sie klare Feldnamen. estimatedDelivery ist besser als est_dlv_dt. Das Modell schließt über Namen.
  • Machen Sie Fehler lesbar. Geben Sie bei Fehlern eine menschenlesbare message zurück, damit das Modell sie weitergeben kann.
  • Halten Sie Operationen schmal. Ein Endpoint, der fünf Dinge tut, verwirrt das Routing. Besser getOrderStatus, cancelOrder und getInvoice als separate Operationen mit eigenen Beschreibungen.

Eine Konsequenz, die man sich einprägen sollte: Das Modell kann nur tun, was Ihr Schema *beschreibt*. Wenn es Bestellungen stornieren soll, brauchen Sie eine cancelOrder-Operation (ein POST oder DELETE) mit eigener Beschreibung und idealerweise OAuth, damit die Action als echter Nutzer mit Stornoberechtigung läuft.

Wissenscheck

1. Was ist der Hauptzweck einer GPT Action?

2. Warum betont die Lektion, dass Ihre OpenAPI-`description`-Felder „Prompt, nicht Dokumentation“ sind?

3. Wenn Sie Daten aus Google Drive für Suche und Retrieval in ChatGPT bringen wollen, was sollten Sie nutzen?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die korrekt beschreiben, was zur Laufzeit passiert, wenn ein GPT eine Action nutzt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Aussagen, die Actions von Connectors unterscheiden.

Wählen Sie alle richtigen Antworten aus.

Folgenreiche Aktionen und Bestätigung

Manche Aufrufe sind Read-only. Manche verändern die Welt: eine Zahlung erstatten, eine E-Mail senden, einen Datensatz löschen. ChatGPT behandelt diese anders.

Standardmäßig fragt ChatGPT den Nutzer um Bestätigung, bevor es eine Action auf einer neuen Domain aufruft. Bei Schreibvorgängen wollen Sie diese Reibung. Sie können Operationen so markieren, dass der Nutzer jedes Mal bestätigen muss, was bei allem Destruktiven gute Praxis ist. Behandeln Sie jedes POST, PUT, PATCH und DELETE als folgenreich, bis das Gegenteil bewiesen ist, und entwerfen Sie Ihren Endpoint so, dass ein Bestätigungsschritt günstig ist (etwa ein Flow mit zwei Aufrufen: einer für die Vorschau, einer für das Commit).

Behalten Sie eine klare Grenze im Kopf. Das GPT schließt über Ihre Beschreibungen und kann die falsche Operation aufrufen oder das falsche Argument übergeben. *Ihr Server* ist die eigentliche Autorität. Validieren Sie jeden Request serverseitig: prüfen, dass die Bestellung zum authentifizierten Nutzer gehört, dass der Betrag innerhalb der Grenzen liegt, dass die ID wohlgeformt ist. Gehen Sie nie davon aus, dass das Modell es richtig gemacht hat.

Wie das mit der API und dem Agents SDK zusammenhängt

Actions sind die Custom-GPT-Oberfläche für Tool-Nutzung. Darunter treibt dieselbe Idee die OpenAI API an, wo Sie Tools als JSON-Schemas definieren und das Modell einen strukturierten Tool-Call zurückgibt, den Ihr Code ausführt. Wenn Sie aus dem GPT-Builder herauswachsen (Sie brauchen eigene Logik zwischen den Aufrufen, ein eigenes UI oder Orchestrierung über viele Tools), wechseln Sie zur Responses API oder zum Agents SDK, wo Sie den Loop direkt steuern.

Der Migrationspfad ist klar: Die Beschreibungen und Parameter-Schemas, die Sie für eine Action geschrieben haben, übertragen sich fast direkt in Tool-Definitionen im Code. Sehen Sie GPT Actions als die gehostete Variante desselben Muster ohne eigene Orchestrierung. Prototypen Sie eine Integration als Action und heben Sie sie ins Agents SDK, wenn Sie volle Kontrolle brauchen.

Actions debuggen

Wenn ein Aufruf sich falsch verhält, arbeiten Sie das in dieser Reihenfolge durch:

1. Hat das Modell überhaupt aufgerufen? Wenn es aus dem Bauch heraus geantwortet hat, ist Ihre description zu schwach oder zu generisch. Ergänzen Sie den expliziten Trigger-Satz „Use this when...“.

2. Falsche Parameter? Prüfen Sie die description-Felder und Typen der Parameter. Mehrdeutigkeit hier erzeugt fehlerhafte Requests.

3. Auth-Fehler? Testen Sie den Endpoint mit genau demselben Key oder Token außerhalb von ChatGPT (ein curl-Aufruf), um zu isolieren, ob das Problem Ihre Auth oder die Konfiguration des GPT ist.

4. Schema beim Speichern abgelehnt? Der Editor validiert gegen OpenAPI 3.1. Fügen Sie Ihr YAML in einen externen Validator ein, um die problematische Zeile zu finden.

Ein schneller curl-Check, bevor Sie überhaupt den Builder anfassen:

bash
curl -s https://api.acme-shop.com/v1/orders/10428 \
  -H "Authorization: Bearer $ACME_TOKEN"

Wenn das sauberes JSON zurückgibt, ist die GPT-Seite nur Schema und Auth-Konfiguration.

Key Takeaways

  • Schreiben Sie Beschreibungen als Prompts, nicht als Dokumentation. Über die Felder operationId, summary und description entscheidet das Modell, wann und wie es Ihre API aufruft. Nehmen Sie in jede Operation einen expliziten Satz „Use this when...“ auf.
  • Passen Sie die Auth an die Identitätsanforderungen an. API Key für gemeinsame, Read-only-interne Endpoints; OAuth immer dann, wenn jeder Nutzer als er selbst agieren soll oder die Action Daten schreibt.
  • Behandeln Sie das Modell als nicht vertrauenswürdigen Input. Validieren Sie jeden Request serverseitig und markieren Sie Schreiboperationen als folgenreich, damit Nutzer bestätigen, bevor sich etwas ändert.
  • Halten Sie Responses klein und flach. Geben Sie nur die Felder zurück, die das Modell braucht; die Response verbraucht Context-Tokens, und das Modell schließt über Ihre Feldnamen.
  • Prototyp als Action, Aufstieg zum Agents SDK. Dieselben Schemas lassen sich übernehmen, also starten Sie im GPT-Builder und wechseln Sie zu Code, wenn Sie Orchestrierung oder eigene Logik zwischen den Aufrufen brauchen.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • operationId, summary und description der Action als Wann-verwenden-Prompts schreiben
  • OAuth für user-scoped Actions oder solche mit Schreibzugriff nutzen; API Keys nur für gemeinsame Read-only-Zugriffe
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.