L'errore più facile è trattare Rivya API e Rivya Studio come percorsi concorrenti.
Si capiscono meglio come due fasi dello stesso prodotto. Studio è dove le persone esplorano, scelgono, rivedono e continuano il lavoro visivamente. L'API è dove un workflow stabile diventa parte di un altro prodotto, script o processo backend.
Se stai ancora imparando la superficie API, parti da Che cos'è la Rivya API?. Questa pagina è più stretta: come decidere se un task specifico appartiene a Studio o all'API.
La decisione in una tabella
| Domanda | Usa Studio quando... | Usa l'API quando... |
|---|---|---|
| L'output è ancora esplorativo? | sì | no, il workflow è già ripetibile |
| Una persona deve confrontare i risultati? | sì | solo dopo che la tua app riceve i risultati |
| La scelta del modello è stabile? | non ancora | sì, o selezionata dalla lista modelli API |
| Il task ha bisogno di media di riferimento? | una persona li sta ancora preparando | la tua app può caricarli tramite Files API |
| Il risultato deve aggiornare un altro sistema? | non ancora | sì, tramite polling o webhooks |
| L'uso dei credit deve restare visibile? | sì, durante i test | sì, ma tramite controlli API a livello account |
Non riguarda quale superficie sia più avanzata. Riguarda se il task è pronto per essere automatizzato.
Usa Studio mentre il lavoro sta ancora cambiando
Studio è il posto giusto quando la decisione umana è ancora il lavoro principale.
Include:
- scegliere tra modelli immagine, video, audio o chat
- testare se una direzione di prompt vale la pena tenerla
- confrontare risultati visivi fianco a fianco
- decidere se i media di riferimento stanno aiutando o danneggiando
- usare history salvata per continuare da un risultato precedente
È particolarmente vero per il lavoro creativo. Se il brief non è stabile, automatizzare la richiesta di solito rende la confusione più veloce invece che più piccola.
Usa l'API quando il workflow è ripetibile
L'API diventa il percorso migliore quando input e passaggi successivi sono abbastanza prevedibili.
Buoni segnali:
- il tuo prodotto conosce già il modello o la categoria modello di cui ha bisogno
- l'input utente può essere mappato in un request body stabile
- un job backend può fare polling dello stato senza qualcuno davanti allo schermo
- un webhook può aggiornare il record giusto quando un task termina
- l'app può spiegare l'uso dei credit al team o al proprietario account
A quel punto, usare Studio per ogni run può diventare il percorso più lento. L'API permette al tuo prodotto di avviare il task direttamente.
Un confine pratico: discovery contro integrazione
Usa Studio per discovery.
Usa l'API per integrazione.
Discovery significa:
- "Quale modello dovremmo usare?"
- "Quale forma di prompt funziona?"
- "I media di riferimento migliorano questo task?"
- "La qualità dell'output è abbastanza buona per questo caso d'uso?"
Integrazione significa:
- "Questa azione utente dovrebbe creare un job di generazione."
- "Questo job dovrebbe essere ritentato in modo idempotente."
- "Questo file dovrebbe essere caricato e allegato a una richiesta modello."
- "Questo task completato dovrebbe aggiornare il nostro record prodotto."
Questo confine impedisce all'API di diventare una superficie nascosta di esperimenti.
Come i credit dovrebbero influenzare la decisione
Sia Studio sia API attingono dagli stessi credit account Rivya.
Significa che il comportamento dei credit dovrebbe far parte del design prodotto, non essere un ripensamento.
Usa prima Studio quando il team deve ancora imparare la forma del costo. Usa l'API quando il task è abbastanza stabile perché il prodotto possa spiegare quando i credit possono essere riservati o consumati.
Per le regole pubbliche correnti, leggi API Credits. Se un workflow è troppo costoso da spiegare al proprietario account, non è ancora pronto per l'automazione API.
Dove i file cambiano la scelta
I media di riferimento sono spesso il punto in cui un'integrazione diventa più seria.
In Studio, una persona può caricare, ispezionare, riprovare e decidere se il file è abbastanza buono. Nell'API, il tuo prodotto deve gestire deliberatamente il percorso file tramite Files API.
Usa Studio quando:
- immagine, video o audio di riferimento richiede ancora cleanup umano
- il team non è sicuro di quale riferimento debba guidare il modello
- le regole dei file non sono ancora chiare per l'utente
Usa l'API quando:
- l'app può raccogliere il file in sicurezza
- i requisiti di riferimento del modello sono noti
- il file può essere caricato prima della richiesta generazione o chat
- gli errori possono essere mostrati nel tuo prodotto senza nascondere cosa è successo
Files API è un ponte utile, ma non elimina il bisogno di progettare l'esperienza file.
Dove Chat cambia la scelta
Chat può appartenere a entrambi i lati.
Usa Rivya Chat direttamente quando una persona sta esplorando, scrivendo, rivedendo o decidendo.
Usa Chat API quando il turno chat deve vivere dentro il tuo prodotto o workflow server. Può includere turni non-streaming, streaming SSE opzionale, sessioni create via API e allegati file supportati.
La domanda chiave è dove dovrebbe vivere la conversazione. Se la conversazione fa parte del lavoro Rivya, usa Rivya. Se la conversazione fa parte dell'esperienza del tuo prodotto, usa l'API.
Quando i webhooks sono un segnale
Se il tuo workflow ha bisogno di API Webhooks, probabilmente è oltre la fase manuale di Studio.
I webhooks sono utili quando un altro sistema deve rispondere a task di generazione completati:
- segnare un asset come pronto
- notificare un utente
- spostare avanti uno step di revisione
- portare un task fallito in support o logica di retry
Questo è lavoro di integrazione. Studio può ancora essere utile per testare il percorso modello, ma il loop di produzione appartiene all'API.
Un pattern di migrazione sicuro
Non spostare un intero workflow nell'API in una volta.
Usa questa sequenza:
- testa manualmente il task in Studio
- annota modello stabile, forma del prompt, file input e risultato atteso
- leggi API Models e il riferimento modello
- invia una generazione tramite API Quickstart
- aggiungi Files API solo se il modello richiede media di riferimento
- aggiungi Webhooks solo dopo che il polling funziona
- aggiungi Chat API solo se il prodotto ha bisogno di turni chat fuori da Studio
Ogni step dovrebbe rendere il workflow più facile da operare, non solo più automatizzato.
Quando restare in Studio
Resta in Studio quando il task ha ancora bisogno di:
- revisione soggettiva
- modellazione del prompt
- confronto visivo
- esplorazione modelli
- history creativa salvata
- una persona che decida se il passo successivo sia immagine, video, audio o chat
Non è una debolezza. Studio è progettato per quella fase.
Quando passare all'API
Passa all'API quando:
- lo stesso task si ripete spesso
- l'input può essere strutturato
- il modello è noto
- l'app deve creare task dalla propria UI
- stato, errori e credit possono essere gestiti chiaramente
- polling o webhooks si adattano al backend del prodotto
L'API è più forte quando trasforma un workflow Rivya già compreso in un'azione prodotto affidabile.
Prossimo passo in Rivya
- Usa Developers per vedere in anteprima la superficie API.
- Leggi Rivya API Quickstart prima di scrivere codice di produzione.
- Leggi Autenticazione API prima di salvare una API key.
- Leggi Come costruire un workflow AI multimodale con Rivya API se la prossima domanda è come collegare modelli, file, chat e webhooks.
- Usa Spostare il lavoro tra Rivya Chat, Image, Video, Audio se il progetto appartiene ancora a lavoro Studio guidato da persone.
