Skip to main content

Configurer un client

Le SDK ne lit pas lui-même les variables d’environnement. Dans ces exemples, votre application transmet l’identifiant depuis process.env.

Jetons d’accès OAuth

Pour une application agissant au nom d’un utilisateur, fournissez accessToken à la place de apiKey. Une fonction peut récupérer le jeton courant avant une requête :
Cet exemple lit un jeton déjà fourni au serveur. Pour une intégration en production, remplacez cette lecture par votre stockage de jetons et votre logique de renouvellement côté serveur. Le SDK ne réalise ni le consentement OAuth ni le renouvellement des jetons. Voir Exigences des clients OAuth. Les requêtes OAuth suivent l’appartenance actuelle de l’utilisateur à l’espace de travail, son rôle et les portées approuvées. Les clés API suivent leur propre espace de travail, statut et portées. Accès API est requis dans les deux cas. Ne fournissez pas les deux options d’authentification.

Délais et annulation

Les valeurs du client s’appliquent à toutes les opérations. Passez timeoutMs, maxRetries ou signal dans le dernier argument, après les entrées de la méthode, pour adapter une requête. Pour les méthodes générées de client.api, il s’agit du deuxième argument ; les raccourcis de ressources peuvent le placer en première, deuxième ou troisième position. Voir Exemples d’options de requête. Le délai couvre toute la requête, y compris la récupération du jeton, les répétitions, les pauses et la lecture de la réponse. Un AbortSignal permet à votre application de l’annuler plus tôt.
Annuler arrête l’attente de la réponse. Cela n’annule pas une action déjà acceptée par le serveur.

Répétition des requêtes

Les requêtes GET et HEAD éligibles peuvent être répétées après un problème réseau ou HTTP 429, 502, 503 ou 504. Le SDK respecte Retry-After lorsqu’il est présent et utilise sinon des délais croissants bornés. Les écritures ne sont jamais répétées automatiquement, même après une limitation de débit. Augmenter maxRetries n’active pas les répétitions d’écriture. Cela protège les appels, messages et achats de ressources contre les doublons accidentels.
Un délai dépassé ou une connexion perdue après une écriture peut laisser son résultat inconnu. Vérifiez l’état de la ressource, l’historique des appels ou le webhook avant de répéter l’action. Un en-tête d’idempotence arbitraire ne rend pas toutes les opérations répétables sans risque.

Traiter les erreurs

Ne journalisez ni identifiants ni corps de requête sensibles complets. Un ID de requête, lorsqu’il existe, aide l’assistance à retrouver l’échec.

Dépannage

Vérifiez indépendamment les mêmes identifiants avec la CLI :
Consultez la Référence API REST pour les comportements HTTP et les portées. Pour les connexions d’outils IA, utilisez le Guide MCP.