Rivya AI
Rivya Journal
Författare
Kategorier
Innehållsförteckning
Fortsätt utforska
Fortsätt med relaterade guider, produktanteckningar och arbetsflödesgenomgångar från Rivya-teamet.
En bra Rivya API-integration är inte bara en begäran till en modell.
De flesta verkliga produktarbetsflöden har en liten kedja: välj rätt modell, förbered indata, ladda upp referensfiler vid behov, skicka in ett jobb, följ status, hantera krediter och meddela produkten när resultatet är klart.
Den här artikeln visar planeringsformen. Använd Rivya API-snabbstart för den kortaste körbara vägen och använd API-dokumentationen för exakta begäransfält.
Arbetsflödet nedan beskriver det implementerade kontraktet för det offentliga API:et. Innan du börjar bygga behöver du kontrollera att API:et är aktiverat för både driftsmiljön och kontot, att den valda modellen är API-redo och att valfria funktioner som webhooks faktiskt är tillgängliga.
Innan du väljer API-rutter ska du beskriva produkthändelsen i en mening.
Exempel:
Skapa ett utkast till produktbild när en säljare skickar in en listningsbrief.
Generera ett kort videokoncept efter att en kampanjansvarig har godkänt en stillbildsriktning.
Skicka en chattur i ett internt researchverktyg och streama svaret tillbaka till användaren.
Ladda upp en referensbild, skicka en stödd modellbegäran och meddela användaren när resultatet är klart.
Den meningen hindrar integrationen från att bli en lös samling API-anrop.
Använd den här tabellen innan du öppnar schemat för begäran.
| Arbetsflödessteg | Produktfråga | API-område |
|---|---|---|
| Kontoåtkomst | Vilket Rivya-konto äger användningen? | API-autentisering |
| Modellval | Vilket publikt modell-ID passar jobbet? | API-modeller |
| Referensindata | Behöver modellen uppladdad media? | Files API |
| Generering | Är det här ett async bild-, video- eller ljudjobb? | Skapa generering |
| Chatt | Är det här en chattmodellstur i stället för ett genereringsjobb? | Chat API |
| Status | Hur vet produkten att resultatet är klart? | Genereringsstatus |
| Sluthändelse | Ska ett annat system få ett signerat återanrop, och är webhooks aktiverade? | API-webhooks |
| Krediter | Hur ska teamet förstå kostnaden? | API-krediter |
Arbetsflödet ska vara tillräckligt tydligt för att varje API-område ska ha ett skäl att finnas.
Skapa en API-nyckel för den specifika appen, miljön eller arbetsflödet som ska använda den.
Undvik att använda en nyckel för allt. Att namnge nycklar efter syfte gör senare granskning enklare:
production-image-workflow
staging-video-tests
internal-chat-assistant
webhook-smoke-test
Läs API-autentisering innan du lagrar nyckeln. Hela hemligheten visas en gång, så ditt team bör direkt spara den i rätt serverbaserad hemlighetslagring.
Hårdkoda inte en modell bara för att den fungerade i ett manuellt test.
Använd API-modeller och modellreferensen för API för att bekräfta:
publikt modell-ID
om den är tillgänglig via API
stödd indatametod
förväntningar på prompt och parametrar
om Files API krävs
kreditbeteende och förberedelsenoteringar
Här blir många integrationer renare. En modell som är perfekt för ett manuellt Studio-test kanske inte är den bästa första modellen för ett automatiserat produktflöde.
Om modellen kan köras från textindata håller du första versionen textbaserad.
Lägg bara till Files API när arbetsflödet verkligen behöver referensmedia.
När det gör det, definiera:
vilka filtyper produkten accepterar
vem som äger filrensningssteget
vad som händer när uppladdningen misslyckas
hur returnerad fildata skickas vidare till modellparametrar
om samma fil ska återanvändas eller laddas upp igen
Det hindrar en skör filupplevelse från att döljas bakom en prydlig genereringsknapp.
För bild-, video- och ljudgenerering är det normala mönstret:
förbered modell-ID, prompt och stödda parametrar
lägg till en idempotensnyckel för säkra omförsök
skicka via genererings-endpointen
spara publikt uppgifts-ID
polla status tills uppgiften når ett slutläge
Använd Skapa generering för begäransformen och Genereringsstatus för resultathantering.
Produkten bör behandla queued, processing, succeeded och failed som användarsynliga tillstånd. Låt inte användare läsa systemdetaljer eller gissa varför ett jobb är långsamt.
Chattmodeller ska använda Chat API, inte genererings-endpointen.
Det spelar roll eftersom chattarbete beter sig annorlunda:
chatturer kan höra till API-skapade sessioner
icke-streaming och SSE-streaming ger olika användarupplevelser
bildbilagor använder fil-ID:n från Files API
kreditavräkning följer chatturen snarare än ett vanligt asynkront mediajobb
Om din produkt behöver ett assistantsvar i sitt eget gränssnitt kan Chat API vara rätt väg. Om användaren fortfarande utforskar idéer kan Rivya Chat eller Studio passa bättre.
För en första version är regelbundna statuskontroller lättare att förstå.
Om webhooks är aktiverade för driftsmiljön kan du lägga till API Webhooks när:
produkten har många async-jobb
väntande klienter inte bör polla direkt
nedströms system behöver signerade sluthändelser
omförsök och dubletthantering redan är utformade
Webhook-mottagare ska vara enkla och strikta: verifiera signaturen, acceptera dublettsäkra händelser, uppdatera en produktpost och logga bara sådant som är säkert att logga.
Rivya API använder samma kontocredits som Studio.
Din integration bör avgöra hur mycket av det som ska visas. Som minimum bör teamet veta:
vilket konto som äger API-nyckeln
vilket arbetsflöde som kan förbruka krediter
vad som händer när krediterna inte räcker
hur misslyckade genereringstillstånd förklaras
vart användaren ska hänvisas med frågor om krediter och fakturering
Använd API Credits, Credits och fakturering i Rivya och Hur du tänker kring Rivya credits, paket och planer för den användarsynliga plånboksmodellen.
En bra första version är avsiktligt begränsad.
Till exempel:
en API-nyckel
en vald bildmodell
ingen filuppladdning ännu
en genereringsbegäran
en väg för statuspolling
en enkel resultatförhandsvisning i din produkt
ett tydligt felmeddelande om otillräckliga krediter
Den versionen bevisar kopplingen innan du lägger till fler rörliga delar.
När den första versionen fungerar kan ett fylligare arbetsflöde lägga till:
Files API för referensbilder eller videor
modellspecifika parameterkontroller
idempotens kopplad till din produktpost
signerade webhooks för slutförande när funktionen är aktiverad
Chat API för assistantturer
en serverbaserad eventstream där chatt behöver liveutdata
admin- eller supportvyer för misslyckade jobb
Varje tillägg ska svara på ett verkligt produktbehov. Om det bara får demon att se större ut, lämna det ute.
Undvik de här mönstren:
att börja med varje API-funktion på en gång
att dölja kreditanvändning för kontoägaren
att använda Studio-exklusiva antaganden i ett API-flöde
att behandla filuppladdningar som en eftertanke
att försöka om genereringsbegäranden utan idempotens
att använda Chat API för jobb som bör vara async-generering
att använda genereringsrutter för chatturer
att logga fullständiga API-nycklar, webhook-hemligheter eller temporära fildetaljer
Det säkraste API-arbetsflödet är tydligt med ägarskap, tillstånd och felhantering.
Börja från Utvecklare för den publika API-hubben.
Använd Rivya API-snabbstart för att köra den första begäran.
Använd API-modeller innan du väljer modell-ID:n.
Använd Files API bara när modellen verkligen behöver referensmedia.
Använd Chat API för chatturer och streamade chattsvar.
Använd API-webhooks när statuskontroller inte längre räcker och kontot har tillgång till webhooks.
Om arbetsflödet fortfarande behöver mänsklig utforskning, läs När du ska använda Rivya API i stället för Studio innan du automatiserar det.
