Envía solicitudes de chat con OAuth

Elige este camino cuando un cliente haya autorizado tu aplicación para usar su cuenta de ShareAI seleccionada. Primero completa el código de autorización con PKCE y obtén una concesión que incluya surcharge.

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}'

El token de acceso va en el encabezado Bearer#

El endpoint de chat y el cuerpo de la solicitud son los mismos que en el flujo de clave API. La diferencia está en la credencial y su ciclo de vida de autorización. Un token de actualización se envía solo al endpoint de token; un token de ID se usa únicamente para el inicio de sesión validado de la aplicación.

¿Quién paga y qué plan se aplica?#

La concesión aceptada identifica la cuenta personal u organizacional seleccionada, la aplicación y el plan de uso. El servicio determina esos valores a partir de la autorización. No envíes un ID de pagador, tarifa del Builder u otro sujeto del cliente en el cuerpo del chat para cambiar la facturación.

Renovar acceso sin perder el consentimiento#

Cuando el token de acceso expire, utiliza el flujo de actualización en tu backend y almacena el token de actualización de reemplazo. Cuando la concesión sea revocada o se requiera un nuevo consentimiento, reconecta al cliente a través del flujo del navegador.

Manejo de fallos#

Identidad del modelo y proveedores de ejecución#

Copia el identificador exacto del modelo basado en el creador desde Modelos. Selecciona la infraestructura por separado con el provider objeto opcional. El valor predeterminado clasifica a los proveedores elegibles por precio, del más bajo al más alto. Elige proveedores o consulta la referencia completa de políticas.

Límites mensuales de gasto y recuperación de facturación#

Cada cuenta de pago puede establecer su propio límite mensual de gasto en IA por aplicación o servicio de cliente en Facturación → Suscripciones y Compromisos. El límite incluye el costo de red y el recargo del builder, mientras que las suscripciones fijas y las compras confirmadas permanecen separadas. Un error de límite utiliza HTTP 402 application_spending_limit_exceeded; créditos elegibles insuficientes utilizan HTTP 402 insufficient_credits. Ambos proporcionan un enlace de facturación para el cliente. Ejemplo de contrato de error, manejo de streaming e integración.