AI Agent ohne Code mit jeder API verbinden

Der API Action builder von Quickchat AI verbindet deinen AI Agent aus einem Satz in einfacher Sprache mit einer REST API. Du beschreibst die API, die du aufrufen möchtest, zum Beispiel „den Lieferstatus einer Bestellung abrufen und dem Kunden sagen, wann sie ankommt“, und ein LLM mit Websuche liest die Live-Dokumentation dieser API und setzt eine vollständige, funktionierende Action zusammen. Dabei füllt es Methode, URL, Header, Parameter und die Beschreibung aus, die deinem Agent sagt, wann er sie verwenden soll. Es nennt die gelesene Dokumentation als Quelle, und wenn es keinen echten Endpoint bestätigen kann, sagt es das, statt zu raten.

Dieser Leitfaden erstellt zwei Live-Actions aus zwei getippten Sätzen, mit einem kostenlosen Konto, und belegt beide mit echten Aufrufen, die in der Inbox aufgezeichnet wurden. Dabei erklärt er was ein API-Aufruf tatsächlich für deinen Agent tut und was „Function Calling“ ist, der Mechanismus, auf dem diese Funktion läuft.

Alles unten wurde mit einem echten Agent gebaut und getestet. Jeder Screenshot, jedes generierte Feld und jeder API-Aufruf stammt aus diesem Build, und du kannst alles reproduzieren.

Das fertige Ergebnis: Ein Reisender fragt nach dem Wochenende, der Agent ruft mitten in der Konversation eine Wetter-API auf und antwortet mit Live-Zahlen.

Was du bauen wirst

Einen Support-Agent für Wanderlark Tours, einen fiktiven Anbieter von alpinen Wanderungen in kleinen Gruppen, der aus seinem Wissen antwortet und mitten in der Konversation zwei echte APIs aufruft. Beides zu bauen, zu testen und die Live-Aufrufe anzusehen dauert etwa fünfzehn Minuten:

1. Eine Wettervorhersage-Abfrage gegen Open-Meteo, aus einem Satz gebaut. Ohne Schlüssel, du brauchst also nur ein Quickchat-Konto.
2. NASAs Astronomy Picture of the Day gegen api.nasa.gov, für Wanderlarks Sternbeobachtungs-Add-on. Dafür brauchst du einen API-Schlüssel, genau deshalb ist es hier: Es zeigt den Ablauf mit dem Platzhalter [[secret]], bei dem die Aktivierung blockiert bleibt, bis du deinen Schlüssel einfügst.

Du wirst außerdem absichtlich einen Satz eingeben, dessen Erstellung der Builder ablehnt, weil zu sehen, wie er fehlschlägt, dazugehört, um zu wissen, wann du ihm vertrauen kannst.

Was du brauchst:

• Ein kostenloses Quickchat AI Konto (hier registrieren).
• Kein Code, kein Server. Für die zweite Action einen NASA API-Schlüssel: NASA betreibt zum Ausprobieren einen gemeinsamen, rate-limitierten DEMO_KEY, den die Screenshots verwenden, und stellt persönliche Schlüssel sofort auf api.nasa.gov aus.

Was bedeutet es, wenn ein AI Agent eine API aufruft?

Ein Agent, der APIs aufrufen kann, kann mitten in einer Konversation Dinge in echten Systemen abrufen oder ändern und dann mit dem Ergebnis antworten. Ein Chatbot kann dein Unternehmen beschreiben, ein Agent, der APIs aufruft, kann darin handeln.

Aus Sicht des Endnutzers ändert sich nichts außer der Antwort. Ein Reisender fragt „Wie wird das Wetter am Samstag in Interlaken?“ und sieht ein paar Sekunden lang einen Tipp-Indikator, dann eine Antwort mit echten Temperaturen. Er sieht kein Tool, keinen Request und keine JSON-Payload. Die zwei Sekunden dazwischen sehen so aus:

Der Reisende sieht eine Frage und eine Antwort. Dazwischen hat das Modell eine Action gewählt, ihre Werte gefüllt, und Quickchat hat einen echten HTTP-Request ausgeführt: 280 ms der ungefähr zwei Sekunden.

Du kannst sogar festlegen, was der Besucher während dieser Pause sieht. Jede Action kann eine Thinking message enthalten, eine kurze Zeile, die das Website-Widget anstelle des generischen „Thinking…“ anzeigt, während der Aufruf läuft. Wanderlarks Forecast-Action setzt eine solche Zeile, daher sieht der Reisende während dieser zwei Sekunden tatsächlich Folgendes:

Die Ansicht auf Besucherseite während des Aufrufs: Die benutzerdefinierte Denk-Zeile schimmert dort, wo die Antwort erscheinen wird. Du setzt diese Zeile später im Action Editor.

Nichts davon ist spezifisch für Wetter. Jedes System, das eine HTTP API bereitstellt, kann am anderen Ende einer Action sitzen: deine Bestelldatenbank, ein Buchungssystem, ein CRM, ein Ticketsystem, eine Messaging-Plattform. Abfragen beantworten Fragen mit Live-Daten, Schreibvorgänge ändern etwas und hinterlassen einen Datensatz.

Jede Kachel ist ein beschriebener HTTP-Request. Dieser Leitfaden baut zwei der Abfragen, die Schreibmuster werden in den am Ende verlinkten Leitfäden behandelt.

Historisch war der Haken, dass man für die Einrichtung einer solchen Verbindung API-Dokumentation lesen und den Request von Hand ausfüllen musste. Genau diesen Teil entfernt der Builder.

Wie funktioniert der Action Builder in einfacher Sprache?

Du beschreibst die API in einem Satz, und ein LLM mit Live-Websuche macht daraus eine vollständige Action. Es durchsucht während der Generierung die Dokumentation der API, entwirft Methode, URL, Header, Query-Parameter und die Beschreibung, die deinem Agent sagt, wann er sie aufrufen soll, und gibt das Ergebnis mit Links zu den gelesenen Dokumentationsseiten zurück. Die Generierung dauert etwa eine halbe Minute, und das Ergebnis öffnet sich in einem Dialog, sobald es bereit ist.

Der Builder liefert nur aus, was er in der Dokumentation bestätigt hat. Alles, was er nicht bestätigen konnte, wird zu einem Platzhalter oder einer Ablehnung, nie zu einer Vermutung.

Drei Eigenschaften machen die Nutzung sicher:

• Nichts läuft, bis du es aktivierst. Jede generierte Action kommt deaktiviert an, damit du sie prüfen kannst.
• Unbekanntes wird zu Platzhaltern, nicht zu Vermutungen. Werte, die das Modell pro Aufruf füllen soll (ein Datum, eine Stadt), werden zu {{param}}-Lücken. Konstanten, die nur du kennst (ein API-Schlüssel), werden zu [[secret]]-Lücken, und die Aktivierung wird blockiert, bis du sie ersetzt.
• Er zeigt seine Arbeit. Das Ergebnis listet die gelesenen Dokumentationsseiten auf, jeweils mit einem Hinweis, was diese Seite bestätigt hat. Der Review beginnt also mit Belegen statt Vertrauen:

Quellenangaben aus einer zweiten Generierung desselben Wettersatzes, die später in diesem Leitfaden verwendet wird: die Dokumentationsseite plus ihre API-Abschnitte, jeweils mit dem, was der Builder dort bestätigt hat.

Schritt 1: Erstelle den Reise-Agent

Erstelle zuerst den Agent, damit die Actions zu etwas gehören. Nach der Registrierung benennst du den Agent (dieser Build verwendet Wanderlark) und gibst ihm seine Aufgabe im Feld AI Main Prompt unter Identity im Dashboard:

Du bist der Assistent für Wanderlark Tours, einen Anbieter von alpinen Wanderungen in kleinen Gruppen. Wanderlark bietet drei geführte Touren an: Interlaken Classic, Zermatt Highline und Dolomites Traverse, plus das Sternbeobachtungs-Add-on Dark-Sky Nights. Hilf Reisenden, eine Tour auszuwählen, Daten, Preise, Schwierigkeitsgrad und Packliste zu verstehen, und beantworte Fragen zu Buchung und Stornierung. Sei freundlich, praktisch und knapp, und halte Antworten kurz.

Antworte nur auf Grundlage dessen, was du tatsächlich über Wanderlark weißt. Wenn dir ein Detail fehlt, sage, dass du es nicht hast, und biete an, sie mit dem Wanderlark-Team zu verbinden, statt zu raten.

Füge dann unter Knowledge Base einige Fakten hinzu, damit er etwas hat, aus dem er antworten kann. Die Demo verwendet fünf kurze Artikel (Touren und Preise, das Dark-Sky Nights Add-on, Buchung und Stornierung, Packliste, Treffpunkte), der vollständige Text steht im Kopierblock am Ende. Wir erweitern diesen Prompt mit zwei action-spezifischen Zeilen, nachdem die Actions existieren. Wenn du die Schritt-für-Schritt-Anleitung für Prompts und Wissen von null an möchtest, führt der unten verlinkte Master-Recipe-Beitrag durch jeden Schritt.

Schritt 2: Beschreibe die API in einem Satz

Öffne in der Seitenleiste Actions & MCPs, klicke auf Add Action und wähle API Action, den ersten Eintrag im Menü.

Benutzerdefinierte Actions liegen unter Actions & MCPs. Der Eintrag API Action öffnet den Beschreibungsdialog.

Der geöffnete Dialog fordert dich auf, die API zu beschreiben, die diese Action aufrufen soll, und den Endpoint zu nennen oder die Dokumentation zu verlinken. Hier ist der exakte Satz für die Wetter-Action:

Rufe die tägliche Wettervorhersage für einen Ort über die Open-Meteo API (Dokumentation: https://open-meteo.com/en/docs) ab, damit der Agent mit echten Temperaturen und Regenwahrscheinlichkeiten für die angefragten Tage antworten kann, wenn ein Reisender fragt, wie das Wetter an einem unserer Ziele wird.

Ein Satz: welche API, ein Dokumentationslink, wann der Agent sie verwenden soll und was er mit dem Ergebnis tun soll.

Dieser Satz enthält die drei Dinge, die eine gute Beschreibung braucht:

1. Eine konkrete API, einen Endpoint oder eine Dokumentations-URL. „Die Open-Meteo API“ plus Dokumentationslink gibt dem Builder etwas Echtes zum Lesen. Ohne das bekommst du eine Ablehnung statt einer Action.
2. Wann der Agent sie verwenden soll. „Wenn ein Reisender fragt, wie das Wetter wird“ landet fast wörtlich in der Beschreibung, die die Action später auslöst.
3. Was mit dem Ergebnis zu tun ist. „Mit echten Temperaturen und Regenwahrscheinlichkeiten antworten“ prägt, wie der Agent die Response nutzt.

Das Feld erlaubt bis zu 500 Zeichen, was mehr Platz ist, als eine gute Beschreibung braucht. Jeder Satz in diesem Leitfaden passt mit reichlich Reserve hinein.

Klicke auf Submit. Der Dialog schließt sich, ein Toast informiert dich, dass die Action vorbereitet wird, und etwa eine halbe Minute später öffnet sich der Ergebnisdialog von selbst:

Der ganze Ablauf in Echtzeit, mit gekürzter Wartezeit: beschreiben, absenden und prüfen, was zurückkam.

Was steckt in der generierten Action?

Der Ergebnisdialog ist eine Review-Oberfläche. Links siehst du eine Vorschaukarte der neuen Action, genau so, wie sie auf deiner Actions-Seite erscheint. Rechts Details: Der Builder erklärt, was er gebaut hat, welche Werte das Modell zur Laufzeit füllt und was er angenommen hat, wenn dein Satz etwas offenließ. Darunter Sources: die gelesene Dokumentation als Links.

Der Builder erklärt seine Arbeit Feld für Feld. Wenn du im Dialog scrollst, listet der Sources-Abschnitt auf, was er für diese Action gelesen hat: Open-Meteos Dokumentationsseite und die OpenAPI-Spezifikation des Projekts auf GitHub, jeweils mit einem Hinweis, was bestätigt wurde.

Für den Wettersatz generierte der Builder eine Action namens get_open_meteo_daily_forecast (Builder-Namen sehen aus, als hätte sie ein Entwickler geschrieben, du kannst sie im Editor umbenennen). Klicke in der Vorschau auf Edit Action, um jedes gefüllte Feld zu sehen:

Alles, was eine von Hand gebaute Action hat, ausgefüllt: der Name, die Parametertabelle unter „What to ask the user first“ und der Endpoint.

Von oben nach unten:

• API Action Name: Was das Modell als Namen des Tools sieht.
• What to ask the user first: die Parametertabelle. Der Builder hat sieben Parameter deklariert, jeweils mit Typ und Beschreibung: latitude, longitude, timezone, start_date, end_date plus optionale Einheiten. Das sind die {{param}}-Werte, die das Modell pro Aufruf füllt. Beachte, was hier nicht steht: kein „city“-Parameter. Der Builder hat den Endpoint so verdrahtet, wie Open-Meteo tatsächlich funktioniert, über Koordinaten, und die Geografie dem Modell überlassen. Gleich siehst du, dass es diese Koordinaten korrekt füllt.
• API Endpoint: GET https://api.open-meteo.com/v1/forecast, mit verdrahteten Query-Parametern. Feste Werte bleiben literal, etwa die vom Builder gewählte daily-Liste der Forecast-Variablen. Vom Modell gefüllte Werte erscheinen als farbige {{...}}-Chips.

Feste Teile bleiben fest, die farbigen Chips sind die Lücken, die das Modell füllt. Die Chips sind die eigene Legende der UI dafür, was woher kommt.

Der vierte Tab des Endpoint-Editors, Test Response, führt den echten Request aus, bevor die Action je einem Besucher begegnet. Jeder Parameter erhält ein Feld „Your test value“. Fülle plausible Werte ein, drücke den Play-Button („Test the API“), und die tatsächliche Response kommt mit Statuscode zurück. Ein Show cURL-Schalter zeigt, in den eigenen Worten der UI, „the exact HTTP request that would be triggered when this AI Action runs with these parameters“. Hier ist der Test dieses Builds, wieder mit den Koordinaten von Interlaken:

Ein echter 200 von Open-Meteo, aus dem Editor ausgelöst, mit dem aufgelösten Request direkt darunter. Prüfen, testen, dann aktivieren.

• API Action Description: Der Satz, der entscheidet, wann der Agent diese Action verwendet. Der Builder schrieb ihn aus deiner „wenn ein Reisender fragt“-Klausel. Dieses Feld leistet zur Laufzeit die meiste Arbeit, und es ist das erste Feld, das du anpasst, wenn der Agent die Action jemals im falschen Moment auslöst.
• Thinking message: die Zeile auf Reisendenseite aus der Zeitleiste oben. Der Editor beschreibt sie als „a thinking preloader that will be displayed to the user when this action is invoked“. Wanderlarks Forecast-Action setzt sie auf „Checking the live forecast for you…“.

Die Action kam deaktiviert an. Öffne sie im Editor, und Quickchat zeigt ein Banner, das sagt, dass die Action deaktiviert ist, mit einem Enable-Button. Alternativ legst du den Schalter auf ihrer Karte auf der Actions-Seite um. Da es hier nichts auszufüllen gab, wird sie sofort aktiviert.

Erst prüfen, dann einschalten. Nichts ruft irgendetwas auf, bis du das tust.

Wenn du diese gleiche Action lieber Feld für Feld von Hand bauen und jede Box von Grund auf verstehen möchtest, ist das der grundlegende Leitfaden: Einen kostenlosen AI Agent bauen, der Actions ausführt. Der Builder und der manuelle Editor erzeugen dieselbe Art von Action, dieser Beitrag ist der generierte Weg.

Schritt 3: Teste sie und beobachte den Aufruf

Stelle dem Agent eine Frage, die die Action auslösen sollte. Die Transkripte hier liefen durch Quickchats Test-Pipeline und wurden wie jede Konversation in der Inbox aufgezeichnet. In deinem Konto gibt dir der Bereich AI Preview in der Seitenleiste denselben Loop im Browser.

Die Testnachricht:

Hallo! Wir machen nächstes Wochenende die Interlaken Classic. Wie wird das Wetter in Interlaken am Samstag, 25. Juli, und Sonntag, 26. Juli?

Der Agent antwortete mit der echten Vorhersage: etwa 27,7 °C und nahezu regenfrei für Samstag, kühler mit bis zu 18 mm Regenwahrscheinlichkeit für Sonntag, plus Packempfehlungen aus seinem Wissen.

Der Beleg steht in der Inbox. Unter der Antwort des Agent gibt es eine Markierung „1 action called“. Klappe sie auf, und du bekommst den vollständigen Datensatz dessen, was passiert ist:

Der Aufrufdatensatz: get_open_meteo_daily_forecast, HTTP 200 in 280 ms, und jeder Wert, den das Modell gefüllt hat.

Lies die Parameter, die das Modell gewählt hat: latitude: 46.6863, longitude: 7.8632, timezone: Europe/Zurich, start_date: 2026-07-25, end_date: 2026-07-26. Niemand hat Koordinaten getippt. Der Reisende sagte „Interlaken“, und das Modell übersetzte das in die Werte, die die API braucht, präzise genug, um die Stadt zu treffen. Das ist die Urteilskomponente des Systems bei der Arbeit. Die deterministische Hälfte (URL, Methode, feste daily-Variablenliste) ging exakt wie geprüft hinaus.

Was ist Function Calling bei AI Agents?

Der obige Beleg zeigt den Mechanismus, den die Branche Function Calling nennt: Ein Sprachmodell entscheidet sich mitten in der Konversation, statt eines Satzes einen strukturierten Aufruf an ein vordefiniertes Tool auszugeben, die Plattform führt ihn aus, und das Modell fährt mit dem Ergebnis fort.

Function Calling am echten Aufruf dieses Leitfadens. Das Modell erzeugt nur die strukturierten Werte, die Plattform besitzt den Request, die API ist normales HTTP.

Ein paar Dinge ergeben sich aus dem Diagramm:

• Das Modell entscheidet, die Plattform führt aus. Das Modell sendet nie Bytes an Open-Meteo. Es erzeugt {"latitude": 46.6863, ...}, und Quickchat setzt diese Werte in den Request ein, den du geprüft hast. Die Teile, die du festgelegt hast, die URL, die Methode, jedes Secret, kann das Modell nicht ändern.
• „Tool Calling“ ist dasselbe. Die zwei Namen beschreiben denselben Mechanismus, Tool Calling ist der neuere, allgemeinere Begriff. Eine AI Action ist eine Tool-Definition: Ihr Name, ihre Beschreibung und ihre Parametertabelle sind genau das, was das Modell liest, wenn es entscheidet, ob und wie es sie aufruft. Deshalb ist das Beschreibungsfeld so wichtig. Konzeptuell entspricht die ganze Definition, die das Modell sieht, etwa Folgendem:

name:        get_open_meteo_daily_forecast
description: Verwende diese Action, wenn ein Reisender fragt, wie das Wetter an bestimmten kommenden Tagen an einem Zielort wird...
parameters:  latitude (number, required), longitude (number, required), timezone (text, required), start_date (text, required), end_date (text, required), temperature_unit (text), precipitation_unit (text)

• Die API-Seite ist gewöhnlich. Open-Meteo hat dafür keine AI-Unterstützung eingebaut. Jeder Endpoint, der HTTP spricht und JSON zurückgibt, kann ein Tool sein. Deshalb lässt sich das Ein-Satz-Rezept auf dein eigenes Backend übertragen.

Jede große Modellfamilie unterstützt diesen Mechanismus. Zwischen Plattformen unterscheidet sich, wer die Tool-Definitionen schreibt. In Entwicklerplattformen und benutzerdefinierten GPT Actions bist das du, von Hand, in einem Schema. Der Builder, den du in Schritt 2 verwendet hast, ist Function Calling ohne Schema-Schreibarbeit: Aus deinem Satz wurde die Tool-Definition. Für die technische Sicht auf dieses Umfeld, von Protokollen wie MCP bis zu benutzerdefinierten Endpoints, siehe APIs für AI Agents: Von MCP zu benutzerdefinierten Endpoints.

Schritt 4: Eine API, die einen Schlüssel braucht

Die meisten echten APIs wollen Zugangsdaten. Hier kommt die zweite Platzhalterart des Builders ins Spiel, und Wanderlarks Sternbeobachtungs-Add-on liefert einen natürlichen Anlass: Gäste auf Dark-Sky Nights fragen gern nach NASAs Astronomy Picture of the Day.

Öffne Add Action, wähle erneut API Action und beschreibe sie. Sage dem Builder diesmal direkt, dass du den Schlüssel bereitstellst:

Rufe NASAs Astronomy Picture of the Day über die NASA APOD API (GET https://api.nasa.gov/planetary/apod) ab, damit Gäste, die neugierig auf unser Dark-Sky Nights Add-on sind, nach dem heutigen Astronomiebild fragen und seinen Titel sowie das, was es zeigt, hören können. Ich stelle meinen eigenen NASA API-Schlüssel bereit.

„Ich stelle meinen eigenen API-Schlüssel bereit“ sagt dem Builder, dass er eine saubere Lücke lassen soll, statt bei der Authentifizierung zu raten.

Eine halbe Minute später öffnet sich der Ergebnisdialog, und er sieht in einem wichtigen Punkt anders aus: ein bernsteinfarbenes Panel mit dem Titel „Replace before activating“, das genau eine Sache auflistet: [[nasa_api_key]]. Die Vorschaukarte trägt ein rotes Incomplete-Badge, und ihr Aktivierungsschalter ist aus und bleibt aus.

Der Builder hat die ganze Action verdrahtet und eine Lücke gelassen, die er nicht füllen konnte: deinen Schlüssel. Bis du sie ersetzt, kann die Action nicht eingeschaltet werden.

Auf der Actions-Seite ist der Schalter vollständig deaktiviert, mit einem Tooltip, der erklärt, warum:

Die Aktivierung ist auf Plattformebene blockiert, solange ein [[secret]] übrig ist. Eine Action mit einem Platzhalter an der Stelle des Schlüssels kann nicht um 3 Uhr morgens fehlschlagen, weil sie nicht laufen kann.

Die zwei Platzhalterarten haben unterschiedliche Besitzer:

Eine URL, beide Arten: {{date}} ist die Lücke des Modells, pro Aufruf aus der Konversation gefüllt. [[nasa_api_key]] gehört dir und wird einmal eingefügt.

Fülle sie jetzt. NASA stellt persönliche Schlüssel sofort aus (Name und E-Mail auf api.nasa.gov, der Schlüssel kommt per Mail) und dokumentiert den gemeinsamen DEMO_KEY zum Ausprobieren, den dieser Build verwendet:

1. Klicke auf der Karte der Action auf Edit Action und öffne dann den Tab Query Params im Abschnitt API Endpoint.
2. Die Zeile api_key enthält den bernsteinfarbenen [[nasa_api_key]]-Chip. Klicke in den Wert und ersetze ihn durch deinen Schlüssel.
3. Klicke auf Save changes.

Der Platzhalter ist ein normaler bearbeitbarer Wert. Ersetze ihn und speichere.

Beachte dann, was du nicht tun musstest: den Schalter umlegen. Wenn ein Speichern eine schreibgeschützte GET-Action erstmals vollständig und gültig macht, aktiviert Quickchat sie für dich. Actions, die schreiben (POST, PUT, PATCH, DELETE), tun das nie. Sie warten auf eine bewusste Aktivierung, was der richtige Standard für alles ist, was Daten verändert.

Einfügen, speichern, und eine schreibgeschützte Abfrage schaltet sich selbst ein. Schreib-Actions überlassen die letzte Entscheidung immer dir.

Teste sie genauso wie die Vorhersage:

Wir haben das Dark-Sky Nights Add-on zu unserer Zermatt Highline Reise hinzugefügt. Worum geht es beim heutigen Astronomiebild?

Der Agent hat das heutige Bild „Shadow and Rainbow“ abgerufen und zusammengefasst, was es zeigt.

Und wieder der Beleg in der Inbox:

HTTP 200 von api.nasa.gov. Der einzige vom Modell gefüllte Wert ist das Datum, leer gelassen, sodass NASA standardmäßig heute verwendet. Der Schlüssel erscheint nirgends in diesem Datensatz: Er ist kein Parameter, also kann das Modell ihn nie füllen oder preisgeben.

Was passiert, wenn der Builder die API nicht finden kann?

Der Builder erzeugt nicht immer eine Action, und das ist Absicht. Gib einen Satz ein, der ein Verhalten beschreibt, aber keine API nennt:

Lass meinen Agent Reisenden helfen, ihre Tour umzubuchen, wenn das Wetter schlecht aussieht.

Der Builder sucht, findet keine einzelne API, die er verantwortungsvoll für dich auswählen könnte, und kommt mit einem anderen Dialog zurück: „We need a bit more detail“. Es wird keine Action erstellt. Das Details-Panel erklärt genau, was fehlt (welcher Wetteranbieter? welches Buchungssystem?) und zeigt die Umformulierung, bis hin zu einem Beispielsatz mit einem konkreten Endpoint.

Eine Ablehnung mit Reparaturset: was mehrdeutig war, warum Raten falsch wäre, und ein Beispiel für einen Satz, der funktionieren würde.

Es gibt eine zweite Art der Ablehnung. Beschreibe etwas, das Quickchat bereits nativ kann:

Übergib die Konversation an einen menschlichen Guide, wenn der Reisende frustriert wirkt oder darum bittet, mit einer Person zu sprechen.

Der Builder erkennt dies als eingebauten Bereich und verweist dich, statt eine externe API um ein gelöstes Problem zu wickeln, auf die Funktion, mit einem Set up Human Handoff-Button direkt im Dialog:

Nicht jede Fähigkeit sollte eine benutzerdefinierte Action sein. Eskalation an einen Menschen ist eingebaut, und der Builder leitet dich dorthin, statt sie zu duplizieren.

Die exakten Sätze und Einstellungen zum Kopieren

Alles, was die Demo verwendet hat, an einem Ort. Die zwei Sätze, die die Actions generiert haben:

Rufe die tägliche Wettervorhersage für einen Ort über die Open-Meteo API (Dokumentation: https://open-meteo.com/en/docs) ab, damit der Agent mit echten Temperaturen und Regenwahrscheinlichkeiten für die angefragten Tage antworten kann, wenn ein Reisender fragt, wie das Wetter an einem unserer Ziele wird.

Rufe NASAs Astronomy Picture of the Day über die NASA APOD API (GET https://api.nasa.gov/planetary/apod) ab, damit Gäste, die neugierig auf unser Dark-Sky Nights Add-on sind, nach dem heutigen Astronomiebild fragen und seinen Titel sowie das, was es zeigt, hören können. Ich stelle meinen eigenen NASA API-Schlüssel bereit.

Der AI Main Prompt, einschließlich der zwei Action-Zeilen, die hinzugefügt wurden, nachdem die Actions existierten. Die Actions und ihre Auslösemomente im Prompt zu nennen macht das Auslösen merklich zuverlässiger. Die zu verwendenden Action-Namen sind die generierten Namen, die du im Editor gesehen hast:

Du bist der Assistent für Wanderlark Tours, einen Anbieter von alpinen Wanderungen in kleinen Gruppen. Wanderlark bietet drei geführte Touren an: Interlaken Classic, Zermatt Highline und Dolomites Traverse, plus das Sternbeobachtungs-Add-on Dark-Sky Nights. Hilf Reisenden, eine Tour auszuwählen, Daten, Preise, Schwierigkeitsgrad und Packliste zu verstehen, und beantworte Fragen zu Buchung und Stornierung. Sei freundlich, praktisch und knapp, und halte Antworten kurz.

Wenn ein Reisender fragt, wie das Wetter an einem Zielort an kommenden Tagen wird, rufe get_open_meteo_daily_forecast auf und antworte mit den echten Zahlen für die angefragten Tage. Wenn ein Gast nach dem heutigen Astronomiebild fragt oder danach, was er in einer Dark-Sky Night sehen könnte, rufe get_tonights_nasa_apod auf und beschreibe den Titel des Bildes und was es zeigt.

Antworte nur auf Grundlage dessen, was du tatsächlich über Wanderlark weißt. Wenn dir ein Detail fehlt, sage, dass du es nicht hast, und biete an, sie mit dem Wanderlark-Team zu verbinden, statt zu raten.

Die generierten API Action Descriptions, so wie der Builder sie geschrieben hat (passe diese an, nicht die URL, wenn das Auslöseverhalten Arbeit braucht):

Verwende diese Action, wenn ein Reisender fragt, wie das Wetter an bestimmten kommenden Tagen an einem Zielort wird, und du echte tägliche Vorhersagedaten (Höchst-/Tiefsttemperaturen und Regenwahrscheinlichkeit) von der Open-Meteo API brauchst. Der Assistent sollte dies mit Breiten-/Längengrad des Zielorts, Datumsbereich und bevorzugten Einheiten aufrufen und dann die JSON-Response verwenden, um die vorhergesagten Temperaturen und Niederschlagswahrscheinlichkeiten für die angefragten Tage in natürlicher Sprache zu beschreiben.

Verwende diese Action, wenn ein Gast im Zusammenhang mit deinem Dark-Sky Nights Add-on nach dem heutigen Astronomy Picture of the Day fragt, damit du NASAs offizielle APOD-Metadaten abrufen und den Titel sowie das, was das Bild zeigt, beschreiben kannst. Die Action ruft NASAs APOD API für das angegebene Datum auf (standardmäßig heute, wenn kein Datum angegeben ist) und gibt JSON zurück, einschließlich Bild- oder Video-URL, Titel, Erklärung und Medientyp, die der Assistent für den Gast im Gespräch zusammenfassen sollte.

Die Thinking message, die auf der Forecast-Action gesetzt wurde (die Zeile, die das Widget anzeigt, während der Aufruf läuft):

Ich prüfe die Live-Vorhersage für dich...

Die fünf Knowledge Base Artikel, auf ihre Fakten gekürzt:

Touren: Interlaken Classic, 3 Tage, leicht bis moderat, 890 Euro, max. 10 Gäste, Mai bis Oktober. Zermatt Highline, 4 Tage, moderat bis anspruchsvoll, 1.290 Euro, max. 8, Juni bis September. Dolomites Traverse, 5 Tage, anspruchsvoll, 1.590 Euro, max. 8, Ende Juni bis Mitte September, von Hütte zu Hütte. Preise enthalten Guide, Unterkunft, Frühstück.

Dark-Sky Nights: Sternbeobachtungs-Add-on auf Zermatt Highline und Dolomites Traverse, 120 Euro pro Person, geführte Nachtwanderung mit Teleskop, geplant um Neumond; wegen Wolken ausgefallene Sessions werden verschoben oder erstattet.

Buchung: 200 Euro Anzahlung, Restbetrag 30 Tage vor Start fällig. Kostenlose Stornierung bis 30 Tage; 50 Prozent Erstattung 29 bis 14 Tage; innerhalb von 14 Tagen keine Erstattung, aber eine kostenlose Umbuchung innerhalb von 12 Monaten.

Packliste: Schichten, wasserdichte Hardshell, eingelaufene Stiefel, 30-Liter-Tagesrucksack; Stöcke und Steigeisen werden gestellt; kalte Abende auch im Sommer.

Treffpunkte: Bahnhof Interlaken Ost; Bahnhof Zermatt (autofrei, Shuttle ab Täsch); Cortina d'Ampezzo, Flughafentransfer Venedig 45 Euro je Strecke.

Wie beschreibe ich eine API, damit der Builder es richtig macht?

Drei Regeln decken alles ab, was dieser Build berührt hat, und der Fehlerdialog lehrt dieselbe Lektion von der anderen Seite:

Das Muster hinter jedem Ergebnis in diesem Leitfaden: konkrete API hinein, funktionierende Action heraus. Nur Verhalten hinein, Anleitung zurück.

1. Nenne die API, den Endpoint oder füge eine Dokumentations-URL ein. „Die Open-Meteo API (Dokumentation: …)“ erzeugte eine korrekte Action, die auf zwei zitierten Quellen beruht. „Ihre Tour umbuchen, wenn das Wetter schlecht aussieht“ erzeugte eine Ablehnung, weil es einen Wunsch nennt, keine API. Der Builder braucht etwas Konkretes, das er lesen kann, und auf dieser Regel beruhen die anderen beiden.
2. Sage, wann der Agent sie verwenden soll und was er danach sagen soll. Deine Auslöseklausel wird nahezu wörtlich zur Action-Beschreibung, und die Beschreibung löst die Action zur Laufzeit aus. „Wenn ein Reisender fragt, wie das Wetter wird“ ist ein Signal, das das Modell mitten in der Konversation erkennen kann.
3. Sage, wie die Zugangsdaten funktionieren, falls es welche gibt. „Ich stelle meinen eigenen NASA API-Schlüssel bereit“ führte dazu, dass Auth sauber als [[secret]] modelliert wurde. Der Builder tendiert auch von selbst in diese Richtung: Er bevorzugt statische, langlebige Zugangsdaten wie Schlüssel und Webhook-URLs gegenüber kurzlebigen OAuth-Tokens, weil die Action bei jedem Aufruf unverändert läuft, ohne Token-Refresh-Mechanik.

Und eine Nicht-Regel: Du musst keine Parameter, Formate oder Response-Felder angeben. Der Builder las Open-Meteos Dokumentation und wählte sieben Parameter, sinnvolle Defaults und die richtigen täglichen Variablen, ohne darum gebeten zu werden. Prüfe im Editor, was er gewählt hat, statt es vorab diktieren zu wollen.

Iteration selbst ist billig. Es gibt keinen Regenerate-Button. Wenn ein Entwurf falsch herauskommt, lösche ihn und sende einen schärferen Satz erneut, etwa eine halbe Minute pro Versuch. Konten können bis zu 15 erstellte Actions enthalten, räume Entwürfe also währenddessen auf.

Live gehen

Die Aktivierung hat es bereits erledigt. Actions gehören zum Agent, nicht zu einem Kanal. Deshalb werden die zwei Abfragen, die du gebaut hast, auf dieselbe Weise aus dem Website-Widget, WhatsApp, Messenger, Slack, Telegram, Discord oder überall sonst ausgelöst, wo der Agent bereitgestellt ist, wobei jeder Aufruf in der Inbox aufgezeichnet wird. Wenn das Website-Widget der Hauptkanal ist, kannst du den AI Chatbot mit White-Labeling versehen, ohne die Action zu ändern. Dasselbe gilt für Dinge, die er nicht beantworten kann: Nach Winter-Schneeschuhtouren gefragt, sagt Wanderlark, dass es keine anbietet, statt zu improvisieren.

Nach etwas außerhalb seines Wissens gefragt, sagt der Agent das, statt zu improvisieren. Dieselbe Zurückhaltung gilt für seine API-Aufrufe.

Zwei naheliegende nächste Schritte, sobald deine ersten Actions live sind:

• Mache das Auslösen deterministisch, wo es wichtig ist. Action-Beschreibungen entscheiden, wann das Modell aufruft. Für Actions, die nur unter bestimmten Bedingungen laufen dürfen, füge serverseitige Run Conditions und Memory Captures hinzu: So machst du die Actions deines AI Agent zuverlässig.
• Nutze die One-Click-Integrationen für Tools, die sie haben. Dasselbe Add Action Menü enthält die anderen Wege: HubSpot Action, Discord Action und Google Sheets werden als fertige Galerien geliefert, Shopify MCP verbindet den Katalog eines Shops, und MCP verbindet jeden Remote-MCP-Server, aus einem Katalog von 240+ oder einer eingefügten URL, und importiert die Tools dieses Servers. Die Leitfäden unten führen durch die Galerien.

Drei Wege zum selben Ziel, eine Faustregel:

Verwandte Leitfäden

• Verbinde deinen AI Agent mit HubSpot: Kontakte, Deals und Tickets mitten in der Konversation schreiben, mit dem Sicherheitsmuster für Write-only.
• Mache deinen AI Agent zu einem MCP-Server: die umgekehrte Form, bei der ChatGPT, Claude und Cursor deinen Agent aufrufen.
• Baue einen AI Telegram Bot zur Verwaltung deiner Gruppe: sechs von Hand gebaute Bot API Actions mit Admin-Gating.
• AI Discord Moderationsbot: Moderations-Actions mit korrekt umgesetzten Berechtigungen und Autorisierung.
• AI Discord Ticket-Bot: die Support-Hälfte derselben Galerie, die aus einer Knowledge Base antwortet und private Ticket-Threads öffnet.
• Verbinde deinen AI Agent mit Google Sheets: die One-Click-Reporting-Integration.

Häufig gestellte Fragen

Wie verbinde ich einen AI Agent ohne Code mit einer API?

Öffne in Quickchat AI Actions & MCPs, klicke auf Add Action, wähle API Action und beschreibe die API in einem Satz in einfacher Sprache. Ein LLM mit Live-Websuche liest die Dokumentation der API und generiert die vollständige Action, mit Methode, URL, Parametern und Beschreibung. Du prüfst sie, ergänzt Platzhalterwerte wie einen API-Schlüssel und aktivierst sie.

Was ist Function Calling bei AI Agents?

Function Calling ist der Mechanismus, bei dem ein Sprachmodell mitten in einer Konversation statt normalem Text einen strukturierten Request ausgibt, um ein vordefiniertes Tool auszuführen. Die Plattform führt das Tool aus, in diesem Fall einen HTTP-Request, und gibt das Ergebnis an das Modell zurück, das seine Antwort dann mit echten Daten schreibt. Jeder AI Action Aufruf in diesem Leitfaden ist ein Function Call.

Ist Function Calling dasselbe wie Tool Calling?

Ja. Function Calling und Tool Calling bezeichnen denselben Mechanismus, Tool Calling ist der neuere, allgemeinere Begriff. Eine AI Action ist eines dieser Tools: ein beschriebener HTTP-Request, den das Modell während einer Konversation aufrufen kann.

Woher weiß der Builder, wie die API aussieht?

Er führt während der Generierung eine Live-Websuche in der Dokumentation der API aus und setzt die Action nur aus dem zusammen, was er dort bestätigen konnte. Der Ergebnisdialog listet die gelesenen Quellen auf, damit du sie prüfen kannst, bevor du die Action aktivierst.

Was ist der Unterschied zwischen {{param}}- und [[secret]]-Platzhaltern?

Ein {{param}}-Wert wird bei jedem Aufruf vom Modell aus der Konversation gefüllt, zum Beispiel ein Datum oder eine Stadt. Ein [[secret]]-Wert ist eine Konstante, die du vor der Aktivierung einmal einfügst, zum Beispiel ein API-Schlüssel. Das Modell wählt oder bearbeitet Secrets nie, und sie sind keine Parameter, die es füllen kann.

Wo kommt mein API-Schlüssel hin, und kann ein Besucher ihn aus dem Agent herausbekommen?

Du ersetzt den [[secret]]-Platzhalter innerhalb der Action im Editor, bevor du sie aktivierst. Der Schlüssel wird Teil des festen Requests, den Quickchat sendet. Er ist kein Parameter, deshalb kann das Modell ihn nicht ändern, und er erscheint nicht im Action-Call-Datensatz der Konversation.

Erstellt der Builder nur GET-Abfragen, oder kann der Agent auch Daten schreiben?

Beides. Derselbe Ein-Satz-Ablauf generiert POST-, PUT-, PATCH- und DELETE-Actions. Schreibgeschützte GET-Actions aktivieren sich selbst, sobald sie vollständig und gültig sind, Schreib-Actions warten immer darauf, dass du sie bewusst aktivierst.

Kann er sich mit privaten oder internen APIs verbinden?

Ja, solange der Endpoint von Quickchat aus über HTTPS erreichbar ist. Der Builder stützt sich auf öffentliche Dokumentation. Beschreibe bei einer internen API den Endpoint daher explizit in deinem Satz oder generiere eine nahe Vorlage und passe URL und Felder im Editor an.

Was passiert, wenn ich ein Verhalten statt einer bestimmten API beschreibe?

Der Builder schlägt geschlossen fehl. Statt einen Endpoint zu erfinden, erklärt er, was fehlt, und zeigt dir, wie du umformulieren kannst, meist indem du einen konkreten Anbieter, Endpoint oder eine Dokumentations-URL nennst. Wenn dein Request zu einer eingebauten Funktion wie Human Handoff passt, verweist er dich auf diese Funktion, statt eine benutzerdefinierte Action zu erstellen.

Was passiert, wenn der API-Aufruf während einer Konversation fehlschlägt?

Der Agent sieht den Fehler und teilt dem Nutzer mit, dass er die Abfrage nicht abschließen konnte, statt eine Antwort zu erfinden. Jeder Aufruf wird in der Inbox an der Konversation mit seinen Parametern und dem HTTP-Statuscode aufgezeichnet, sodass du genau sehen kannst, was gesendet wurde und was zurückkam.

Können ChatGPT, Claude oder Gemini sich so mit einer API verbinden?

Ihre Modelle unterstützen alle Function Calling, aber die Verdrahtung ist Entwicklungsarbeit: Du schreibst das Function Schema oder die OpenAPI-Spezifikation selbst, wie bei benutzerdefinierten GPT Actions. Hier tippst du einen Satz, und die Action wird aus der Live-Dokumentation der API generiert und läuft dann auf allen Kanälen deines Agent. Du kannst deinen fertigen Quickchat Agent auch für ChatGPT, Claude und Cursor als MCP-Server bereitstellen.

Aus welchen Kanälen kann der Agent die API aufrufen?

Aus allen. Actions gehören zum Agent, nicht zu einem Kanal. Deshalb wird dieselbe Action aus dem Website-Widget, WhatsApp, Messenger, Slack, Telegram, Discord und überall sonst ausgelöst, wo dein Agent bereitgestellt ist.

Ist der Action Builder in einfacher Sprache kostenlos?

Ja. Das Generieren, Prüfen und Aktivieren von API Actions funktioniert im kostenlosen Plan, und beide Actions in diesem Leitfaden wurden mit einem kostenlosen Konto erstellt. Bezahlte Pläne fügen höhere Nutzungslimits und fortgeschrittenere Modelle hinzu, nicht den Zugriff auf den Builder.

Wie wählt der Agent zwischen mehreren Actions?

Er liest den Namen und die Beschreibung jeder Action und wählt diejenige, die zum Moment in der Konversation passt. Der Demo-Agent hat zwei: Eine Wetterfrage wird zur Forecast-Action geleitet, eine Astronomiefrage zur NASA-Action, weil ihre Beschreibungen diese Auslöser nennen. Klare, unterschiedliche Beschreibungen machen die Auswahl zuverlässig.

Wie viel Latenz fügt ein API-Aufruf einer Antwort hinzu?

Weniger, als du vielleicht erwartest. Der echte Forecast-Aufruf in diesem Leitfaden kehrte in 280 ms zurück, innerhalb einer Antwort, die insgesamt etwa zwei Sekunden dauerte. Der Besucher sieht einen kurzen Denk-Indikator, den du durch eine benutzerdefinierte Thinking message ersetzen kannst, und danach eine Antwort auf Basis von Live-Daten.

Zusammenfassung

Aus zwei getippten Sätzen wurden zwei live laufende, dokumentierte und geprüfte API Actions: eine Wetterabfrage ohne Schlüssel und eine NASA-Abfrage mit Schlüssel, jeweils belegt durch einen HTTP 200, der in der Inbox neben den vom Modell gefüllten Werten aufgezeichnet wurde. Die Regeln, die das zuverlässig machen, passen in drei Zeilen. Nenne eine echte API, und der Builder stützt die Action auf ihre Dokumentation und zitiert sie. Alles, was nur du kennst, kommt als [[secret]], das die Aktivierung blockiert, bis du es füllst. Alles, was der Builder nicht bestätigen kann, wird zu einer Erklärung und einem Vorschlag zur Umformulierung, nie zu einer Vermutung.

Halte beim Bauen für die vollständige Feldliste von API Actions, Run Conditions und Response Handling die AI Actions docs bereit.