
L'erreur la plus facile est de traiter Rivya API et Rivya Studio comme deux chemins concurrents.
Il vaut mieux les comprendre comme deux étapes du même produit. Studio est l'endroit où les personnes explorent, choisissent, relisent et continuent le travail visuellement. L'API est l'endroit où un workflow stable devient une partie d'un autre produit, script ou processus backend.
Si vous découvrez encore la surface API, commencez par Qu'est-ce que la Rivya API ?. Cette page est plus étroite : comment décider si une tâche précise appartient à Studio ou à l'API.
La décision dans un tableau
| Question | Utilisez Studio quand... | Utilisez l'API quand... |
|---|---|---|
| La sortie est-elle encore exploratoire ? | oui | non, le workflow est déjà répétable |
| Une personne doit-elle comparer les résultats ? | oui | seulement après que votre app reçoit les résultats |
| Le choix du modèle est-il stable ? | pas encore | oui, ou sélectionné depuis la liste de modèles API |
| La tâche a-t-elle besoin de médias de référence ? | une personne les prépare encore | votre app peut les importer via Files API |
| Le résultat doit-il mettre à jour un autre système ? | pas encore | oui, par polling ou webhooks |
| L'usage des crédits doit-il rester visible ? | oui, pendant les tests | oui, mais via les contrôles API au niveau du compte |
Il ne s'agit pas de savoir quelle surface est plus avancée. Il s'agit de savoir si la tâche est prête à être automatisée.
Utilisez Studio tant que le travail change encore
Studio est le bon endroit lorsque la décision humaine reste le travail principal.
Cela inclut :
- choisir entre modèles image, vidéo, audio ou chat
- tester si une direction de prompt mérite d'être gardée
- comparer visuellement les résultats côte à côte
- décider si les médias de référence aident ou nuisent
- utiliser l'historique enregistré pour continuer depuis un résultat précédent
C'est particulièrement vrai pour le travail créatif. Si le brief n'est pas stable, automatiser la demande rend généralement la confusion plus rapide plutôt que plus petite.
Utilisez l'API quand le workflow est répétable
L'API devient le meilleur chemin lorsque les entrées et les étapes suivantes sont assez prévisibles.
Bons signaux :
- votre produit connaît déjà le modèle ou la catégorie de modèle dont il a besoin
- l'entrée utilisateur peut être transformée en corps de requête stable
- une tâche backend peut interroger le statut sans qu'une personne surveille un écran
- un webhook peut mettre à jour le bon enregistrement lorsqu'une tâche se termine
- l'app peut expliquer l'usage des crédits à l'équipe ou au propriétaire du compte
À ce stade, utiliser Studio pour chaque exécution peut devenir le chemin plus lent. L'API permet à votre produit de démarrer la tâche directement.
Une frontière pratique : découverte versus intégration
Utilisez Studio pour la découverte.
Utilisez l'API pour l'intégration.
Découverte signifie :
- "Quel modèle devons-nous utiliser ?"
- "Quelle forme de prompt fonctionne ?"
- "Les médias de référence améliorent-ils cette tâche ?"
- "La qualité de sortie est-elle suffisante pour ce cas d'usage ?"
Intégration signifie :
- "Cette action utilisateur doit créer une tâche de génération."
- "Cette tâche doit être rejouée de façon idempotente."
- "Ce fichier doit être importé et attaché à une requête de modèle."
- "Cette tâche terminée doit mettre à jour notre enregistrement produit."
Cette frontière empêche l'API de devenir une surface d'expérimentation cachée.
Comment les crédits doivent influencer la décision
Les usages Studio et API puisent tous deux dans les mêmes crédits de compte Rivya.
Cela signifie que le comportement des crédits doit faire partie de la conception produit, pas être une explication ajoutée après coup.
Utilisez d'abord Studio lorsque l'équipe doit encore apprendre la forme des coûts. Utilisez l'API lorsque la tâche est assez stable pour que le produit explique quand des crédits peuvent être réservés ou consommés.
Pour les règles publiques actuelles, lisez Crédits API. Si un workflow est trop coûteux pour être expliqué au propriétaire du compte, il n'est pas encore prêt pour l'automatisation API.
Là où les fichiers changent le choix
Les médias de référence sont souvent l'endroit où une intégration devient plus sérieuse.
Dans Studio, une personne peut importer, inspecter, réessayer et décider si le fichier est assez bon. Dans l'API, votre produit doit gérer le chemin du fichier délibérément via Files API.
Utilisez Studio quand :
- l'image, la vidéo ou l'audio de référence nécessite encore un nettoyage humain
- l'équipe ne sait pas encore quelle référence doit guider le modèle
- les règles de fichier ne sont pas encore claires pour l'utilisateur
Utilisez l'API quand :
- l'app peut collecter le fichier en sécurité
- les exigences de référence du modèle sont connues
- le fichier peut être importé avant la génération ou la requête chat
- les erreurs peuvent être affichées dans votre propre produit sans masquer ce qui s'est passé
Files API est un pont utile, mais elle ne supprime pas la nécessité de concevoir l'expérience fichier.
Là où Chat change le choix
Chat peut appartenir aux deux côtés.
Utilisez Rivya Chat directement lorsqu'une personne explore, écrit, relit ou décide.
Utilisez Chat API lorsque le tour de chat doit vivre dans votre propre produit ou workflow serveur. Cela peut inclure des tours non-streaming, du streaming SSE optionnel, des sessions créées par API et les pièces jointes de fichiers prises en charge.
La question clé est : où la conversation doit-elle vivre ? Si la conversation fait partie du travail Rivya, utilisez Rivya. Si elle fait partie de l'expérience de votre produit, utilisez l'API.
Quand les webhooks sont un signal
Si votre workflow a besoin de API Webhooks, il a probablement dépassé l'étape Studio manuelle.
Les webhooks sont utiles lorsqu'un autre système doit répondre à des tâches de génération terminées :
- marquer un asset comme prêt
- notifier un utilisateur
- faire avancer une étape de revue
- envoyer une tâche échouée vers le support ou une logique de relance
C'est du travail d'intégration. Studio peut encore être utile pour tester le chemin de modèle, mais la boucle de production appartient à l'API.
Un schéma de migration sûr
Ne déplacez pas tout un workflow vers l'API en une fois.
Utilisez cette séquence :
- tester la tâche manuellement dans Studio
- noter le modèle stable, la forme de prompt, les fichiers d'entrée et le résultat attendu
- lire API Models et la référence de modèle
- soumettre une génération via API Quickstart
- ajouter Files API seulement si le modèle exige des médias de référence
- ajouter Webhooks seulement après que le polling fonctionne
- ajouter Chat API seulement si le produit a besoin de tours de chat hors Studio
Chaque étape doit rendre le workflow plus facile à exploiter, pas seulement plus automatisé.
Quand rester dans Studio
Restez dans Studio lorsque la tâche a encore besoin de :
- revue subjective
- façonnage de prompt
- comparaison visuelle
- exploration de modèles
- historique créatif enregistré
- une personne qui décide si l'étape suivante est image, vidéo, audio ou chat
Ce n'est pas une faiblesse. Studio est conçu pour cette étape.
Quand passer à l'API
Passez à l'API quand :
- la même tâche se répète souvent
- l'entrée peut être structurée
- le modèle est connu
- l'app doit créer des tâches depuis sa propre interface
- le statut, les erreurs et les crédits peuvent être gérés clairement
- le polling ou les webhooks correspondent au backend du produit
L'API est la plus forte lorsqu'elle transforme un workflow Rivya déjà compris en action produit fiable.
Prochaine étape dans Rivya
- Utilisez Developers pour prévisualiser la surface API.
- Lisez Rivya API Quickstart avant d'écrire du code de production.
- Lisez API Authentication avant de stocker une clé API.
- Lisez Comment construire un workflow IA multimodal avec Rivya API si la prochaine question est de connecter modèles, fichiers, chat et webhooks.
- Utilisez Faire passer un projet entre Chat, Image, Video et Audio dans Rivya si le projet appartient encore au travail Studio mené par des humains.


