OpenAI API ohne Code integrieren: Xano + WeWeb Guide

Warum du OpenAI nie direkt vom Frontend aufrufen solltest

Der erste Fehler, den die meisten No-Code-Entwickler machen: OpenAI API direkt von WeWeb oder FlutterFlow aufrufen, mit dem API-Key im Client exponiert.

Tue das niemals. Der API-Key ist in den Browser-Dev-Tools sichtbar, und jeder, der ihn findet, kann tausende Euro an API-Aufrufen auf deine Kosten generieren. OpenAI API-Keys haben standardmäßig keine Ratenbegrenzung.

Richtiges Muster: alle OpenAI-Aufrufe gehen über dein Backend (Supabase Edge Function, Xano-Endpunkt oder beliebiger Server). Das Frontend ruft dein Backend auf, das OpenAI mit dem als serverseitige Umgebungsvariable gespeicherten Key aufruft. Das fügt eine Indirektionsschicht hinzu und schützt deinen Key vollständig. In Deutschland ist auch die DSGVO relevant, deine Edge Function kann in der EU gehostet werden, um sicherzustellen, dass keine Nutzerdaten Europa verlassen.

Supabase Edge Functions für OpenAI konfigurieren

Supabase Edge Functions sind Deno-basierte serverlose Funktionen, die im Edge-Netzwerk laufen. Sie sind der einfachste Weg, OpenAI-Aufrufe zu proxyen.

Die grundlegende Struktur: Nachrichten und System-Prompt vom WeWeb-Frontend empfangen, OpenAI Chat Completions API mit deinem in Deno.env gespeicherten Key aufrufen und die Antwort zurückgeben. Deploye mit supabase functions deploy ai-chat und setze den Key mit supabase secrets set OPENAI_API_KEY=sk-....

Wähle bei der Projekterstellung die Supabase EU-West-Region. Das stellt sicher, dass alle Edge Function-Ausführungen und Datenspeicherungen innerhalb der EU stattfinden, eine DSGVO-Anforderung für die meisten deutschen B2B-Kunden und eine formale Anforderung, wenn deine Kundendaten unter DSGVO-Artikel 9 als besonders schützenswert eingestuft werden.

OpenAI-Kostenoptimierung: Caching und Batching

In der Produktion können OpenAI-API-Kosten schnell wachsen, wenn sie nicht kontrolliert werden. Die zwei wirksamsten Strategien zur Kostensenkung, noch bevor man an die Modellwahl geht, sind Caching und Batching. Caching bedeutet, den Output eines API-Aufrufs zu speichern und das gecachte Ergebnis zurückzugeben, wenn derselbe Input erneut angefragt wird. Erstelle eine Tabelle ai_response_cache in Supabase mit Spalten für einen Hash des vollständigen Prompts, den Antworttext, das verwendete Modell und einen created_at-Zeitstempel. Prüfe vor jedem API-Aufruf, ob für diesen Hash bereits eine gecachte Antwort existiert. Cache-Trefferquoten von 20 bis 40 % sind bei Funktionen zur Inhaltsgenerierung üblich, bei denen Nutzer oft ähnliche Outputs generieren.

Batching kommt zum Einsatz, wenn du viele KI-Operationen ausführen musst, die nicht in Echtzeit nutzerseitig sichtbar sein müssen, zum Beispiel Zusammenfassungen für 500 über Nacht hochgeladene Dokumente generieren oder Sentiment-Analyse für die Support-Tickets von gestern durchführen. OpenAIs Batch API verarbeitet asynchron zu 50 % des Standardpreises. Reiche deine Anfragen als JSONL-Datei ein, frage den Status ab und hole die Ergebnisse ab. Für Hintergrundjobs sollte Batching immer deine Standardwahl sein.

Eine dritte Technik: Setze aggressive max_tokens-Limits. Wenn eine Funktion nur einen 150-Wörter-Output benötigt, stellt max_tokens: 200 sicher, dass du niemals für 2.000-Token-Antworten bezahlst, die durch Prompt-Drift entstehen. Überwache die durchschnittliche Token-Nutzung pro Endpoint zwei Wochen nach dem Launch und reduziere die Limits auf das 95. Perzentil dessen, was du tatsächlich beobachtest.

GPT-4o vs. GPT-4 Turbo: das richtige Modell wählen

Nicht jede Funktion braucht das leistungsfähigste Modell. Die richtige Modellwahl für jeden Anwendungsfall kann deine API-Rechnung um 60 bis 80 % senken, ohne dass Nutzer einen Qualitätsunterschied bemerken. GPT-4o ist das aktuelle Flaggschiff, multimodal (Bilder, Audio, Text), schnell und kosteneffizient bei 2,50 USD/M Input-Tokens. Es ist die richtige Wahl für nutzerseitigen Chat, komplexes Reasoning und Aufgaben, bei denen die Ausgabequalität für den Nutzer direkt sichtbar ist.

GPT-4o mini läuft bei 0,15 USD/M Input-Tokens, etwa 17-mal günstiger. Es bewältigt einfache Klassifizierung, kurze Inhaltsgenerierung, FAQ-Beantwortung und Formular-Vorausfüllung mit einer Qualität, die die meisten Nutzer nicht von GPT-4o unterscheiden können. Starte für jede Funktion mit einer klar definierten, einfachen Aufgabe mit GPT-4o mini und wechsle nur zu GPT-4o, wenn Qualitätstests einen spürbaren Unterschied zeigen.

Verwende für Embeddings und semantische Suche text-embedding-3-small (0,02 USD/M Tokens). Es ist schnell, günstig und liefert für die meisten Dokumentenabruf-Aufgaben vergleichbare Ergebnisse wie größere Embedding-Modelle. Reserviere text-embedding-3-large für Suchfunktionen, bei denen Präzision entscheidend ist und das Abfragevolumen gering ist. Die Faustregel: Starte günstig, benchmarke die Qualität und aktualisiere das Modell nur, wenn du die Verbesserung bei den Nutzerergebnissen messen kannst.

Edge Function von WeWeb aufrufen

In WeWeb erstelle eine REST-API-Datenquelle, die auf deine Edge Function-URL zeigt (zu finden im Supabase-Dashboard unter Edge Functions). Konfiguriere sie als POST-Anfrage mit einem JSON-Body.

Erstelle eine Variable chatMessages (Array) und aiResponse (String). Beim Klick auf einen Button: 1. Nutzernachricht zu chatMessages hinzufügen 2. userInput leeren 3. Edge Function-Aktion mit messages: chatMessages aufrufen 4. aiResponse an den Antworttext binden 5. aiResponse in einem Textelement anzeigen

Für gestreamte Antworten (Text, der Wort für Wort erscheint), verwende den stream: true-Parameter im OpenAI-Aufruf und verarbeite den SSE-Stream in der Edge Function. Das ist komplexer, schafft aber eine viel bessere Nutzererfahrung, wichtig für deutsche B2B-Apps, bei denen professionelle Nutzer schnelle Reaktionszeiten erwarten.

Streaming-Antworten in No-Code-Apps

Streaming ist die Technik, durch die ChatGPT Text Wort für Wort anzeigt, während er generiert wird, statt auf die vollständige Antwort zu warten. Das verbessert die gefühlte Performance dramatisch, Nutzer sehen Output in unter einer Sekunde, statt 3 bis 8 Sekunden auf die vollständige Antwort zu warten. Streaming in einem No-Code-Stack zu implementieren erfordert eine kleine Menge Custom Code, ist aber mit Supabase Edge Functions und WeWebs benutzerdefinierten JavaScript-Aktionen umsetzbar.

Füge in der Edge Function stream: true zur OpenAI-Anfrage hinzu und leite den Antwort-Body zurück an den Client. Die Edge Function gibt einen Server-Sent-Events-Stream (SSE) zurück, eine Reihe von Text-Chunks, jeweils mit data: vorangestellt. Verarbeite das in WeWeb mit einer benutzerdefinierten JavaScript-Aktion, die eine EventSource-Verbindung öffnet, auf data-Events lauscht und jeden Chunk an eine reaktive Variable anhängt, die an dein Ausgabe-Textelement gebunden ist.

In FlutterFlow wird Streaming über eine in Dart geschriebene Custom Action gehandhabt, die das http-Paket verwendet, um die Antwort als Stream zu lesen und den App-State schrittweise zu aktualisieren. Die Implementierung dauert 2 bis 4 Stunden, ist aber für jede Chatbot- oder Inhaltsgenerierungsfunktion die Investition wert, die UX-Verbesserung ist erheblich, und Nutzer bevorzugen sie durchweg.

Rate Limiting und Retry-Logik

OpenAIs API gibt HTTP-429-Fehler (Too Many Requests) zurück, wenn du deine Ratenlimits überschreitest. Ohne Retry-Logik erscheinen diese als Fehler bei deinen Nutzern. Eine ordentliche Behandlung von Ratenlimits ist für produktive KI-Funktionen nicht verhandelbar.

Implementiere in deiner Supabase Edge Function exponentielles Backoff: Bei einer 429-Antwort 1 Sekunde warten und erneut versuchen; schlägt es wieder fehl, 2 Sekunden warten; dann 4 Sekunden; danach mit einer nutzerfreundlichen Fehlermeldung abbrechen. Die meisten 429-Fehler sind vorübergehend und lösen sich beim ersten oder zweiten Retry.

Implementiere für nutzerbezogenes Rate Limiting, das verhindert, dass ein einzelner Nutzer ein unverhältnismäßiges API-Budget verbraucht, einen Anfragezähler pro Nutzer in Supabase. Jeder API-Aufruf erhöht einen Zähler in einer usage_tracking-Tabelle. Prüfe den Zähler zu Beginn jeder Anfrage und gib eine 429 mit einer klaren Meldung zurück, wenn der Nutzer sein tägliches oder monatliches Limit überschritten hat. Das schützt dein API-Budget und liefert die Daten, die du für nutzungsbasierte Abrechnung brauchst. Logge Modell, verwendete Tokens, Latenz und Erfolg/Misserfolg für jede Anfrage, diese Daten werden bei der Fehlersuche bei Kostenspitzen und der Prompt-Optimierung unverzichtbar.

Prompt Engineering für Produktfeatures

Die Qualität deiner KI-Funktion hängt vollständig von deinem System-Prompt ab. Generische Prompts liefern generische Ergebnisse.

Für einen Inhaltsgenerator: "Du bist ein Texter für [Firmenname], ein [Beschreibung] SaaS. Generiere [Output-Typ], der dieser Markenstimme entspricht: [Beispiele]. Antworte immer in diesem Format: [Struktur]. Erwähne niemals [Ausschlüsse]."

Für einen Datenanalysten: "Du bist ein Experten-Datenanalyst. Analysiere die bereitgestellten Daten und gib Erkenntnisse zurück als: 1) Eine-Satz-Zusammenfassung, 2) Drei Kernbefunde als Aufzählungspunkte, 3) Eine empfohlene Aktion. Antworte immer in gültigem JSON."

Praktische Regeln: Sei spezifisch über das Ausgabeformat (JSON, wenn das Frontend parsen muss), füge negative Einschränkungen ein ("erwähne niemals Wettbewerber"), und teste mit 20+ Inputs vor dem Launch. Für deutsche Apps: spezifiziere, dass die KI auf Deutsch antworten soll, sofern nicht anders angegeben.

Kostenkontrolle und Ratenbegrenzung

OpenAI API-Kosten steigen in der Produktion schnell. Drei Kontrollen, die vor dem Launch implementiert werden sollten:

1. Token-Limits: Setze max_tokens für jede Anfrage. Für die meisten Funktionen reichen 500 Tokens. GPT-4o kostet 2,50 USD/M Input-Tokens + 10 USD/M Output-Tokens, ein 500-Token-Limit hält die Kosten unter 0,005 USD pro Anfrage.

2. Benutzer-Ratenbegrenzung: In deiner Edge Function prüfe, wie viele Aufrufe der Nutzer in der letzten Stunde gemacht hat (in Supabase gespeichert). Gib 429 zurück, wenn das Limit überschritten wird.

3. Caching: Für deterministische Outputs (gleicher Input → gleicher Output) cache die Antworten in Supabase. Eine ai_cache-Tabelle mit einem Hash des Prompts als Key eliminiert redundante API-Aufrufe.

Für eine SaaS-App mit 500 MAU, die jeweils 20 KI-Anfragen pro Tag stellen: budgetiere 150-300 € pro Monat für GPT-4o.

Häufige No-Code-KI-Funktionen, die wir bauen

KI-Inhaltsgenerierung: Blogartikel, Produktbeschreibungen, E-Mail-Betreffzeilen. WeWeb-Formular → Edge Function → GPT-4o → Output anzeigen. Für den deutschen Markt: automatisch Produktbeschreibungen auf Deutsch für Zalando-Händler generieren.

Intelligente Suche: Nutzerinhalte mit OpenAI text-embedding-3-small einbetten, Vektoren in pgvector (Supabase) speichern und Ähnlichkeitssuche ausführen. Gibt semantisch relevante Ergebnisse statt Keyword-Matches zurück.

Dokumentenzusammenfassung: PDF hochladen → Text via Edge Function extrahieren → mit GPT-4o zusammenfassen → Zusammenfassung in Supabase speichern.

KI-gesteuertes Onboarding: Beim Signup 5 Fragen stellen, mit GPT-4o eine personalisierte Setup-Checkliste generieren, im Benutzerprofil speichern.

All das läuft auf dem WeWeb + Supabase + OpenAI-Stack ohne benutzerdefinierten Frontend-Code.