API-Schlüssel

Premium-Funktion

BasePeak.AI verwendet Bearer-Tokens mit eingeschränktem Geltungsbereich für den programmatischen Zugriff. Ein Token ist an die Person gebunden, die es erstellt hat, führt eine ausdrückliche Liste von Scopes und kann nie mehr tun, als dieses Konto im Moment der Ausstellung selbst durfte.

Einen Schlüssel erstellen

Die Oberfläche finden Sie unter Profil → API-Schlüssel.

Klicken Sie auf API-Schlüssel erstellen.
Füllen Sie aus:
- Name – ein kurzes Label, das in der Liste erscheint. Pflichtfeld.
- Beschreibung – optionaler Freitext.
- Ablauf – optional. Ohne Ablaufdatum gilt der Schlüssel bis zum Widerruf.
- Geltungsbereiche – mindestens einer. Über Geltungsbereich hinzufügen wählen Sie die Art des Zugriffs und – wo sinnvoll – den Agenten, die Anmeldedaten oder „Beliebiger Agent“ bzw. „Beliebige Anmeldedaten“.
Kopieren Sie das Token. Es wird genau einmal angezeigt – gespeichert wird nur ein Hash. Ein verlorenes Token kann daher nicht wiederhergestellt, sondern nur ersetzt werden.

Welche Scopes der Dialog anbietet

Der Dialog bietet die Scopes an, die Ihr Konto voraussichtlich ausstellen darf: Chat- und credential:use:-Scopes immer, die Datei- und Unterhaltungs-Scopes für jeden Agenten, für den Sie freigeschaltet sind (agent:files-write zusätzlich nur, wenn Sie selbst die Berechtigung agent:update besitzen), und einen Management-Scope nur, wenn Sie die zugehörige Berechtigung selbst besitzen. Management-Scopes gelten immer für alle Objekte ihres Typs – einzige Ausnahme ist agent:update, das auf einen Agenten festgelegt werden kann. Die endgültige Prüfung übernimmt in jedem Fall der Server beim Anlegen; schlägt sie fehl, nennt die Fehlermeldung den Grund.

Für die Chat- sowie die Datei- und Unterhaltungs-Scopes bietet die Agentenauswahl die Agenten an, für die der Schlüssel ausgestellt werden kann – einschließlich derer, die Sie nur über eine Gruppenfreigabe oder ein eigenes Projekt erreichen. Nicht aufgeführt werden System-Agenten und Freigaben auf gelöschte Agenten; beides ließe sich zwar ausstellen, ergibt als Ziel eines Schlüssels aber keinen Sinn. Für agent:update gilt eine andere Regel: Diese Berechtigung ist an keinen bestimmten Agenten gebunden, daher listet die Agentenauswahl dort alle Agenten der Instanz.

API-Zugriff ist eine Premium-Funktion

Der programmatische API-Zugriff ist eine Premium-Funktion. Das Anlegen eines Schlüssels scheitert mit 403 (API access is disabled for this instance), wenn das Merkmal apiAccess deaktiviert ist; auch bestehende Schlüssel authentifizieren sich dann nicht mehr. Das Merkmal folgt Ihrem Abonnement und ist nicht selbst verwaltbar. Wenden Sie sich in diesem Fall an Ihren BasePeak.AI-Kontakt.

Token-Format

sk-bpai-<user_id>-<key_id>-<secret>

Nur das letzte Segment ist geheim; die übrigen kennzeichnen, welcher Schlüssel vorgelegt wird. Die gespeicherte maskierte Form (sk-bpai-1-42-…jvT8) darf in Logs erscheinen und ist das, was die Oberfläche nach dem Anlegen anzeigt.

Einen Schlüssel verwenden

Senden Sie ihn als Bearer-Token:

curl -sS https://your-instance.platform.basepeak.ai/api/invoke/a17jlm7 \
  -H "Authorization: Bearer sk-bpai-1-42-…" \
  -H "Content-Type: text/plain" \
  --data 'Hallo!'

Header je Schnittstelle

Header	Wo	Zweck
`Authorization: Bearer <token>`	überall	Das Token.
`X-BPAI-Agent: <agent>`	nur `/v1/chat/completions`	Welcher Agent ausgeführt wird. Muss vom Scope des Schlüssels abgedeckt sein.
`X-BPAI-Thread-Id: <thread>`	beide Chat-Schnittstellen	Eine bestehende Unterhaltung fortsetzen.
`Accept`	`/api/invoke/{id}`	Wählt Streaming, JSON oder reinen Text.

Bei /api/invoke/{id} kommt der Agent aus dem URL-Pfad, nicht aus einem Header. Siehe Invoke-API und OpenAI-kompatible API.

Mit den OpenAI-SDKs

from openai import OpenAI

client = OpenAI(
    api_key="sk-bpai-1-42-…",
    base_url="https://your-instance.platform.basepeak.ai/v1",
    default_headers={"X-BPAI-Agent": "a17jlm7"},
)

resp = client.chat.completions.create(
    model="ignored",          # es wird das Modell des Agenten verwendet
    messages=[{"role": "user", "content": "Hallo!"}],
)
print(resp.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "sk-bpai-1-42-…",
  baseURL: "https://your-instance.platform.basepeak.ai/v1",
  defaultHeaders: { "X-BPAI-Agent": "a17jlm7" },
});

const resp = await client.chat.completions.create({
  model: "ignored",
  messages: [{ role: "user", content: "Hallo!" }],
});
console.log(resp.choices[0].message.content);

Scopes

Ein Scope besteht aus drei Segmenten:

resource:action:id

resource und action stammen aus einer festen Liste – keines der beiden darf ein Platzhalter sein. Nur id darf * lauten.

Chat-Scopes

Scope	Erlaubt
`agent:chat:a17jlm7`	Chat mit genau diesem Agenten
`agent:chat:*`	Chat mit jedem Agenten, auf den das zugehörige Konto Zugriff hat
`credential:use:<credential>`	Erlaubt dem Schlüssel, ein gespeichertes Credential zu nutzen – und damit die Werkzeuge, die es benötigen. Siehe unten.

Ein Schlüssel mit Platzhalter wird bei jedem Aufruf erneut gegen die aktuellen Berechtigungen des zugehörigen Kontos geprüft. Er kann daher nie einen Agenten erreichen, den dieses Konto nicht auch im Browser öffnen könnte.

Credential-Scopes entscheiden, welche Werkzeuge dem Agenten bleiben

Das ist die häufigste Ursache dafür, dass „der Agent im Browser funktioniert, über die API aber seine Werkzeuge ignoriert“.

Die Werkzeuge eines Agenten benötigen häufig ein gespeichertes Credential – ein Google-Konto für den Kalender, ein Token für GitHub. Bei jedem Aufruf mit einem API-Schlüssel wird der Lauf gegen die credential:use:…-Scopes des Schlüssels gefiltert:

Credentials, die der Schlüssel nicht abdeckt, werden aus dem Agenten entfernt, und
jedes Werkzeug, das eines dieser Credentials benötigt, wird aus dem Lauf entfernt.

Das geschieht stillschweigend. Es gibt weder einen Fehler noch eine Warnung in der Antwort: der Agent antwortet einfach, als gäbe es das Werkzeug nicht.

Scopes des Schlüssels	Wirkung
nur `agent:chat:<id>`	Jedes Werkzeug mit Credential wird entfernt. Der Agent kann nur aus seinen Anweisungen und seinem Wissen antworten.
`agent:chat:<id>` + `credential:use:*`	Es wird nichts entfernt. Der Agent läuft mit allen Werkzeugen.
`agent:chat:<id>` + `credential:use:google`	Nur Werkzeuge mit abgedeckten Credentials bleiben, die übrigen werden entfernt.

Wenn Ihre Anbindung die Werkzeuge des Agenten benötigt, stellen Sie den Schlüssel also mit credential:use:* aus (oder nennen Sie die einzelnen Credentials):

{ "name": "calendar-bot", "scopes": ["agent:chat:a17jlm7", "credential:use:*"] }

Werkzeuge ohne Credential sind nie betroffen.

Management-Scopes

Neun weitere Berechtigungen schalten die Management-API frei:

Scope	Erlaubt
`agent:create:*`	Agenten anlegen, auflisten, lesen, kopieren, exportieren, importieren
`agent:update:*`	Agenten ändern, inklusive der Zuordnung von Wissenssammlungen
`agent:delete:*`	Agenten löschen
`knowledgeset:manage:*`	Wissenssammlungen, ihre Dateien, Im- und Exporte
`tool-reference:manage:*`	Werkzeuge und MCP-Server
`model-provider:manage:*`	Modelle und Modellanbieter
`trigger:manage:*`	Webhooks, E-Mail-Empfänger, Cronjobs
`task:manage:*`	Aufgaben und Aufgabenausführungen
`team:manage:*`	Agenten-Teams

Management-Scopes müssen * als id verwenden – mit Ausnahme von agent:update, siehe unten.

Mehrere Scopes pro Schlüssel

Ein Schlüssel darf beliebig viele Scopes tragen. Chat- und Management-Scopes auf einem Schlüssel zu mischen ist unterstützt und üblich:

{
  "name": "provisioning-bot",
  "scopes": ["agent:chat:*", "agent:create:*", "knowledgeset:manage:*"]
}

Beim Anlegen prüft der Server, dass Sie die angeforderten Agenten- und Management-Berechtigungen aktuell selbst besitzen. Eine Berechtigung, die Sie nicht haben, wird mit 403 abgelehnt. Das verhindert Schlüssel, die entweder wirkungslos wären oder eine Rechteausweitung darstellten. (credential:use:-Scopes werden bewusst nicht so geprüft.)

Scopes ohne erreichbare Route werden in der Regel abgelehnt statt wirkungslos gespeichert – mcp:*, agent:read und admin:* sind keine gültigen Scopes.

Scopes für Dateien und Unterhaltungen

Vier weitere Scopes betreffen Dateien und den Gesprächsverlauf. Jeder ist auf einen Agenten bezogen, thread:files:a17jlm7 bedeutet also „die Threads dieses Agenten“:

Scope	Erlaubt
`agent:files:<agent\|*>`	Dateien im eigenen Arbeitsbereich des Agenten auflisten und herunterladen (nur lesend). Diese Dateien werden in jede neue Unterhaltung übernommen.
`agent:files-write:<agent\|*>`	Alles, was `agent:files` erlaubt, plus Hochladen und Löschen. Eine Erweiterung von `agent:files` – ein Schlüssel braucht nicht beide. Lässt sich nur ausstellen, wenn das ausstellende Konto selbst die Berechtigung `agent:update` besitzt (siehe unten); ein reiner Chat-Nutzer kann sich Schreibzugriff auf den Arbeitsbereich eines Agenten nicht selbst verschaffen.
`thread:files:<agent\|*>`	Auflisten, Herunterladen, Hochladen und Löschen im Arbeitsbereich einer einzelnen Unterhaltung (beide Richtungen, ein Scope).
`thread:read:<agent\|*>`	Unterhaltungen dieses Agenten auflisten (`GET /api/threads`), einzeln abrufen (`GET /api/threads/{id}`) und ihren Verlauf erneut abspielen (`GET /api/threads/{id}/events`) – nur die eigenen Unterhaltungen des Schlüsselkontos. Siehe Threads.

Sie werden wie Chat-Scopes vergeben: Sie müssen den Agenten erreichen können, um sie auszustellen. agent:files-write verlangt zusätzlich, dass Sie selbst die Berechtigung agent:update besitzen – sonst scheitert das Anlegen mit 403, genau wie bei einem Management-Scope ohne die passende Berechtigung. Darüber hinaus sind diese Scopes voneinander und von agent:chat unabhängig – ein Chat-Schlüssel erhält keinen Dateizugriff, ein Datei-Schlüssel kann nicht chatten.

POST /api/threads/{id}/abort braucht keinen eigenen Scope: Einen Lauf zu starten und ihn abzubrechen ist dieselbe Befugnis, agent:chat deckt beides ab.

Diese Scopes lassen sich – wie Management-Scopes – im Dialog Profil → API-Schlüssel → API-Schlüssel erstellen vergeben oder über REST anlegen (POST /api/account/apikeys).

Scopes für Projekte

Acht weitere Scopes adressieren ein Projekt statt eines Agenten – die Einheit, in der auch der Browser eine Unterhaltung führt. Jeder nimmt eine konkrete p1…-Projekt-ID oder *:

Scope	Erlaubt
`project:chat:<p\|*>`	Unterhaltungen im Projekt beginnen und fortsetzen
`project:files:<p\|*>`	Geteilten Arbeitsbereich des Projekts auflisten und herunterladen
`project:files-write:<p\|*>`	Zusätzlich hochladen und löschen; strikte Erweiterung von `project:files`
`project:knowledge:<p\|*>`	Wissenssammlung des Projekts auflisten (inklusive Einlese-Status) und herunterladen
`project:knowledge-write:<p\|*>`	Zusätzlich hochladen und löschen; strikte Erweiterung von `project:knowledge`
`project:tasks:<p\|*>`	Aufgaben des Projekts: anlegen, lesen, ändern, löschen, ausführen und ihre Läufe
`project:threads:<p\|*>`	Unterhaltungen des Projekts lesen: auflisten, abrufen und erneut abspielen
`project:env:<p\|*>`	Umgebungsvariablen des Projekts lesen – einschließlich der Werte
`project:env-write:<p\|*>`	Umgebungsvariablen des Projekts setzen

project:files-write und project:knowledge-write sind strikte Erweiterungen ihrer lesenden Geschwister – ein Schlüssel mit der schreibenden Hälfte muss die lesende nicht zusätzlich ausstellen.

project:env und project:env-write sind unabhängige Hälften

Anders als bei Dateien und Wissen impliziert hier die schreibende Hälfte nicht die lesende, und umgekehrt. project:env liest die gespeicherten Werte der Umgebungsvariablen zurück – dort liegen die Geheimnisse der Werkzeuge eines Projekts. project:env-write setzt sie. Ein Schlüssel, der nur ein Geheimnis rotieren soll, muss es dafür nie lesen können – deshalb bleibt dieser eine Scope vom sonst geltenden Muster ausgenommen. Details und Beispiele: Projekte.

project:tasks ist bewusst nicht aufgeteilt – ein Scope deckt Lesen, Schreiben und Ausführen im Projekt gleichermaßen ab, analog zu task:manage auf der flachen Oberfläche.

project:threads ist ebenfalls nicht aufgeteilt, allerdings aus dem umgekehrten Grund: Der Scope ist rein lesend und hat keine schreibende Hälfte. Unterhaltungen zu ändern oder zu löschen ist über API-Schlüssel generell nicht möglich, und das Abbrechen eines laufenden Zuges (POST /api/threads/{id}/abort) bleibt beim Chat-Scope – einen Lauf zu starten und ihn zu stoppen ist dieselbe Befugnis.

project:chat schließt das Zurücklesen der Unterhaltung nicht ein

Ein Schlüssel mit ausschließlich project:chat:<p> kann Unterhaltungen beginnen und fortsetzen, sie aber weder auflisten noch abrufen oder erneut abspielen – er muss den Antwort-Header X-Bpai-Thread-Id mitschneiden und die ID selbst aufbewahren. Vergeben Sie zusätzlich project:threads:<p>, damit die Integration ihre eigenen Unterhaltungen zurücklesen kann.

Greifen Sie zu project:threads:<p> statt zu thread:read:<agent>, wann immer die Absicht lautet „diese Integration liest ihr eigenes Projekt“: thread:read ist an den Agenten gebunden und erlaubt damit jede Unterhaltung dieses Agenten – über alle Projekte hinweg, die er bedient. Siehe Unterhaltungen.

Alle neun Projekt-Scopes gründen ausschließlich auf Projektmitgliedschaft. Anders als bei agent:files-write ist dafür keine Management-Berechtigung nötig, auch nicht für die schreibenden Hälften: Die Browser-Sitzung verlangt für dieselben Mutationen ebenfalls nur Zugriff auf das Projekt. Ausführliche Routen, Beispiele und Fehlerfälle: Projekte.

`task:manage` gegenüber `project:tasks`

Die beiden Aufgaben-Scopes überschneiden sich, ohne dass einer den anderen enthält:

Scope	Reichweite
`task:manage` (nur `*`)	Jede Aufgabe, die dem Konto des Schlüssels gehört, über alle Projekte hinweg – kein Pinnen auf ein einzelnes Projekt möglich.
`project:tasks:<p>`	Jede Aufgabe in genau diesem Projekt – auch eine, die dem Konto nur über eine `ThreadAuthorization`-Freigabe zugänglich ist, nicht über Eigentum. Das sieht die flache Oberfläche (`GET /api/tasks`) gar nicht, da sie ausschließlich nach Eigentum filtert.

Aufgaben anlegen existiert zudem nur auf der projektbezogenen Route – ein flaches POST /api/tasks gibt es nicht.

Einen Schlüssel auf einen Agenten festlegen

agent:update ist die einzige Management-Berechtigung, die eine konkrete ID akzeptiert:

Scope	Reichweite
`agent:update:*`	Jeder Agent, den das zugehörige Konto ändern darf
`agent:update:a17jlm7`	Nur Agent `a17jlm7` – bei jedem anderen `403`

In Kombination mit einem passenden Chat-Scope erhalten Sie einen Schlüssel, der mit genau einem Agenten sprechen und genau diesen Agenten ändern darf – und sonst nichts:

{ "name": "self-improve", "scopes": ["agent:chat:a17jlm7", "agent:update:a17jlm7"] }

Die Festlegung verengt ausschließlich den Schlüssel. Sie ändert nicht, was Sie beim Anlegen bereits besitzen müssen.

Schlüssel verwalten

Die Liste zeigt Name, maskiertes Token, Erstellungszeit, letzte Nutzung und Ablauf. Die letzte Nutzung wird asynchron und höchstens einmal pro Minute und Schlüssel aktualisiert; ein sehr aktueller Aufruf erscheint daher möglicherweise nicht sofort.

Ein Widerruf wirkt unmittelbar – die nächste Anfrage mit diesem Token erhält 401.

Rotieren stellt ein neues Geheimnis für denselben Schlüssel aus: ID, Name, Scopes, Ablaufdatum und Audit-Log bleiben erhalten, das alte Geheimnis funktioniert sofort nicht mehr, und das neue wird genau einmal angezeigt.

Instanz-Administratoren sehen unter Zugriff → API-Schlüssel im Admin-Bereich zusätzlich die Schlüssel aller Benutzer – maskiert, mit Besitzer und Audit-Log – und können jeden Schlüssel widerrufen. Geheimnisse werden nie gespeichert oder angezeigt; auch ein Administrator kann prüfen, aber niemals einen Benutzer imitieren.

REST-Referenz

Diese Routen gehören zur Browser-Sitzung, die die Schlüssel besitzt. API-Schlüssel können keine API-Schlüssel erstellen oder verwalten.

Methode	Pfad	Beschreibung
`GET`	`/api/account/apikeys`	Eigene Schlüssel auflisten. Enthält nie das Geheimnis.
`POST`	`/api/account/apikeys`	Schlüssel anlegen. Die einzige Antwort, die das Token im Klartext enthält.
`GET`	`/api/account/apikeys/{id}`	Metadaten eines Schlüssels.
`GET`	`/api/account/apikeys/{id}/audit`	Die 50 neuesten Audit-Einträge dieses Schlüssels. Nicht paginiert.
`DELETE`	`/api/account/apikeys/{id}`	Widerrufen. Liefert `204`; ein erneuter Aufruf `404`.
`POST`	`/api/account/apikeys/{id}/rotate`	Neues Geheimnis für denselben Schlüssel; die Antwort enthält es genau einmal.

Anfrage zum Anlegen:

{
  "name": "ci-pipeline",
  "description": "Generator für Release Notes",
  "scopes": ["agent:chat:a17jlm7"],
  "expiresAt": "2026-12-31T23:59:59Z"
}

Antwort – beachten Sie key, das Sie nicht wieder sehen werden:

{
  "id": 42,
  "userId": "1",
  "name": "ci-pipeline",
  "description": "Generator für Release Notes",
  "key": "sk-bpai-1-42-sJ_jvT…",
  "maskedKey": "sk-bpai-1-42-...jvT8",
  "scopes": ["agent:chat:a17jlm7"],
  "createdAt": "2026-06-05T12:34:56Z",
  "expiresAt": "2026-12-31T23:59:59Z"
}

Mindestens ein Scope ist erforderlich.

Audit-Verlauf

Jeder erfolgreiche Aufruf mit einem Schlüssel wird protokolliert: welcher Schlüssel und Agent, die Route, der resultierende Statuscode und die Dauer. Die Aufbewahrung beträgt standardmäßig 90 Tage. Die 50 neuesten Einträge sind über GET /api/account/apikeys/{id}/audit abrufbar.

Sicherheitsmodell

Aspekt	Behandlung
Das Token selbst	Wird nie gespeichert. Einmal angezeigt, danach nur als Hash vorhanden.
Geheimnis im Ruhezustand	Mit bcrypt gehasht.
Der `Authorization`-Header	Wird direkt nach der Authentifizierung entfernt und erreicht damit weder Request-Handler noch deren Logs.
Erreichbare Routen	Ein Schlüssel ist auf eine Positivliste beschränkt – Chat, Invoke, die Agenten- und Thread-Dateien, die Thread-Routen (auflisten, abrufen, Verlauf, abbrechen) und die Management-Routen. Alles andere antwortet mit `403`, auch wenn Scopes anderes nahelegen.
Erneute Prüfung des Kontos	Chat-Schlüssel mit Platzhalter werden bei jedem Aufruf gegen die aktuellen Rechte des zugehörigen Kontos geprüft.
Widerruf	Unmittelbar wirksam.

Zwei Konsequenzen, die Sie einplanen sollten: Ein Widerruf wirkt sofort und erfordert kein Leeren von Caches – und die Reichweite eines Schlüssels schrumpft mit der des zugehörigen Kontos. Verliert dieses den Zugriff auf einen Agenten, sind Platzhalter-Schlüssel für diesen Agenten sofort wirkungslos.

Fehlerbehebung

Antwort	Bedeutung	Was zu prüfen ist
`401 auth/bad-token-format`	Der Bearer ist kein wohlgeformtes `sk-bpai-…`-Token	Abschneiden in einer Umgebungsvariablen oder ein verbliebener Platzhalterwert. Vergleichen Sie mit dem maskierten Token in der Oberfläche.
`401 auth/invalid-token`	Wohlgeformt, aber nicht akzeptiert	Meist widerrufen, sonst ein Tippfehler im Geheimnis. Da `-` im Geheimnis gültig ist, ändert eine fehlerhafte Kopie nicht immer die Länge.
`401 auth/key-expired`	Ablaufdatum überschritten	Die Antwort enthält `expiredAt` zur Anzeige. Stellen Sie einen Ersatz aus.
`403 auth/api-access-disabled`	`apiAccess` ist für die Instanz deaktiviert	Nicht selbst verwaltbar – wenden Sie sich an Ihren BasePeak.AI-Kontakt.
`403 authz/scope-missing`	Die Scopes deckten die Anfrage nicht ab. Bei `/v1/chat/completions` und `/api/invoke/{id}` nennt der Body den `requiredScope`; die Datei-Routen (`/api/agents/{id}/files…`, `/api/threads/{id}/files…`) und die Thread-Routen (`GET /api/threads`, `GET /api/threads/{id}`, `GET /api/threads/{id}/events`, `POST /api/threads/{id}/abort`) antworten mit einem einfachen `403` ohne `requiredScope`-Feld.	Bei `/v1` prüfen, ob `X-BPAI-Agent` zu einem `agent:chat:<id>`-Scope passt; bei `/api/invoke/{id}` der Agent im Pfad. Bei den Thread-Routen, ob der Schlüssel entweder `thread:read` für den Agenten der Unterhaltung oder `project:threads` für ihr Projekt trägt – bzw. `agent:chat` beim Abbrechen.
`403` auf einer erwarteten Route	Die Route steht nicht auf der Positivliste	Threads auflisten, abrufen, deren Verlauf abspielen und laufende Züge abbrechen sind mit einem Schlüssel möglich – Umbenennen (`PUT`) und Löschen (`DELETE`) eines Threads nicht. Siehe API-Überblick.
`404 model_not_found`	Agent oder Alias ist nicht auflösbar	Eine falsch geschriebene ID oder ein Alias, der auf dieser Instanz nicht existiert.

Threads aus einem Schlüssel erscheinen im Projekt „API“

Das ist erwartetes Verhalten. Nur /v1/chat/completions leitet einen Thread-Namen ab; über /api/invoke/{id} erzeugte Threads bleiben ohne Namen. In der Admin-Thread-Liste erscheint als Projekt wörtlich „API“, weil der Schlüssel einen Agenten-Scope und keinen Projekt-Scope trägt – diese Threads sind absichtlich keinem Projekt zugeordnet. Siehe Threads.

Das gilt für /api/invoke/{id} und /v1/chat/completions. Ein über POST /api/projects/{project_id}/invoke gestarteter Thread ist die Ausnahme: Er hängt am Projekt und erscheint dort wie jede andere Unterhaltung. Siehe Projekte.

Weiterführende Dokumentation

API-Überblick – welche Schnittstelle wofür
OpenAI-kompatible API – /v1/chat/completions
Invoke-API – der native Ereignisstrom
Management-API – was Management-Scopes freischalten
Projekte – die neun Projekt-Scopes im Einsatz

Einen Schlüssel erstellen​

Token-Format​

Einen Schlüssel verwenden​

Header je Schnittstelle​

Mit den OpenAI-SDKs​

Scopes​

Chat-Scopes​

Credential-Scopes entscheiden, welche Werkzeuge dem Agenten bleiben​

Management-Scopes​

Mehrere Scopes pro Schlüssel​

Scopes für Dateien und Unterhaltungen​

Scopes für Projekte​

task:manage gegenüber project:tasks​

Einen Schlüssel auf einen Agenten festlegen​

Schlüssel verwalten​

REST-Referenz​

Audit-Verlauf​

Sicherheitsmodell​

Fehlerbehebung​

Threads aus einem Schlüssel erscheinen im Projekt „API“​

Weiterführende Dokumentation​