// stack · schnittstelle
Die OpenAI API ist eine Schnittstelle zu Sprachmodellen: Dein Server schickt eine Anfrage, das Modell antwortet. Für siteway ist das der Weg, wenn auf einer Website etwas erzeugt, zusammengefasst, klassifiziert oder beantwortet werden soll. Diese Seite beschreibt die Technik dahinter — und die eine Regel, an der solche Anbindungen am häufigsten scheitern: Der Schlüssel bleibt auf dem Server.
// definition
dienst · anfrage statt installation
Die OpenAI API ist eine Programmierschnittstelle zu Sprachmodellen. Du installierst kein Modell und betreibst keinen Rechner dafür. Deine Anwendung schickt eine Anfrage als JSON über HTTPS, das Modell verarbeitet sie und antwortet. Authentifiziert wird mit einem API-Schlüssel, der als Bearer-Token in der Authorization-Kopfzeile mitgeht; zusätzliche Kopfzeilen geben an, welcher Organisation und welchem Projekt die Nutzung zugerechnet wird.
Diese Seite betrachtet die Schnittstelle aus einer bestimmten Richtung: als Funktion auf deiner Website, die deine Besucher benutzen. Wie siteway selbst mit KI-Werkzeugen entwickelt — also unsere eigene Arbeitsweise —, steht auf einer eigenen Seite: KI-gestützte Entwicklung. Zwei Themen, zwei Blickrichtungen, derselbe Grundstoff.
Was die Schnittstelle interessant macht, sind nicht nur erzeugte Texte. Sie liefert auch Embeddings — Text als Vektor, damit sich inhaltlich Ähnliches finden lässt — und strukturierte Ausgaben, bei denen die Antwort einem vorgegebenen Schema folgt statt Fließtext zu sein. Beides steht im Kapitel Technik im Detail. Die buchbaren Leistungen dazu heißen KI & Automation und KI-Chatbots.
// praxis
erzeugen · zusammenfassen · klassifizieren · beantworten
Am Anfang steht keine Technikentscheidung, sondern eine Aufgabe. Vier Grundformen decken das meiste ab, was auf einer Website sinnvoll ist. Erzeugen: aus Stichpunkten wird ein Entwurf, aus einem Datensatz ein Beschreibungstext, aus einem Artikel ein Vorschlag für Titel und Teaser. Zusammenfassen: ein langes Dokument wird auf das Wesentliche gekürzt. Klassifizieren: eine eingehende Anfrage bekommt Kategorie, Priorität und Zuständigkeit. Beantworten: eine Frage wird auf Grundlage hinterlegter Inhalte beantwortet.
Die Reihenfolge ist uns dabei wichtig: Erst der Anwendungsfall, dann die Frage, ob ein Sprachmodell dafür der richtige Weg ist. Vieles, was nach KI aussieht, ist in Wahrheit eine gute Suche, ein Filter oder ein sauber gebautes Formular — schneller, günstiger und mit immer demselben Ergebnis. Wo das reicht, bauen wir das.
Wo ein Modell gebraucht wird, entscheidet als Nächstes die Frage, woher die Antwort kommt. Ein Sprachmodell für sich genommen kennt deine Preisliste nicht, deine Lieferzeiten nicht und deine Handbücher nicht. Damit ein Assistent auf Basis deiner Inhalte antwortet, werden diese Inhalte vorher in Embeddings übersetzt und abgelegt; zur Laufzeit werden die inhaltlich passenden Passagen herausgesucht und zusammen mit der Frage an das Modell gegeben. Das ist der Unterschied zwischen einer Antwort mit Beleg und einer Antwort mit Behauptung.
Zwei Betriebsarten unterscheiden wir außerdem. Im Hintergrund: Ein Text wird beim Speichern eines Datensatzes erzeugt, redaktionell geprüft und dann veröffentlicht — der Besucher sieht nur das Ergebnis, das Modell steht nicht im Antwortweg der Seite. Im Dialog: Der Besucher fragt, die Antwort entsteht in dem Moment. Der zweite Fall ist der aufwendigere, weil Wartezeit, Ausfall und Missbrauch mitgeplant werden müssen.
Und wie bei jeder externen Schnittstelle planen wir den Fehlerfall mit: Antwortet der Dienst nicht oder zu langsam, bleibt die Seite bedienbar und zeigt einen ehrlichen Hinweis samt Weg zum Menschen — statt eines Ladekreisels ohne Ende. Die Anbindung selbst gehört zur Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation der Plattform — Begriffe und Mechanik im Original. Modellnamen mit Versionsständen und Preise lassen wir bewusst weg: Beides ändert sich schneller, als eine Agenturseite gepflegt wird. Was für dein Projekt gilt, steht in deinem Konto und in deinem Vertrag.
// d-01zugang
Eine Anfrage ist ein JSON-Dokument über HTTPS; die Antwort kommt ebenso zurück. Authentifiziert wird mit einem API-Schlüssel als Bearer-Token im Authorization-Header. Zusätzliche Kopfzeilen für Organisation und Projekt legen fest, wem die Nutzung zugerechnet wird — praktisch, um mehrere Websites im selben Konto sauber zu trennen.
zweck: wer fragt, auf wessen konto
// d-02einheit
Token sind die Recheneinheit: Text wird in Token zerlegt, und daran hängen sowohl die Länge einer Anfrage als auch die Abrechnung. Die Nutzungsgrenzen werden entsprechend gemessen — unter anderem in Anfragen je Minute und Token je Minute; welche Grenze zuerst greift, entscheidet. Wer zu viel auf einmal schickt, bekommt eine Absage statt einer Antwort.
zweck: länge, kosten, drosselung
// d-03ausgabe
Statt auf die fertige Antwort zu warten, lässt sich die Ausgabe als Server-Sent Events stückweise ausliefern — die Antwort erscheint, während sie entsteht. Für einen Dialog auf der Website ist das der Unterschied zwischen gefühlter Wartezeit und keiner. Die Dokumentation nennt auch den Preis dafür: Teilausgaben sind schwerer zu prüfen als eine vollständige Antwort.
zweck: antwort während der entstehung
// d-04embeddings
Text wird in einen Vektor übersetzt — eine Liste von Zahlen. Der Abstand zweier Vektoren misst laut Dokumentation, wie verwandt die Texte sind: kleiner Abstand, hohe Verwandtschaft. Als Abstandsmaß wird die Kosinus-Ähnlichkeit empfohlen. Genannte Einsatzgebiete sind unter anderem Suche, Gruppierung, Empfehlungen und Klassifikation.
zweck: ähnliches finden
// d-05schema
Die Antwort muss kein Fließtext sein. Mit einem vorgegebenen JSON-Schema liefert das Modell ein festes Datenformat zurück, an das es sich hält — die Dokumentation stellt das ausdrücklich einem reinen JSON-Modus gegenüber, der nur gültiges JSON garantiert, aber keine bestimmte Form. Schemata dürfen verschachtelte Objekte, Listen und Aufzählungen enthalten.
zweck: antwort maschinell nutzbar
// d-06funktionsaufrufe
Die Schwesterform der strukturierten Ausgabe: Statt selbst zu antworten, meldet das Modell, welche Funktion deiner Anwendung mit welchen Werten aufgerufen werden soll. Die Dokumentation zieht die Trennlinie klar — Funktionsaufrufe für die Verbindung zu Systemen und Daten, ein Ausgabeformat für die Antwort an den Nutzer. Ausgeführt wird ausschließlich, was dein Code freigibt.
zweck: brücke zu deinen daten
Ein Sprachmodell erzeugt eine plausible Antwort, keine geprüfte. Es kann eine Zahl nennen, die es so nicht gibt, und eine falsche Aussage so flüssig formulieren wie eine richtige. Wer das auf einer Unternehmenswebsite einsetzt, muss diesen Punkt vorher auf den Tisch legen — nicht nach der ersten Beschwerde.
Unsere Linie ist deshalb einfach: Wo es verbindlich wird, kommt die Antwort aus der Datenquelle. Preise, Verfügbarkeiten, Fristen, Termine, rechtlich relevante Auskünfte — dafür fragt die Anwendung das System, das die Wahrheit hält, und das Modell darf höchstens formulieren, was von dort kommt. Wo es um Erklärungen, Vorschläge und Entwürfe geht, ist ein Modell gut aufgehoben.
Dazu kommen drei Handgriffe, die im Alltag den Unterschied machen: Antworten aus eigenen Inhalten bekommen einen Quellenverweis, damit sich jede Aussage nachschlagen lässt. Es bleibt erkennbar, dass eine Maschine antwortet. Und es gibt immer einen Weg zum Menschen — über Formular oder Kontakt.
// integration
drei systeme · ein muster
Eine Sache entscheidet über alles Weitere, und sie steht deshalb hier zuerst: Der API-Schlüssel gehört ausschließlich auf den Server. Die Website spricht nicht direkt mit dem Dienst, sondern mit einem eigenen Endpunkt auf deiner eigenen Domain. Der nimmt die Anfrage entgegen, prüft sie, begrenzt sie und reicht sie erst dann weiter — der Schlüssel bleibt dahinter. Ohne diese Schicht steht er im Quelltext oder im JavaScript-Bundle, und dort liest ihn jeder Besucher aus: Fremde Anfragen laufen dann auf deine Rechnung, bis jemand die Abrechnung liest. Die Dokumentation sagt dasselbe in einem Satz — den Schlüssel nicht teilen, nicht in clientseitigem Code offenlegen, sondern serverseitig aus einer Umgebungsvariablen oder einem Schlüsseldienst laden.
Dieser Endpunkt ist zugleich die Stelle für Missbrauchsschutz und Kostenkontrolle. Vier Begrenzungen bauen wir standardmäßig ein: eine Obergrenze, wie viele Anfragen ein Besucher in einem Zeitraum stellen darf, eine Höchstlänge für die Eingabe, ein Zeitlimit je Anfrage und eine Obergrenze für die Länge der Antwort. Dazu kommt, was auf der Ebene des Kontos möglich ist — Nutzungsgrenzen und ein eigener Projektschlüssel je Website, damit sich Verbrauch zuordnen lässt. Und darüber liegt eine Protokollierung, die sichtbar macht, wenn der Verbrauch aus der Reihe läuft, bevor es die Rechnung tut. Was das CMS darunter unterscheidet, ist nur, wo Route, Konfiguration und Template jeweils hingehören.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Den Endpunkt legen wir als Middleware oder als Controller-Route an — er nimmt die Anfrage der Seite entgegen, prüft Herkunft und Länge, zieht die Begrenzung je Besucher und spricht erst dann mit dem Dienst. Der Schlüssel liegt in der Extension-Konfiguration oder als Umgebungsvariable und wird nie an ein Template gereicht. Ausgegeben wird in Fluid, sodass Eingabefeld, Antwortbereich und Ladezustand im Design der Website stehen. Wo Inhalte als Grundlage dienen, läuft die Berechnung der Embeddings als Scheduler-Task über den Bestand.
// 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, die Rechte und Herkunft prüft, Länge und Häufigkeit begrenzt und dann weiterreicht. 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 Template-Dateien und ein Block für den Editor dazu. Erzeugte Texte legen wir als Entwurf an, damit die Redaktion vor der Veröffentlichung darüber schaut.
// cms-03statamic
Unter Statamic liegt Laravel, und das macht den Aufbau geradlinig. Eine Route plus Controller bildet den Endpunkt; Begrenzung je Besucher, Zeitlimit und Längenprüfung hängen als Middleware davor. Der Schlüssel liegt in der .env und wird über die Konfiguration gelesen, nie im gerenderten Frontend. Antlers oder Blade rendern Eingabe, Antwort und Fehlerfall. Längere Aufgaben — etwa das Berechnen der Embeddings über alle Entries — laufen als Artisan-Command in der Warteschlange, statt die Anfrage des Besuchers warten zu lassen.
// datenschutz
sachlich · keine rechtsberatung
Der Kern ist in einem Satz gesagt: Was in eine Anfrage geht, verlässt deinen Server. Der Text eines Besuchers, der Auszug aus deinem Handbuch, der Inhalt eines Formularfelds — alles, was du mitschickst, wird bei einem Dritten verarbeitet. Das ist kein Ausschlussgrund, aber es entscheidet darüber, wie eine Funktion geschnitten wird.
Daraus folgt als erste Regel Datensparsamkeit: In die Anfrage geht der Ausschnitt, der für die Aufgabe gebraucht wird — und personenbezogene Daten nur dann, wenn es ohne sie nicht geht. Sehr oft geht es ohne: Eine Anfrage lässt sich klassifizieren, ohne dass Name, Adresse und Telefonnummer mitreisen. Wo etwas dranbleiben muss, prüfen wir, ob es sich vorher entfernen oder ersetzen lässt.
Vertraglich gehören drei Punkte vor den Start geklärt: die Auftragsverarbeitung mit dem Anbieter, der Verarbeitungsort und die Frage, was gespeichert wird. OpenAI dokumentiert dazu, dass über die API gesendete Daten standardmäßig nicht zum Training der Modelle verwendet werden, dass Protokolle zur Missbrauchserkennung in der Regel bis zu 30 Tage aufbewahrt werden und dass es Vertragsoptionen sowohl für den Verarbeitungsort als auch für den Verzicht auf diese Speicherung gibt. Welche davon für dein Konto gelten, steht in deinem Vertrag — und nicht auf einer Agenturseite.
Dazu kommt die Seite, die deine Besucher sehen: Wer mit einer KI-Funktion spricht, sollte das wissen, und es sollte in der Datenschutzerklärung wiederzufinden sein. Wie wir das mit dem Rest der Auslieferung zusammenbringen, steht im Stack unter Sicherheit & Datenschutz; wenn eine bestehende Seite systematisch durchgesehen werden soll, ist das ein Datenschutz-Audit. Eine Rechtsberatung ist das ausdrücklich nicht.
// faq
Die OpenAI API ist eine Programmierschnittstelle zu Sprachmodellen. Dein Server schickt eine Anfrage als JSON über HTTPS und bekommt eine Antwort zurück — Text, oder auf Wunsch ein Datenformat, das du vorher festgelegt hast. Authentifiziert wird mit einem API-Schlüssel, der als Bearer-Token im Authorization-Header mitgeht; über zusätzliche Kopfzeilen lässt sich angeben, welcher Organisation und welchem Projekt die Nutzung zugerechnet wird. Für eine Website heißt das: Das Modell ist keine Software, die du installierst, sondern ein Dienst, den deine Anwendung im laufenden Betrieb befragt. Es rechnet nichts vor, es hält nichts vor — es antwortet auf genau das, was in der Anfrage steht.
Vier Grundformen decken das meiste ab. Erzeugen: aus Stichpunkten wird ein Entwurf, aus einem Datensatz ein Beschreibungstext, aus einem Artikel ein Vorschlag für Titel und Teaser. Zusammenfassen: ein langes Dokument wird auf das Wesentliche gekürzt. Klassifizieren: eine eingehende Anfrage bekommt eine Kategorie, eine Priorität, eine Zuständigkeit. Beantworten: eine Frage wird auf Grundlage hinterlegter Inhalte beantwortet. Wichtig ist die Reihenfolge: Zuerst steht der Anwendungsfall, dann die Frage, ob ein Sprachmodell dafür der richtige Weg ist. Vieles, was nach KI aussieht, ist eine Suche, ein Filter oder ein sauber gebautes Formular — und dann bauen wir das, weil es schneller ist, weniger kostet und immer dasselbe Ergebnis liefert.
Nein, das sind zwei verschiedene Themen, die nur denselben Grundstoff teilen. KI-gestützte Entwicklung beschreibt unsere eigene Arbeitsweise: wie wir mit KI-Werkzeugen Code schreiben, prüfen und ausliefern. Diese Seite handelt vom Gegenteil der Blickrichtung — von einer Funktion, die auf deiner Website läuft und die deine Besucher benutzen. Das eine ist unser Werkzeugkasten, das andere ist dein Feature. Die buchbaren Leistungen dazu heißen KI & Automation sowie KI-Chatbots; diese Seite erklärt die Schnittstelle und ihre Technik darunter.
Ein Embedding ist die Übersetzung von Text in einen Vektor — eine Liste von Zahlen. Die Dokumentation beschreibt den Zweck nüchtern: Der Abstand zwischen zwei Vektoren misst, wie verwandt die beiden Texte sind; kleiner Abstand bedeutet hohe Verwandtschaft. Als Abstandsmaß empfiehlt die Dokumentation die Kosinus-Ähnlichkeit, und sie nennt als Einsatzgebiete unter anderem Suche, Gruppierung, Empfehlungen und Klassifikation. Für eine Website ist das der entscheidende Baustein: Wir übersetzen deine Inhalte einmal in Vektoren und legen sie ab. Kommt eine Frage, wird auch sie zum Vektor, und wir holen die inhaltlich nächstliegenden Passagen heraus. Erst diese Passagen gehen zusammen mit der Frage an das Modell. Damit antwortet der Assistent auf Grundlage deiner Inhalte, statt aus dem allgemeinen Sprachwissen zu schöpfen — und du kannst mitliefern, aus welchem Dokument die Antwort stammt.
Weil alles, was der Browser lädt, auch lesbar ist. Ein Schlüssel in JavaScript, in einem Datenattribut oder in einer Konfigurationsdatei des Frontends steht damit jedem Besucher zur Verfügung — und jede Anfrage, die jemand damit stellt, läuft auf deine Rechnung. Die Dokumentation ist an dieser Stelle unmissverständlich und sagt, den Schlüssel nicht zu teilen und nicht in clientseitigem Code offenzulegen, sondern ihn auf dem Server aus einer Umgebungsvariablen oder einem Schlüsseldienst zu laden. Der Missbrauchsschutz gehört in dieselbe Schicht: eine Begrenzung, wie viele Anfragen ein Besucher in einem Zeitraum stellen darf, eine Höchstlänge für die Eingabe, ein Zeitlimit je Anfrage und eine Obergrenze für die Länge der Antwort. Dazu kommt die Kostenkontrolle über die Nutzungsgrenzen im Konto und eine Protokollierung, die sichtbar macht, wenn der Verbrauch aus der Reihe läuft.
Ja. Ein Sprachmodell erzeugt eine plausible Antwort, keine geprüfte. Es kann eine Zahl nennen, die es so nicht gibt, oder eine Aussage flüssig formulieren, die nicht stimmt. Das ist kein Argument gegen den Einsatz, aber ein Argument für eine bestimmte Bauweise. Wir ziehen deshalb eine Linie: Wo es um Preise, Verfügbarkeiten, Fristen, Termine oder rechtlich verbindliche Auskünfte geht, kommt die Antwort aus der Datenquelle und nicht aus dem Modell — das Modell darf höchstens formulieren, was die Quelle liefert. Wo es um Erklärungen, Vorschläge und Entwürfe geht, ist ein Modell gut aufgehoben, solange erkennbar bleibt, dass eine Maschine antwortet, und solange ein Weg zum Menschen offen bleibt. Antworten aus eigenen Inhalten belegen wir zusätzlich mit einem Verweis auf die Quelle, damit sich jede Aussage nachschlagen lässt.
Der Kern ist schnell gesagt: Was in eine Anfrage geht, verlässt deinen Server. Daraus folgt Datensparsamkeit als erste Regel — in die Anfrage geht der Ausschnitt, der für die Aufgabe gebraucht wird, und personenbezogene Daten nur dann, wenn es ohne sie nicht geht. Zu klären sind vor dem Start die Auftragsverarbeitung mit dem Anbieter, der Verarbeitungsort und die Frage, was gespeichert wird. OpenAI dokumentiert dazu, dass über die API gesendete Daten standardmäßig nicht zum Training der Modelle verwendet werden, dass Protokolle zur Missbrauchserkennung in der Regel bis zu 30 Tage aufbewahrt werden und dass es Vertragsoptionen für den Verarbeitungsort und für den Verzicht auf diese Speicherung gibt — welche davon für dein Konto gelten, steht in deinem Vertrag und nicht auf einer Agenturseite. Dazu kommt die Transparenz gegenüber deinen Besuchern: Wer mit einer KI-Funktion spricht, sollte das wissen und es in der Datenschutzerklärung wiederfinden. 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: ein eigener Endpunkt auf deinem Server, der die Anfrage annimmt, prüft, begrenzt und erst dann weiterreicht; der Schlüssel liegt dahinter und nie im Browser. In TYPO3 entsteht dafür eine eigene Extension mit einer Middleware oder einer Controller-Route als Endpunkt, dem Schlüssel in der Extension-Konfiguration oder einer Umgebungsvariablen und der Ausgabe in 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, die Ausgabe in Antlers oder Blade. Was sich unterscheidet, ist nur, wo Route, Konfiguration und Template jeweils hingehören.
// womit das zusammenhängt
technik, alternativen & leistung
// stack · schnittstelle
Dieselbe Aufgabe bei einem anderen Anbieter: Sprachmodell als Dienst, Anfrage über den eigenen Server. Welcher passt, entscheidet der Anwendungsfall.
zur technik →
// stack · betriebsform
Dieselbe Aufgabe, andere Betriebsform: Modelle, die auf eigener oder gemieteter Infrastruktur laufen — für Fälle, in denen Anfragen das Haus nicht verlassen sollen.
zur technik →
// stack · arbeitsweise
Die andere Blickrichtung: wie wir selbst mit KI-Werkzeugen arbeiten — Code schreiben, prüfen, ausliefern. Nicht das Feature auf deiner Website, sondern unser Werkzeugkasten.
zur arbeitsweise →
// stack · grundlage
Wenn Anfragen zu einem externen Dienst gehen: Schlüssel serverseitig, Datensparsamkeit, Auftragsverarbeitung, Verarbeitungsort.
zur technik →
// leistung · buchbar
Der Assistent auf deiner Website: Antworten aus deinen Inhalten, Übergabe an den Menschen, Auswertung der Fragen. Hier wird gebucht.
zur leistung →
// leistung · abläufe
Wenn ein Modell in einem Ablauf steckt statt in einem Chatfenster: einordnen, weiterleiten, vorbereiten — und der Mensch entscheidet am Ende.
zur leistung →
// Eine KI-Funktion, die auf deine Inhalte antwortet?
Projekt anfragen