spicyapiDocumentation
Contenu principal

Diagnostic et reprise des requêtes

Résoudre les envois incertains, les conflits de devis, les problèmes de fichiers et les flux interrompus.

Conserver les éléments utiles

Notez l’heure, le point de terminaison, le statut HTTP, le code applicatif, request_id et tout taskId reçu. Distinguez refus explicite, absence de réponse réseau et échec après acceptation. Ne joignez pas de clé API, de prompt complet ni de fichier original aux journaux généraux ou demandes de support.

Modèle absent ou indisponible

Actualisez le catalogue authentifié et vérifiez enabled, available et le modèle exact de la tâche. Une page publique ne prouve pas que votre compte peut appeler le modèle. Si 50301 persiste, revérifiez la disponibilité et limitez les tentatives. Répéter ne rend pas un modèle disponible.

Paramètres invalides ou conflit de devis

Pour 400, comparez types, valeurs admises et exigences conditionnelles avec le schéma inputSchema actuel ; retirez les paramètres non pris en charge. Pour 40901, refaites confirmer un devis : requête, validité ou prix ont changé. Un 409 ordinaire dépend de l’opération. Une clé associée à un autre contenu exige de corriger le lien métier.

Délai dépassé sans identifiant de tâche

Gardez le contenu et l’Idempotency-Key d’origine. Renvoyez la même requête pendant sa période de validité avant d’en créer une nouvelle. Avec taskId, consultez recordInfo. Un délai client, un onglet fermé ou un flux coupé n’annule pas une tâche acceptée ; vérifiez state, cost et settled.

Fichier téléversé mais entrée refusée

Après PUT, appelez files/{fileId}/commit. Utilisez l’URI spicy:// renvoyé dans un champ accepté par le modèle, jamais uploadUrl. Vérifiez Content-Type signé, taille, format, compte propriétaire et expiration. Les fichiers entrants sont conservés un jour ; une nouvelle tentative peut nécessiter un nouvel envoi et une entrée actualisée.

Callback absent ou lien expiré

Vérifiez le récepteur HTTPS, la signature sur les octets d’origine et une réponse positive rapide. Récupérez l’état via recordInfo et dédupliquez les callbacks avant de traiter une commande. Si le résultat est encore conservé, demandez un nouveau lien. Si l’état est pending, réessayez plus tard. Pour unavailable ou un résultat dont la conservation a expiré, actualiser l’ancienne URL ne restaure pas le fichier.

Le flux s’arrête trop tôt

Vérifiez statut HTTP et Content-Type avant de décoder les SSE du protocole choisi. Les fragments TCP ne sont pas des événements complets ; la fermeture ne prouve pas la réussite. Contrôlez événements terminaux, erreurs et délais applicatifs. Ne supposez ni remboursement ni nouvel envoi gratuit après coupure ; conservez request_id et consultez l’usage.

Solde, limites et assistance

40201 concerne le solde disponible, 40202 les plafonds du compte et de la clé. Pour 429, respectez Retry-After et réduisez la fréquence. N’envoyez jamais de clé au support. Fournissez étapes, heure, identifiants, structure expurgée des champs et résultats attendu et obtenu.

Guides associés

Erreurs et nouvelles tentatives · Idempotence · Téléversement et téléchargement des médias · Texte et streaming

Sur cette page