Skip to main content

Client konfigurieren

Das SDK liest Umgebungsvariablen nicht selbst. In diesen Beispielen übergibt Ihre Anwendung die Zugangsdaten aus process.env.

OAuth-Zugriffstokens

Für eine Anwendung im Auftrag eines Benutzers übergeben Sie accessToken statt apiKey. Eine Callback-Funktion kann vor einer Anfrage das aktuelle Token abrufen:
Dieses Beispiel liest ein Token, das dem Server bereits bereitgestellt wurde. Ersetzen Sie die Abfrage für eine produktive Integration durch Ihren serverseitigen Token-Speicher und Ihre Erneuerungslogik. Das SDK führt weder die OAuth-Zustimmung noch die Token-Erneuerung aus. Siehe Anforderungen an OAuth-Clients. OAuth-Anfragen berücksichtigen die aktuelle Workspace-Mitgliedschaft, Rolle und genehmigten Scopes des Benutzers. API-Schlüssel folgen ihrem eigenen Workspace, Status und ihren Scopes. Beide benötigen API-Zugriff. Übergeben Sie nicht beide Zugangsdatenoptionen.

Timeouts und Abbruch

Die Client-Standardwerte gelten für jede Operation. Übergeben Sie timeoutMs, maxRetries oder signal im letzten Argument nach den Methodeneingaben, um eine einzelne Anfrage anzupassen. Bei generierten client.api-Methoden ist es das zweite Argument; bei Ressourcen-Kurzmethoden kann es an erster, zweiter oder dritter Stelle stehen. Siehe Beispiele für Anfrageoptionen. Das Zeitlimit gilt für die gesamte Anfrage einschließlich Token-Abruf, Wiederholungen, Wartezeiten und Lesen der Antwort. Mit einem AbortSignal kann Ihre Anwendung früher abbrechen.
Ein Abbruch beendet das Warten auf die Antwort. Er macht eine vom Server bereits angenommene API-Aktion nicht rückgängig.

Wiederholungsverhalten

Geeignete GET- und HEAD-Anfragen können nach einem Netzwerkfehler oder HTTP 429, 502, 503 oder 504 wiederholt werden. Das SDK berücksichtigt vorhandene Retry-After-Angaben und verwendet sonst begrenzte, steigende Wartezeiten. Schreibanfragen werden niemals automatisch wiederholt, auch nicht nach einer Ratenbegrenzung. Ein höheres maxRetries aktiviert keine Schreibwiederholungen. So werden Aktionen wie Anrufe, Nachrichten und Ressourcenkäufe vor versehentlicher Duplizierung geschützt.
Nach einem Timeout oder Verbindungsverlust bei einer Schreibanfrage kann das Ergebnis unbekannt sein. Prüfen Sie Ressourcenstatus, Anrufverlauf oder Webhook, bevor Sie die Aktion wiederholen. Ein beliebiger Idempotenz-Header macht nicht jede Operation sicher wiederholbar.

Fehler behandeln

Protokollieren Sie keine Zugangsdaten oder vollständigen sensiblen Anfrageinhalte. Eine vorhandene Anfrage-ID hilft dem Support, die fehlgeschlagene Anfrage zu finden.

Fehlerbehebung

Prüfen Sie dieselben Zugangsdaten unabhängig mit der CLI:
HTTP-Verhalten und Scope-Anforderungen finden Sie in der REST-API-Referenz. Für KI-Werkzeugverbindungen nutzen Sie die MCP-Anleitung.