Envoyez des requêtes de chat avec OAuth
Utilisez un jeton d'accès OAuth ShareAI approuvé pour les complétions de chat financées par le client et gérez l'expiration du jeton, le consentement et les limites de compte.
Sur cette page
Choisissez ce chemin lorsqu'un client a autorisé votre application à utiliser son compte ShareAI sélectionné. Commencez par compléter le code d'autorisation avec PKCE et obtenez une autorisation incluant surcharge.
https://api.shareai.now/api/v1/chat/completionsExécutez l'inférence selon l'accord d'application accepté par le client.
- URL de base
https://api.shareai.now- Authentification
- Jeton d’accès OAuth Bearer
- Portée requise
surcharge
cURL
curl --fail-with-body https://api.shareai.now/api/v1/chat/completions \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
--data '{"model":"MODEL_IDENTIFIER","messages":[{"role":"user","content":"Hello!"}],"stream":false}'
Le jeton d'accès est placé dans l'en-tête Bearer#
Le point de terminaison de chat et le corps de la requête sont identiques au flux basé sur la clé API. La différence réside dans les informations d'identification et leur cycle de vie d'autorisation. Un jeton d'actualisation est envoyé uniquement au point de terminaison du jeton ; un jeton d'identité est utilisé uniquement pour la connexion validée à l'application.
Qui paie et quel plan s'applique ?#
L'autorisation acceptée identifie le compte personnel ou organisationnel sélectionné, l'application et le plan d'utilisation. Le service détermine ces valeurs à partir de l'autorisation. Ne pas envoyer d'ID de payeur, de frais de Builder ou d'autre sujet client dans le corps du chat pour modifier la facturation.
Renouvelez l'accès sans perdre le consentement#
Lorsque le jeton d'accès expire, utilisez le flux d'actualisation sur votre backend et stockez le jeton d'actualisation de remplacement. Lorsque l'autorisation est révoquée ou qu'un nouveau consentement est requis, reconnectez le client via le flux du navigateur.
Gestion des échecs#
| Résultat | Action |
|---|---|
401 consent_required | Demandez au client de se reconnecter si l'autorisation n'est plus valide. |
403 | Vérifiez l'autorisation d'inférence accordée et l'accès au modèle/fournisseur autorisé. |
429 | Respectez Retry-After et les limites de votre application/compte. |
503 temporarily_unavailable | Affichez une erreur de service temporaire ; ne dites pas au client que le consentement a été révoqué. |
Identité du modèle et fournisseurs d'exécution#
Copiez l'identifiant exact du modèle basé sur le créateur depuis Modèles. Sélectionnez l'infrastructure séparément avec l'objet provider objet. Par défaut, les fournisseurs éligibles sont classés par prix, du plus bas au plus élevé. Choisissez des fournisseurs ou consultez la référence complète de la politique.
Limites de dépenses mensuelles et récupération de facturation#
Chaque compte payant peut définir sa propre limite mensuelle de dépenses en IA par application ou service client dans Facturation → Abonnements & Engagements. Le plafond inclut le coût du réseau et la surcharge du Builder, tandis que les abonnements fixes et les achats confirmés restent séparés. Une erreur de plafond utilise HTTP 402 application_spending_limit_exceeded; des crédits éligibles insuffisants utilisent HTTP 402 insufficient_credits. Les deux fournissent un lien de facturation client. Exemple de contrat d'erreur, gestion du streaming et intégration.
Dernière mise à jour le 18 septembre 2026