// stack · schnittstelle
Die Claude-API von Anthropic ist eine Schnittstelle zu Sprachmodellen — Anfrage rein, Text zurück. Auf dieser Seite geht es um genau eine Verwendung davon: das Modell als Funktion auf deiner Website, für Besucher oder für die Redaktion. siteway baut diese Anbindung selbst — mit dem Schlüssel auf dem Server und den eigenen Inhalten als Grundlage der Antwort.
// definition
schnittstelle · kein fertiges produkt
Anthropic ist das Unternehmen hinter den Claude-Modellen, die Claude-API ist die Schnittstelle dazu. Technisch ist das unspektakulär: eine REST-Schnittstelle, an die deine Anwendung eine Anfrage als JSON schickt und von der sie die Antwort ebenfalls als JSON zurückbekommt. Eine Anfrage besteht im Kern aus einer Abfolge von Nachrichten mit Rollen, einer Systemanweisung, die Rolle und Grenzen setzt, und einer Obergrenze für die Länge der Antwort.
Was das Modell damit kann, ist ebenfalls überschaubar beschreibbar: Text zusammenfassen, einordnen, beantworten, umformulieren. Das ist keine Zauberei und auch keine Datenbank — es ist eine Funktion, die Text hineinbekommt und Text herausgibt. Alles, was danach nach Intelligenz aussieht, entsteht daraus, welchen Text man hineingibt und was mit dem Ergebnis passiert.
Eine Abgrenzung gleich vorweg, weil sie oft verwechselt wird: Wie wir intern mit KI-Werkzeugen arbeiten — beim Schreiben von Code, bei Tests, im Review — steht unter KI-gestützte Entwicklung. Diese Seite beschreibt etwas anderes: die API als Funktion auf der Website unserer Kunden, die Besucher oder Redaktion tatsächlich benutzen.
// praxis
für besucher · für die redaktion
Nicht jede Website braucht ein Sprachmodell. Die Fälle, in denen es sich lohnt, haben eine Gemeinsamkeit: Es gibt viel Text, und jemand muss ihn durchsuchen, verkürzen, einsortieren oder in eine Antwort verwandeln — heute von Hand. Vier Zuschnitte begegnen uns dabei immer wieder.
// f-01für besucher
Ein Eingabefeld, in das jemand eine Frage in eigenen Worten tippt — und eine Antwort, die aus deinen Seiten, Datenblättern oder Hilfetexten stammt. Der spannende Teil ist nicht das Modell, sondern der Schritt davor: die richtigen Ausschnitte finden und mitgeben. Ohne den antwortet der Assistent flüssig und falsch.
braucht: suchindex + kontext
// f-02für besucher
Ein langer Fachartikel, ein Protokoll, ein Datenblatt mit dreißig Zeilen Technik: Das Modell verdichtet auf drei Sätze, die vorne stehen. Der Text liegt vor, das Ergebnis lässt sich zwischenspeichern statt bei jedem Aufruf neu zu erzeugen — das spart Wartezeit und Kosten gleichermaßen.
braucht: zwischenspeicher
// f-03für die redaktion
Der unterschätzte Fall — weil er nach innen wirkt und nicht ins Frontend muss. Titelvorschläge, Kurzbeschreibung, Alternativtext für ein Bild, eine Meta-Description als Entwurf. Vorgeschlagen wird, entschieden wird von der Redaktion; nichts geht ungeprüft live.
braucht: freigabe durch menschen
// f-04im hintergrund
Eine Nachricht aus dem Kontaktformular bekommt eine Kategorie, eine Dringlichkeit und damit den richtigen Empfänger. Hier zählt nicht Sprachgefühl, sondern eine kurze, klar begrenzte Antwort aus einer festen Liste — und ein definierter Rückfallwert, wenn die Zuordnung unklar bleibt.
braucht: feste kategorien
Das ist der Satz, an dem sich entscheidet, ob eine KI-Funktion auf einer Website taugt oder blamiert. Ein Sprachmodell kennt deine Preise, Öffnungszeiten, Produktdaten und Ansprechpartner nicht. Es kennt Sprache. Fragt jemand nach der Lieferzeit deines Sonderanfertigungs-Bauteils, erzeugt es einen Satz, der klingt wie eine Antwort — und geraten ist.
Die Lösung ist nicht mehr Modell, sondern mehr Kontext: Zu jeder Frage werden erst die passenden Ausschnitte aus den eigenen Inhalten gesucht und der Anfrage beigelegt. Das Modell formuliert dann aus dem, was vor ihm liegt. Damit verschiebt sich die eigentliche Arbeit an eine Stelle, die viele nicht erwarten — sie liegt vor dem Modell, nicht darin.
Dafür braucht es zwei Bausteine, die auf einer gut gebauten Website ohnehin vorhanden sein sollten. Erstens einen Suchindex, der zu einer Frage die passenden Abschnitte findet, statt die halbe Website mitzuschicken — das ist derselbe Index, der auch die normale Suche bedient. Zweitens strukturierte Daten und saubere Felder im CMS: Wo Preis, Datum, Zuständigkeit und Status als eigene Felder gepflegt sind, lässt sich ein Ausschnitt sauber schneiden — und eine verbindliche Angabe direkt aus der Quelle beantworten, ohne das Modell dazwischen.
Daraus folgt eine unbequeme, aber nützliche Reihenfolge: Erst die Inhalte ordnen, dann das Modell anschließen. Wer es umgekehrt versucht, baut einen sehr eloquenten Ratekandidaten. Die buchbaren Leistungen darüber sind KI-Chatbots und KI & Automation; die Anbindung selbst gehört zur Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Anthropic — Begriffe, Kopfzeilen und Abläufe im Original. Modellnamen mit Versionsständen und Preise lassen wir bewusst weg: Beides ändert sich schneller als eine Agenturseite, und was für dein Projekt gilt, steht in deinem Vertrag.
// d-01format
Eine REST-Schnittstelle: Anfrage als JSON hin, Antwort als JSON zurück. Die Anfrage trägt eine Abfolge von Nachrichten mit Rollen, optional eine Systemanweisung und eine Obergrenze für die Antwortlänge. Die Antwort kommt in Blöcken und nennt den Grund, aus dem sie endete. Anthropic stellt für mehrere Sprachen eigene SDKs bereit.
zweck: austauschformat
// d-02zugang
Jede Anfrage trägt den API-Schlüssel in einer Kopfzeile, dazu eine Angabe zur API-Version und den Inhaltstyp. Schlüssel werden in der Console erzeugt und bekommen dabei ein Ablaufdatum; über Workspaces lassen sie sich nach Anwendungsfall trennen und Ausgaben getrennt steuern. Für uns heißt das: ein eigener Schlüssel je Anwendung.
zweck: wer darf fragen
// d-03ausgabe
Wird Streaming in der Anfrage gesetzt, kommt die Antwort nicht am Stück, sondern als Folge von Ereignissen über Server-Sent Events: Start, viele kleine Textstücke, Ende. Für eine Website ist das kein Detail, sondern der Unterschied zwischen einer Sekunde Stille und Text, der sofort zu laufen beginnt.
zweck: gefühlte geschwindigkeit
// d-04einheit
Text wird vor der Verarbeitung in Token zerlegt — die Einheit, in der Länge gemessen und abgerechnet wird, für Eingabe wie Ausgabe. Die Antwort meldet den Verbrauch zurück, und es gibt einen eigenen Endpunkt, um Token vorab zu zählen. Wer Kosten steuern will, steuert hier: kürzerer Kontext, begrenzte Antwortlänge.
zweck: länge und kosten
// d-05grenzen
Dokumentiert sind Grenzen für Anfragen und Token pro Minute sowie Ausgabenlimits je Stufe, einsehbar im Konto. Wird eine Grenze erreicht oder ist der Dienst überlastet, antwortet die Schnittstelle mit einem Fehler statt mit Text. Jede Antwort trägt eine Anfrage-Kennung, die im Supportfall den Vorgang eindeutig macht.
zweck: was bei last passiert
// d-06werkzeuge
Statt zu raten, kann das Modell einen Aufruf anfordern, den dein Server ausführt — eine Abfrage im Katalog, ein Blick in den Kalender. Das Ergebnis geht zurück, die Antwort wird darauf gebaut. Genau so kommen verbindliche Angaben aus der Datenquelle und nicht aus dem Sprachgefühl.
zweck: fakten statt formulierung
Modelle können falsch liegen. Das ist keine Randnotiz, sondern eine Eigenschaft: Erzeugt wird plausibler Text, und plausibel ist nicht dasselbe wie richtig. Wer eine KI-Funktion auf eine Website stellt, muss deshalb vorher entscheiden, was passiert, wenn die Antwort daneben liegt — und nicht hoffen, dass es nicht vorkommt.
Unsere Regel dafür ist einfach: Was verbindlich ist, kommt aus der Datenquelle. Preise, Termine, Verfügbarkeiten, Fristen, rechtliche Aussagen — diese Angaben holt der Server aus dem System, in dem sie gepflegt werden, und das Modell darf höchstens den Satz drumherum formulieren. Wo das nicht geht, gehört eine Prüfung dazwischen: durch einen Menschen, oder durch eine Regel, die eine Antwort ohne Beleg gar nicht erst ausspielt und stattdessen weiterleitet.
Dazu kommt Ehrlichkeit an der Oberfläche: ein sichtbarer Hinweis, dass hier ein Assistent antwortet, Quellenangaben mit Link auf die Seite, aus der die Antwort stammt, und ein sichtbarer Weg zu einem Menschen. Das kostet zwei Zeilen Text und rettet die Glaubwürdigkeit der gesamten Funktion.
// integration
drei systeme · ein muster
Es gibt eine Stelle, an der solche Anbindungen scheitern, und sie steht deshalb ganz vorne: Der API-Schlüssel gehört ausschließlich auf den Server. Die Website spricht nie direkt mit dem Anbieter. Zwischen Browser und Schnittstelle liegt ein eigener Endpunkt auf deiner Domain, der die Anfrage entgegennimmt, prüft, begrenzt, die passenden Inhalte dazulegt, den Schlüssel setzt und erst dann weiterreicht. Ohne diese Schicht kann jeder Besucher den Schlüssel aus dem Quelltext oder dem Netzwerkverkehr auslesen und auf fremde Rechnung Anfragen stellen — und es fällt erst auf, wenn die Abrechnung kommt.
Derselbe Endpunkt trägt den Missbrauchsschutz: eine Begrenzung der Anfragen je Besucher und Zeitfenster, eine Obergrenze für die Länge der Eingabe, ein Zeitlimit für die Antwort, damit eine hängende Verbindung nicht die Seite blockiert — und je nach Anwendungsfall eine Prüfung, ob die Anfrage überhaupt von deiner Website kommt. Dazu kommt die Kostenkontrolle, die technisch dieselben Hebel benutzt: begrenzte Antwortlänge, ein Kontext aus wenigen passenden Ausschnitten statt der halben Website, Zwischenspeicher für wiederkehrende Antworten und ein Alarm, wenn der Verbrauch aus dem Rahmen läuft. Was das jeweilige CMS unterscheidet, ist nur, wo Route, Konfiguration und Schlüssel hingehören.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Der Endpunkt entsteht als Middleware oder als eigene Controller-Route, die die Anfrage des Besuchers annimmt, gegen die Begrenzungen prüft und die passenden Inhalte aus Seiten und Records dazulegt. Der Schlüssel liegt in der Extension-Konfiguration oder als Umgebungsvariable und wird nie in ein Template gereicht. Fluid rendert das Eingabefeld und die Ausgabe, sodass die Funktion im Design der Website steht. Mehrsprachigkeit läuft über die Sprachhandhabung des Systems, damit die Antwort in der Sprache der Seite bleibt.
// cms-02wordpress
Die Anbindung entsteht als eigenes Plugin und nicht als Theme-Code — so überlebt sie einen Theme-Wechsel. Der Endpunkt ist eine eigene REST-Route mit Rechteprüfung, Begrenzung je Besucher und Zeitlimit; Redaktionsfunktionen hängen an einer Route, die nur angemeldeten Rollen offensteht. Der Schlüssel steht als Konstante in der wp-config.php oder als Umgebungsvariable, nicht in der Datenbank und nicht im Frontend-Skript. Für die Oberfläche kommen ein Block für den Editor und Template-Dateien dazu, damit die Redaktion die Funktion selbst platzieren kann.
// cms-03statamic
Unter Statamic liegt Laravel, und das macht diesen Fall geradlinig. Der Endpunkt ist eine Route plus Controller; die Begrenzung je Besucher, die Prüfung der Eingabe und das Zeitlimit sind dort Bordmittel und keine Eigenbauten. Die passenden Ausschnitte kommen aus den Collections, der Blueprint gibt vor, welche Felder überhaupt in den Kontext dürfen. Der Schlüssel liegt in der .env und bleibt dort. Antlers oder Blade rendern Eingabefeld und Ausgabe, längere Läufe wandern in eine Queue statt in die Wartezeit des Besuchers.
// datenschutz
datensparsamkeit · keine rechtsberatung
Der Kern ist ein einziger Satz: Was in die Anfrage geht, verlässt deinen Server. Das gilt für den Text, den ein Besucher tippt, genauso wie für die Ausschnitte aus deinen Inhalten, die der Endpunkt dazulegt. Beides ist kein Ausschlussgrund — aber beides gehört vor dem Start auf den Tisch und nicht nachträglich in die Datenschutzerklärung.
Daraus folgt Datensparsamkeit als Bauprinzip. In den Kontext geht, was für die Antwort gebraucht wird — nicht der ganze Datensatz, weil er ohnehin da war. Personenbezogene Daten gehören nur hinein, wenn es ohne sie nicht geht; wo eine Kennung nötig ist, nehmen wir eine technische statt einer Kundennummer. Und Inhalte hinter einer Anmeldung landen nur dann im Kontext, wenn der Endpunkt vorher geprüft hat, dass die anfragende Person sie auch sehen darf.
Drei Punkte klären wir dafür im Projekt. Erstens die Auftragsverarbeitung mit dem Anbieter — wer im Auftrag verarbeitet, braucht einen Vertrag darüber, genau wie der Hoster. Zweitens das Protokollieren: Eingaben werden nur mit einem benannten Zweck gespeichert, mit Löschfrist, und sie sind nicht dafür da, später zum Nachlesen von Kundengesprächen zu dienen. Drittens die Aufklärung an der Oberfläche: eine Hinweiszeile am Eingabefeld, weil Menschen sonst Dinge hineinschreiben, die dort nichts verloren haben.
Wie das mit dem Rest der Auslieferung zusammenpasst, steht im Stack unter Sicherheit & Datenschutz. Wenn die Bestandsaufnahme für die gesamte Website ansteht, ist das Datenschutz-Audit der passende Rahmen. Eine Rechtsberatung ist beides ausdrücklich nicht — wir ordnen technisch ein, die rechtliche Bewertung gehört zu deiner Beratung.
// faq
Anthropic ist das Unternehmen hinter den Claude-Modellen, die Claude-API ist die Schnittstelle dazu. Technisch ist sie eine REST-Schnittstelle: Deine Anwendung schickt eine Anfrage als JSON an einen Endpunkt, die Antwort kommt ebenfalls als JSON zurück. Eine Anfrage besteht im Kern aus einer Abfolge von Nachrichten mit Rollen, einer Systemanweisung, die Rolle und Grenzen setzt, und einer Obergrenze für die Länge der Antwort. Anthropic stellt dafür eigene SDKs für mehrere Programmiersprachen bereit, die Kopfzeilen, Wiederholversuche und Streaming übernehmen. Für eine Website heißt das: Die API ist kein fertiges Produkt, sondern ein Baustein, um den herum die eigentliche Funktion erst gebaut wird.
Für vier Dinge, die in der Praxis immer wiederkehren: einen Assistenten, der Fragen auf Basis der eigenen Inhalte beantwortet; Zusammenfassungen langer Texte, Dokumente oder Datenblätter; Vorschläge für die Redaktion im Backend, etwa Titel, Kurzbeschreibung oder Alternativtext; und die Klassifikation eingehender Anfragen, damit ein Formular im richtigen Postfach landet. Gemeinsam ist allen vieren, dass das Modell mit Text arbeitet, den es bekommt — nicht mit Wissen, das es angeblich schon hat. Die buchbaren Leistungen dahinter sind KI-Chatbots und KI & Automation; diese Seite beschreibt die Schnittstelle darunter.
Gar nicht — und das ist der wichtigste Punkt auf dieser Seite. Ein Sprachmodell kennt deine Preise, Öffnungszeiten, Produktdaten und Ansprechpartner nicht. Damit eine Antwort stimmt, müssen die passenden Ausschnitte aus deinen eigenen Inhalten mit der Anfrage mitgeschickt werden. Der Weg dahin führt über zwei Bausteine, die ohnehin gebraucht werden: einen Suchindex, der zu einer Frage die passenden Abschnitte findet, und saubere Strukturen im CMS, aus denen sich diese Abschnitte überhaupt schneiden lassen. Das Modell formuliert dann aus dem, was es bekommen hat. Ohne diesen Unterbau bekommst du flüssige Sätze ohne Deckung — und genau daran scheitern die schnellen Versuche.
Ausschließlich auf den Server. Die Website spricht nie direkt mit dem Anbieter, sondern mit einem eigenen Endpunkt auf deiner Domain; erst dieser Endpunkt setzt den Schlüssel in die Kopfzeile der Anfrage und reicht sie weiter. Läge der Schlüssel im Frontend, könnte ihn jeder Besucher aus dem Quelltext oder aus dem Netzwerkverkehr lesen und auf deine Rechnung Anfragen stellen. Anthropic dokumentiert dazu, dass Schlüssel in der Console erzeugt werden, dabei ein Ablaufdatum bekommen und sich über Workspaces nach Anwendungsfall trennen lassen. Im Projekt liegt der Schlüssel in der Umgebungskonfiguration und nie im Quelltext-Repository.
Abgerechnet wird nach Token — der Einheit, in die Text vor der Verarbeitung zerlegt wird, für die Eingabe wie für die Ausgabe. Daraus folgen die Stellschrauben: eine Obergrenze für die Antwortlänge, ein Kontext, der nur die wirklich passenden Ausschnitte enthält statt der halben Website, und eine Begrenzung der Anfragen je Besucher und Zeitfenster. Anthropic stellt zum Schätzen einen eigenen Endpunkt zum Zählen von Token bereit und dokumentiert Ausgabenlimits sowie Grenzen für Anfragen und Token pro Minute, die sich im Konto einsehen lassen. Konkrete Preise nennen wir hier bewusst nicht — sie ändern sich, und was für dein Projekt gilt, steht in deinem Vertrag.
Ehrliche Antwort: nicht verlässlich genug für Auskünfte, die verbindlich sein müssen. Ein Sprachmodell erzeugt plausiblen Text, und plausibel ist nicht dasselbe wie richtig. Für Preise, Termine, Verfügbarkeiten und rechtliche Aussagen bauen wir deshalb keinen Formulierungsautomaten, sondern holen die Angabe aus der Datenquelle und lassen das Modell höchstens den Satz drumherum bauen. Wo das nicht geht, gehört eine Prüfung dazwischen — durch einen Menschen oder durch eine Regel, die eine Antwort ohne Beleg gar nicht erst ausspielt. Dazu kommt ein sichtbarer Hinweis, dass hier ein Assistent antwortet, und ein Weg zu einem Menschen.
Der Kern ist schnell gesagt: Was in die Anfrage geht, verlässt deinen Server. Daraus folgt Datensparsamkeit — in den Kontext gehört, was für die Antwort gebraucht wird, und personenbezogene Daten gehören nur hinein, wenn es ohne sie nicht geht. Vor dem Start klären wir außerdem die Auftragsverarbeitung mit dem Anbieter, die Frage, welche Eingaben überhaupt protokolliert werden und zu welchem Zweck, und die Löschfristen dafür. Wenn Besucher frei tippen können, kommt eine Hinweiszeile ans Eingabefeld, weil Menschen dort sonst Dinge hineinschreiben, die niemand verarbeiten möchte. Wie wir das im Projekt einordnen, steht im Stack unter Sicherheit & Datenschutz. Eine Rechtsberatung ist das ausdrücklich nicht.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst mit den Bordmitteln des Systems. Der Aufbau ist überall derselbe: Eine eigene Route auf deiner Domain nimmt die Anfrage des Besuchers entgegen, prüft und begrenzt sie, holt die passenden Inhalte dazu, setzt den Schlüssel und spricht mit dem Anbieter. In TYPO3 entsteht dafür eine eigene Extension mit einer Middleware oder einer Controller-Route, der Schlüssel liegt in der Extension-Konfiguration oder in einer Umgebungsvariablen, das Frontend rendert Fluid. In WordPress bauen wir ein eigenes Plugin statt Theme-Code, mit einer eigenen REST-Route und dem Schlüssel als Konstante in der wp-config.php oder als Umgebungsvariable. In Statamic liegt Laravel darunter: eine Route plus Controller, der Schlüssel in der .env, Antlers oder Blade fürs Frontend.
// womit das zusammenhängt
technik, alternativen & leistung
// stack · alternative
Dieselbe Aufgabe über einen anderen Anbieter. Der Aufbau der Anbindung bleibt gleich: eigener Endpunkt, Schlüssel am Server, eigene Inhalte als Kontext.
zur technik →
// stack · alternative
Andere Betriebsform: Modelle auf eigener Infrastruktur, wenn Eingaben und Inhalte das Haus nicht verlassen sollen und der Betrieb mitgeplant wird.
zur technik →
// stack · grundlage
Der Unterbau jeder Antwort aus eigenen Inhalten: der Index, der zu einer Frage die passenden Abschnitte findet, bevor das Modell überhaupt formuliert.
zur technik →
// stack · arbeitsweise
Die andere Seite des Themas: wie wir intern mit KI-Werkzeugen arbeiten — beim Code, bei Tests, im Review. Nicht auf deiner Website, sondern in unserer.
zur arbeitsweise →
// leistung · buchbar
Die fertige Komponente für deine Website: Assistent auf Basis eigener Inhalte, Übergabe an einen Menschen, Oberfläche im Design der Seite. Hier wird gebucht.
zur leistung →
// leistung · anbindung
Die Disziplin dahinter: eigener Endpunkt, Schlüsselverwaltung, Begrenzungen, Fehlerfälle und Protokollierung — bei jeder Anbindung dieselben Fragen.
zur leistung →
// Eine KI-Funktion, die aus deinen Inhalten antwortet?
Projekt anfragen