API-Dokumentation und Integrationsanleitungen für meinGPT
Willkommen im meinGPT Entwicklerhandbuch. Mit der meinGPT API kannst Du sicher und einfach eigene Anwendungen
mit KI bauen, ohne dass Du zusätzliche Accounts und Services benötigst. Außerdem stehen viele der leistungsstarken
Features aus der Plattform wie Assistenten und Workflows auch in der API zur Verfügung.
Nicht jedes Plattform-Feature ist über die API erreichbar. Der Übersetzer (Text- und Dateiübersetzung über Google Cloud Translate bzw. DeepL, auch mit eigenem DeepL-Schlüssel via BYOK) ist ausschließlich über die Plattform-Oberfläche nutzbar - es gibt weder einen eigenen Übersetzungs-Endpunkt noch lässt er sich als Tool über Completions, Assistenten oder Workflows auslösen. Siehe Übersetzer.
Für die meinGPT API gilt kein Limit für die Anzahl gleichzeitiger (paralleler) Streaming-Requests. Stattdessen wird ein Tokenbudget pro Minute geprüft, das drei Ebenen gleichzeitig berücksichtigt:
Pro Nutzer: Standardmäßig 125.000 Tokens/Minute
Pro Organisation: Standardmäßig 250.000 Tokens/Minute (wird von allen Nutzern der Organisation gemeinsam genutzt)
Pro Modell (plattformweit): Standardmäßig 500.000 Tokens/Minute pro Modell – dieses Budget teilen sich alle meinGPT-Organisationen, die dasselbe Modell nutzen. Bei stark nachgefragten Modellen (z. B. Claude Opus, Claude Sonnet) kann dieses plattformweite Limit auch dann greifen, wenn Dein eigener Nutzer- und Organisationsverbrauch noch innerhalb Deines Kontingents liegt.
Alle Limits laufen über ein gleitendes 60-Sekunden-Fenster und zählen Input- und Output-Tokens zusammen. Im message-Feld einer 429-Antwort steht, welche Ebene überschritten wurde (user, organization oder global). Ein individuell höheres Limit für eine Organisation kann aktuell nicht selbstständig konfiguriert werden — meldet euch bei uns, um eine Anpassung zu besprechen.
Zusätzlich zum Tokenbudget gibt es eine grobkörnige IP-basierte Flood-Protection von aktuell ca. 1.000 Anfragen/Minute pro IP-Adresse, die unabhängig vom Tokenbudget greift. Für normale Nutzung ist sie nicht relevant, kann aber bei sehr vielen kurzen, parallelen Anfragen (z. B. Benchmark- oder Agenten-Workloads mit vielen kleinen Turns) zusätzlich zum Tokenlimit zuschlagen.
Requests oberhalb des Limits werden nicht in eine Warteschlange gestellt, sondern sofort mit einem 429-Fehler abgelehnt. Die Antwort enthält einen Retry-After-Header (aktuell ein fester Wert von 60 Sekunden) sowie Header mit Informationen zu Limit, verbleibendem Budget und Reset-Zeitpunkt für das Tokenbudget.
Wenn eine Anfrage nicht bearbeitet werden kann, liefert die API einen HTTP-Statuscode ungleich 2xx zurück. Gängige Codes:
400 – Ungültige Anfrage (z. B. nicht unterstützter Parameterwert, fehlerhafte Eingabe)
401 – Ungültiger oder fehlender API-Schlüssel
403 – Modell oder Completions-API nicht für die Organisation freigeschaltet
429 – Rate-Limit erreicht (siehe Rate Limits oben) – mit Backoff erneut versuchen oder zu einem anderen Modell wechseln
500 – Vorübergehender Fehler beim KI-Anbieter – nach kurzer Wartezeit erneut versuchen
Ein 200-Status garantiert keinen verwertbaren content. Wird die Modellausgabe durch die Content-Filterung blockiert, antwortet die API weiterhin mit 200 OK, aber choices[0].message.content ist null oder leer und choices[0].finish_reason lautet "content_filter" (in diesem Fall ohne tool_calls). Prüfe deshalb immer zusätzlich zum HTTP-Statuscode auch finish_reason, bevor Du eine Antwort als erfolgreich behandelst, und behandle content_filter getrennt von einem wiederholbaren Fehler — ein unveränderter Retry der Anfrage ändert das Ergebnis nicht.
Bei stream: true werden die Antworten als Server-Sent Events (text/event-stream) mit object: "chat.completion.chunk"-Events gesendet. Jeder Chunk enthält choices[0].delta.content für inkrementellen Text (bzw. choices[0].delta.tool_calls für Tool-Calls), wobei choices[0].finish_reason bis zum letzten Chunk null ist. Der letzte Chunk hat ein leeres delta und ein gesetztes choices[0].finish_reason — "stop", "length", "tool_calls" oder "content_filter" — gefolgt von einem abschließenden data: [DONE]-Event. Prüfe wie bei nicht-gestreamten Antworten auch hier finish_reason auf "content_filter", bevor Du den Stream als vollständig erfolgreich behandelst.
Fehlerantworten enthalten immer einen JSON-Body, allerdings in meinGPTs eigenem Format — {"status": "error", "message": "..."} — statt in OpenAIs {"error": {"message": ..., "type": ..., "code": ...}}-Umschlag. OpenAI-SDK-basierte Tools, die das OpenAI-Format erwarten, können unseren Body deshalb nicht parsen und zeigen ihn als leeren bzw. „no body“-Fehler an, obwohl ein Body gesendet wurde. Prüfe deshalb immer zuerst den HTTP-Statuscode statt Dich auf das geparste Fehlerobjekt zu verlassen — ein 200-Status allein garantiert jedoch keinen gültigen content (siehe oben) — und implementiere Retries mit exponentiellem Backoff für 429- und 500-Antworten. Beachte bei 429-Antworten insbesondere den Retry-After-Header, bevor Du Backoff anwendest — er gibt bereits das exakt verbleibende Zeitfenster an (siehe Rate Limits oben).