Den enkleste feilen er å behandle Rivya API og Rivya Studio som konkurrerende stier.
De forstås bedre som to faser av samme produkt. Studio er der mennesker utforsker, velger, gjennomgår og fortsetter arbeid visuelt. API-et er der en stabil arbeidsflyt blir del av et annet produkt, script eller backend-prosess.
Hvis du fortsatt lærer API-flaten, start med Hva er Rivya API?. Denne siden er smalere: hvordan du avgjør om en konkret oppgave hører hjemme i Studio eller i API-et.
Beslutningen i én tabell
| Spørsmål | Bruk Studio når... | Bruk API-et når... |
|---|---|---|
| Er outputen fortsatt utforskende? | ja | nei, arbeidsflyten er allerede repeterbar |
| Må en person sammenligne resultater? | ja | bare etter at appen din mottar resultater |
| Er modellvalget stabilt? | ikke ennå | ja, eller valgt fra API-modellisten |
| Trenger oppgaven referansemedier? | en person forbereder dem fortsatt | appen din kan laste dem opp gjennom Files API |
| Må resultatet oppdatere et annet system? | ikke ennå | ja, gjennom polling eller webhooks |
| Må credit-bruken være synlig? | ja, mens dere tester | ja, men gjennom API-kontroller på kontonivå |
Dette handler ikke om hvilken flate som er mer avansert. Det handler om hvorvidt oppgaven er klar for automatisering.
Bruk Studio mens arbeidet fortsatt endrer seg
Studio er riktig sted når den menneskelige beslutningen fortsatt er hovedarbeidet.
Det omfatter:
- å velge mellom bilde-, video-, lyd- eller chatmodeller
- å teste om en promptretning er verdt å beholde
- å sammenligne visuelle resultater side om side
- å avgjøre om referansemedier hjelper eller skader
- å bruke lagret historikk til å fortsette fra et tidligere resultat
Dette gjelder spesielt kreativt arbeid. Hvis briefen ikke er stabil, gjør automatisering av forespørselen vanligvis forvirringen raskere i stedet for mindre.
Bruk API-et når arbeidsflyten er repeterbar
API-et blir den bedre stien når inputene og de neste stegene er forutsigbare nok.
Gode tegn:
- produktet ditt vet allerede hvilken modell eller modellkategori det trenger
- brukerinput kan mappes til en stabil request body
- en backend-jobb kan polle status uten at noen ser på en skjerm
- en webhook kan oppdatere riktig oppføring når en oppgave er ferdig
- appen kan forklare credit-bruk for teamet eller kontoeieren
På det tidspunktet kan det bli den tregere stien å bruke Studio for hver kjøring. API-et lar produktet ditt starte oppgaven direkte.
En praktisk grense: oppdagelse kontra integrasjon
Bruk Studio til oppdagelse.
Bruk API-et til integrasjon.
Oppdagelse betyr:
- "Hvilken modell bør vi bruke?"
- "Hvilken promptform fungerer?"
- "Forbedrer referansemedier denne oppgaven?"
- "Er outputkvaliteten god nok for denne bruken?"
Integrasjon betyr:
- "Denne brukerhandlingen skal opprette én genereringsjobb."
- "Denne jobben skal kunne prøves igjen idempotent."
- "Denne filen skal lastes opp og knyttes til en modellforespørsel."
- "Denne fullførte oppgaven skal oppdatere produktets oppføring."
Den grensen hindrer API-et i å bli en skjult eksperimentflate.
Hvordan credits bør påvirke beslutningen
Både Studio- og API-bruk trekker fra de samme Rivya-kontocreditsene.
Det betyr at credit-atferd bør være del av produktdesignet, ikke en ettertanke.
Bruk Studio først når teamet fortsatt må lære kostnadsformen. Bruk API-et når oppgaven er stabil nok til at produktet kan forklare når credits kan reserveres eller brukes.
For de gjeldende offentlige reglene, les API Credits. Hvis en arbeidsflyt er for dyr til å forklare for kontoeieren, er den ikke klar for API-automatisering ennå.
Der filer endrer valget
Referansemedier er ofte der en integrasjon blir mer seriøs.
I Studio kan en person laste opp, inspisere, prøve på nytt og avgjøre om filen er god nok. I API-et må produktet ditt håndtere filstien bevisst gjennom Files API.
Bruk Studio når:
- referansebildet, videoen eller lyden fortsatt trenger menneskelig opprydding
- teamet er usikkert på hvilken referanse som bør styre modellen
- filreglene ennå ikke er tydelige for brukeren
Bruk API-et når:
- appen kan samle inn filen trygt
- modellens referansekrav er kjent
- filen kan lastes opp før genererings- eller chatforespørselen
- feil kan vises i ditt eget produkt uten å skjule hva som skjedde
Files API er en nyttig bro, men det fjerner ikke behovet for å designe filopplevelsen.
Der Chat endrer valget
Chat kan høre hjemme på begge sider.
Bruk Rivya Chat direkte når en person utforsker, skriver, gjennomgår eller bestemmer.
Bruk Chat API når chatrunden må leve inne i ditt eget produkt eller serverarbeidsflyt. Det kan omfatte ikke-strømmende runder, valgfri SSE-strømming, API-opprettede sesjoner og støttede filvedlegg.
Nøkkelspørsmålet er hvor samtalen skal leve. Hvis samtalen er del av Rivya-arbeid, bruk Rivya. Hvis samtalen er del av produktopplevelsen din, bruk API-et.
Når webhooks er et signal
Hvis arbeidsflyten din trenger API Webhooks, er den sannsynligvis forbi det manuelle Studio-stadiet.
Webhooks er nyttige når et annet system må reagere på fullførte genereringsoppgaver:
- markere et asset som klart
- varsle en bruker
- flytte et gjennomgangssteg videre
- flytte en feilet oppgave inn i support- eller retry-logikk
Det er integrasjonsarbeid. Studio kan fortsatt være nyttig for å teste modellstien, men produksjonsloopen hører hjemme i API-et.
Et trygt migreringsmønster
Ikke flytt en hel arbeidsflyt inn i API-et på én gang.
Bruk denne rekkefølgen:
- test oppgaven manuelt i Studio
- skriv ned stabil modell, promptform, inputfiler og forventet resultat
- les API Models og modellreferansen
- send én generering gjennom API Quickstart
- legg til Files API bare hvis modellen krever referansemedier
- legg til Webhooks først etter at polling fungerer
- legg til Chat API bare hvis produktet trenger chatrunder utenfor Studio
Hvert steg bør gjøre arbeidsflyten enklere å drive, ikke bare mer automatisert.
Når du bør bli i Studio
Bli i Studio når oppgaven fortsatt trenger:
- subjektiv gjennomgang
- promptforming
- visuell sammenligning
- modellutforsking
- lagret kreativ historikk
- en person som avgjør om neste steg er bilde, video, lyd eller chat
Det er ikke en svakhet. Studio er designet for den fasen.
Når du bør flytte til API
Flytt til API når:
- samme oppgave gjentas ofte
- inputen kan struktureres
- modellen er kjent
- appen må opprette oppgaver fra sitt eget UI
- status, feil og credits kan håndteres tydelig
- polling eller webhooks passer produktets backend
API-et er sterkest når det gjør en allerede forstått Rivya-arbeidsflyt til en pålitelig produkthandling.
Neste steg i Rivya
- Bruk Developers til å forhåndsvise API-flaten.
- Les Rivya API Quickstart før du skriver produksjonskode.
- Les API Authentication før du lagrer en API-nøkkel.
- Les Slik bygger du en multimodal AI-arbeidsflyt med Rivya API hvis neste spørsmål er hvordan du kobler modeller, filer, chat og webhooks.
- Bruk Flytte arbeid på tvers av Rivya Chat, Image, Video, Audio hvis prosjektet fortsatt hører hjemme i menneskestyrt Studio-arbeid.
