Webhooks vs. Tool Calling von Agenten: Was ist der Unterschied?

Tool Calling von Agenten ist ein Pull, bei dem eine KI entscheidet, eine Funktion aufzurufen; ein Webhook ist ein Push, wenn ein externes Ereignis eintritt. Verglichen werden die beiden, weil am Ende beide bei Ihrem Backend landen – aber sie laufen in entgegengesetzte Richtungen, und sie zu verwechseln erzeugt sowohl schlechte Architektur als auch schlechte Sicherheit. Der ganze Unterschied passt in eine Zeile: Ein Webhook ist die Welt → Ihr System (Push, vom Ereignis ausgelöst, deterministisch); ein Tool Call ist Ihre KI → die Welt (Pull, vom Modell ausgelöst, probabilistisch).

Das Wichtigste in Kürze

Die zwei Richtungen

Dasselbe Backend, aus beiden Richtungen erreicht – einmal geprüft, einmal eingeschränkt:

// JavaScript — Cloud Code: the same backend, reached two ways

// INBOUND — a webhook: the world tells your system something happened.
// Deterministic. You VERIFY the sender before trusting it.
Parse.Cloud.define('paymentWebhook', async (req) => {
  verifyHmac(req.params, process.env.WEBHOOK_SECRET); // trust, then act
  await markPaid(req.params.orderId);
  return { received: true };
});

// OUTBOUND — an agent tool: your AI decides to do something.
// Probabilistic. You CONSTRAIN what it may do (runs under the user's ACLs).
Parse.Cloud.define('refundOrder', async (req) => {
  const asUser = { sessionToken: req.user.getSessionToken() };
  const order = await new Parse.Query('Order').get(req.params.orderId, asUser);
  order.set('status', 'refunded');
  await order.save(null, asUser); // ACLs decide if this agent-driven call is allowed
  return { refunded: order.id };
});

// Flutter / Dart — Back4app Flutter SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'refund my last order'});
print(result.result);
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.

// iOS / Swift — Back4app Swift SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
let result: [String: Any] = try await Cloud.run(
    name: "runAgent", parameters: ["goal": "refund my last order"])
print(result)
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.

// Android / Kotlin — Back4app Android SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
val result = ParseCloud.callFunction<Map<String, Any>>(
    "runAgent", mapOf("goal" to "refund my last order"))
println(result)
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.

Was Tool Calling tatsächlich ist

Da der Webhook-Eintrag die Webhook-Seite abdeckt, trägt dieser Artikel die andere Hälfte. Tool Calling ist die Art, wie ein KI-Agent handelt: Sie liefern in der Anfrage Tool-Definitionen mit – einen Namen, eine Beschreibung, ein typisiertes JSON-Schema; das Modell schlussfolgert über den Gesprächsverlauf und gibt statt einer Prosa-Antwort einen strukturierten Aufruf aus, der ein Tool und dessen Argumente benennt; Ihr Code führt ihn aus und gibt das Ergebnis für den nächsten Denkschritt zurück. Der Punkt, den alle betonen (Fowlers Durchgang ist die klare Referenz): Das Modell führt die Funktion nie aus – es entscheidet nur, sie anzufordern, gesteuert von den Tool-Beschreibungen, weshalb diese Beschreibungen echte Sorgfalt verdienen. “Function Calling” (der ältere Begriff) und “Tool Calling” (der weiter gefasste) meinen praktisch denselben Mechanismus.

Determinismus: die Achse, die Ihre Bauweise verändert

Der Unterschied, der Ihr Testen umorganisiert – und den keine Vergleichsseite klar ausspricht. Ein Webhook ist deterministisch: Ereignis X löst denselben Callback mit einem vorhersehbaren Payload aus, Sie testen den Handler also im Unit-Test gegen eine feste Eingabe und prüfen eine Ausgabe. Ein Tool Call ist probabilistisch: Dasselbe Nutzerziel löst ein bestimmtes Tool vielleicht aus und vielleicht nicht und übergibt bei jedem Lauf womöglich andere Argumente – Sie bewerten einen Agenten deshalb statistisch, über viele Durchläufe, indem Sie messen, wie oft er das Richtige tut, denn es gibt keine einzelne korrekte Ausgabe zum Prüfen. Deshalb ist eine Webhook-Integration “fertig”, wenn die Tests grün sind, und eine Agenten-Integration “fertig”, wenn die Erfolgsquote eine von Ihnen gewählte Schwelle überschreitet. Push gegen Pull ist der einprägsame Unterschied; deterministisch gegen probabilistisch ist der folgenreiche.

Sicherheit: Webhooks vs. Tool Calls – Eingehendes prüfen, Ausgehendes einschränken

Die Richtungen diktieren entgegengesetzte Abwehrmaßnahmen, und sie zu vertauschen ist das eigentliche Risiko.

Prüfen Sie, was hereinkommt; schränken Sie ein, was hinausgeht. Ein Webhook-Handler ohne Signaturprüfung ist ein unauthentifizierter Schreib-Endpoint; ein Agenten-Tool mit zu weit gefassten Zugangsdaten ist ein Confused-Deputy-Vorfall, der auf eine Prompt Injection wartet. Beide scheitern auf dieselbe Weise – ein Aufruf, dem Ihr System vertraut hat, obwohl es das nicht hätte tun sollen – nur aus entgegengesetzten Richtungen.

Sie ergänzen sich

Das sind keine Rivalen, sondern Stufen einer Schleife. Ein eingehender Webhook weckt einen Agenten (ein Support-Ticket trifft ein, eine Zahlung geht durch), der Agent handelt über Tool Calls, und einer dieser Tool Calls löst einen ausgehenden Webhook zu einem weiteren System aus. Das saubere Denkmodell für Backend-Entwickler: Beide erreichen am Ende Ihre API und Ihre Funktionen – die einzigen Unterschiede sind, wer den Auslöser gedrückt hat (ein externes Ereignis oder das Modell) und ob der Aufruf deterministisch war. Entwerfen Sie den Endpoint einmal; sichern Sie ihn dann so ab, wie es die Richtung verlangt, aus der er erreichbar ist.

Typische Anwendungsfälle

• Reaktion auf Ereignisse – Zahlung eingegangen, Code gepusht, Formular abgeschickt: ein Webhook, geprüft.
• Autonomes Handeln – ein Agent, der ein Ziel über eng gefasste Tools erreicht: Tool Calling, eingeschränkt.
• Vom Ereignis geweckte Agenten – ein Webhook als Eingang, der eine Agent Loop startet: beides, kombiniert.
• Wiederverwendbare Tool-Oberflächen – viele Agenten teilen sich einen Satz Tools: standardisiert mit MCP.
• Deterministische geplante Arbeit – ein von Ihnen gesteuerter Abruf nach Zeitplan: ein schlichter API-Aufruf, weder Webhook noch Tool.

Welches brauchen Sie? Entscheidungsmatrix

Grenzen und Trade-offs

• Der Vergleich verdeckt einen gemeinsamen Endpoint. Beide erreichen dieselbe Backend-Funktion; das zu vergessen führt zu zwei Sicherheitsmodellen, wo Sie eine bewachte Tür mit zwei Schlössern gebraucht hätten.
• Probabilistische Aufrufe entziehen sich Garantien. Sie können nicht zusichern, dass ein Agent ein Tool aufruft, so wie Sie zusichern können, dass ein Ereignis einen Webhook auslöst – planen Sie damit, dass das Modell nicht handelt und dass es falsch handelt.
• Prüfen und Einschränken sind nicht austauschbar. Die Signatur eines Tool Calls zu prüfen oder einen Webhook mit Berechtigungen zu begrenzen löst die falsche Bedrohung für die jeweilige Richtung – passen Sie die Abwehr der Richtung an.
• Kombination erzeugt zusätzliche Fehlerfälle. Ein Webhook, der einen Agenten weckt, der Tools aufruft, die Webhooks auslösen, ist mächtig und hat vier Bruchstellen; Korrelations-IDs und Idempotenz über die ganze Kette sind nicht optional.
• “Es hat meine API getroffen” sagt nichts über Vertrauen aus. Derselbe Aufruf ist von einem geprüften Ereignis harmlos und von einem manipulierten Modell gefährlich – verteidigt wird die Herkunft, nicht die Form der Anfrage.

Beide Richtungen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beide Richtungen landen auf demselben Baustein – einer Cloud-Code-Funktion –, und genau deshalb fallen die beiden Abwehrmaßnahmen auf dieser Plattform natürlich aus, wie die Code-Tabs zeigen. Auf der eingehenden Seite ist eine Funktion ein Webhook-Empfänger: HMAC gegen ein serverseitiges Geheimnis prüfen, dann handeln. Auf der ausgehenden Seite ist dieselbe Funktion ein Agenten-Tool: Sie läuft unter der Session des aufrufenden Benutzers, sodass ACLs und Klassenberechtigungen einschränken, was ein modellgesteuerter Aufruf anfassen darf, und ein gekaperter Agent nicht über die Rechte des Benutzers hinauskommt. Prüfen, was hereingepusht wird, einschränken, was der Agent herausholt – ein Backend, ein Ort für beide Kontrollen, mit MCP zur Standardisierung der Tool-Oberfläche, sobald sich die Agenten vermehren.