Vad är Rivya API?

Rivya API är utvecklarkontraktet för att använda de Rivya-modellfunktioner som stöds från din egen produkt, ditt skript eller ditt arbetsflöde. Det förutsätter att det offentliga API:et är aktiverat för driftsmiljön och tillgängligt för kontot.

Det är inte en separat produkt från Rivya Studio. Det använder samma kontogräns, samma kreditplånbok och samma publika modellager som användare ser i Rivya. Skillnaden är hur arbetet startar: i stället för att klicka genom Studio skickar din applikation begäranden med en API-nyckel.

Om du behöver detaljer om API-rutterna, börja med Rivya API-översikt och Rivya API-snabbstart. Den här artikeln förklarar på produktnivå vad API:et är till för, var det passar och när det inte bör vara förstahandsvalet.

Den korta versionen

Rivya API v1 låter ett behörigt, inloggat konto skapa API-nycklar och anropa API-redo Rivya-modellfunktioner utanför webbgränssnittet. Utvecklarsidorna beskriver det implementerade kontraktet; om en begäran kan köras avgörs av den aktiva driftsmiljön, kontots behörigheter och modellens aktuella beredskap.

Den implementerade API-ytan innehåller:

• modellupptäckt genom API-modellistan

• asynkrona genereringsjobb för bild, video och ljud

• Files API-uppladdningar för modeller som behöver referensmedia

• regelbundna statuskontroller med publika uppgifts-ID:n

• kontroll av kontots krediter

• Chat API-turer, inklusive valfri SSE-streaming

• signerade webhooks för slutförd generering när webhooks är aktiverade för driftsmiljön

• en betaversion av TypeScript SDK för team som vill ha en färdig klient

Den publika utvecklarhubben är Utvecklare. Den är bästa ingången om du vill ha en guidad översikt, länkar till API-nyckelinställningar och ett säkert felsökningsflöde.

Varför Rivya har ett API

Studio är användbart när en person fortfarande väljer modeller, formar prompter, granskar resultat och bestämmer vad som ska hända härnäst.

API:et är användbart när det beslutet har blivit en upprepbar produkt eller ett operativt arbetsflöde.

När API-åtkomst är aktiverad är vanliga exempel:

• en produkt vill generera bildvarianter efter att en användare skickar in en uppdragsbeskrivning

• ett marknadsföringsarbetsflöde behöver skapa visuella utkast från strukturerade kampanjindata

• ett internt verktyg behöver skicka video- eller audiojobb utan att be någon öppna webbläsaren

• ett support- eller innehållssystem vill använda en chattmodell i sitt eget gränssnitt

• en bakgrundstjänst vill ha signerade återanrop när genereringsjobben är klara

I de fallen håller Rivya API arbetet kopplat till samma Rivya-konto i stället för att kräva en separat teknisk lösning för fakturering, modellval och uppgiftsstatus.

Vad API:et inte ersätter

API:et ersätter inte alla skäl att använda Rivya direkt.

Använd Studio eller de publika arbetsytorna när:

• prompten fortfarande behöver mänsklig utforskning

• modellvalet inte är stabilt

• en kreatör behöver jämföra resultat visuellt

• projektet beror på sparad historik och manuell granskning

• teamet inte har bestämt vilket indata- och resultatformat som ska bli upprepbart

Använd API:et när arbetsflödet är tillräckligt tydligt för att automatiseras.

Den gränsen spelar roll. En vag kreativ fråga hör oftast hemma i Studio först. Ett känt produktflöde med förutsägbara indata kan flytta till API:et.

De viktigaste byggblocken

Tänk på API:et som sex sammankopplade delar.

API-dokumentationen är källan för formatet för begäran och svar. Den här artikeln ska hjälpa dig att avgöra vilken del du behöver först.

Så fungerar krediterna

API-användning drar krediter från samma Rivya-konto som Studio.

Det betyder att API:et inte är en anonym mellanhand för modeller. En begäran hör till ett Rivya-konto, använder en API-nyckel som kontot har skapat och följer samma kreditgräns som beskrivs i API-krediter.

Det är användbart för team eftersom Studio-försök och API-användning stannar i en och samma operativa modell. Du kan prova en modell manuellt och sedan flytta den upprepbara delen till en integration utan att skapa ett andra faktureringslager.

Hur filer passar in

Vissa modeller kan köras från enbart text. Andra behöver en referensbild, video eller ljudfil.

För API-integrationer bör dessa referenser gå genom Files API. Uppladdningen skapar en hanterad filpost som kan skickas in i stödda modellparametrar.

Den praktiska regeln är enkel:

• om en modell accepterar enbart textindata, börja med genereringsrutten

• om en modell behöver referensmedia, ladda upp filen först

• om modellen är en chattmodell med bildbilagor, använd Chat API och fil-ID:n

Designa inte integrationen runt uppladdningsflöden som bara fungerar i webbläsaren eller sparade Studio-sessioner. API:et har en egen publik filgräns av en anledning.

Där webhooks hjälper

Regelbundna statuskontroller är den enklaste vägen för en första integration. Skicka ett genereringsjobb, spara det publika uppgifts-ID:t och kontrollera statusen tills jobbet lyckas eller misslyckas.

När webhooks är aktiverade för driftsmiljön blir de användbara allt eftersom integrationen närmar sig produktion:

• du vill inte ha en bakgrundsprocess som kontrollerar varje jobb hela tiden

• din app behöver uppdatera en post när genereringen är klar

• du vill ha en signerad händelse som kan försöka igen säkert

• misslyckade jobb behöver flytta till en tydlig återställningsväg

Använd API Webhooks för kontraktet för signerade händelser. Kontrollera att funktionen är tillgänglig innan du utformar lösningen kring den. Håll webhook-mottagaren smal: verifiera signaturer, hantera dubbletthändelser och undvik att lägga hemliga värden i loggar.

Ett bra första API-projekt

Det bästa första API-projektet är oftast litet och konkret.

Till exempel:

1. kontrollera att API-åtkomst är aktiverad för driftsmiljön och kontot

2. skapa en API-nyckel i inställningar

3. anropa modellistan

4. välj en API-redo modell

5. skicka ett genereringsjobb med en idempotensnyckel

6. kontrollera statusrutten

7. kontrollera krediter före och efter

8. lägg först därefter till de Files API-, Chat API- eller Webhook-funktioner som driftsmiljön exponerar

Den vägen ger dig en fungerande integration utan att blanda in varje API-funktion i första testet.

När API:et är fel startpunkt

API:et är troligen inte rätt första steg när:

• teamet ännu inte har valt en modellfamilj

• önskad resultat fortfarande ändras vid varje körning

• prompten beror på manuell smak och granskning

• integrationen skulle dölja kreditanvändning för personerna som behöver förstå den

• produkten behöver en publik demo innan den behöver automatisering

I de fallen börjar du med Bild, Video, Ljud, Chat eller AI-modeller. När vägen är upprepbar flyttar du den stabila delen till API:et.

Vart du går härnäst

• Öppna Utvecklare för den publika API-hubben och felsökaren.

• Läs Rivya API-snabbstart för att göra den första säkra begäran.

• Läs API-autentisering innan du lägger en nyckel på en server.

• Läs API-modeller innan du väljer modell-ID:n.

• Läs När du ska använda Rivya API i stället för Studio om produktgränsen fortfarande är oklar.

• Läs Så bygger du ett multimodalt AI-arbetsflöde med Rivya API när du planerar en full bild-, video-, ljud- eller chattintegration.