Hva er Rivya API?

Rivya API er utviklerkontrakten for å bruke støttede Rivya-modellfunksjoner fra ditt eget produkt, skript eller din egen arbeidsflyt når Public API-tilgang er aktivert for distribusjonen og tilgjengelig for kontoen.

Det er ikke et separat produkt fra Rivya Studio. Det bruker samme kontogrense, samme kredittsaldo og samme offentlige modellag som brukere ser på tvers av Rivya. Forskjellen er hvordan arbeidet starter: I stedet for å klikke deg gjennom Studio sender applikasjonen forespørsler med en API-nøkkel.

Hvis du trenger detaljer om endepunktene, starter du med Oversikt over Rivya API og Hurtigstart for Rivya API. Denne artikkelen forklarer produktnivået: hva API-et brukes til, hvor det passer og når det ikke bør være førstevalg.

Den korte versjonen

Rivya API v1 lar en kvalifisert innlogget konto opprette API-nøkler og kalle API-klare Rivya-modellfunksjoner utenfor nettgrensesnittet. Utviklersidene beskriver den implementerte kontrakten. Den aktive distribusjonen, kontotillatelsene og modellens klargjøring avgjør om en forespørsel kan kjøres.

Den implementerte API-flaten omfatter:

• modelloppdagelse gjennom API-modellisten

• asynkrone genereringsjobber for bilde, video og lyd

• opplastinger gjennom Fil-API for modeller som trenger referansemedier

• regelmessig statusspørring med offentlige oppgave-ID-er

• kontroll av kontocredits

• Chat API-runder, inkludert valgfri SSE-strømming

• signerte webhooks ved fullføring av generering når webhooks er aktivert for distribusjonen

• en TypeScript SDK-beta for team som vil ha et klientbibliotek

Det offentlige utviklerområdet er Utviklere. Det er den beste inngangen hvis du vil ha en veiledet oversikt, lenker til innstillinger for API-nøkler og en trygg feilsøkingsflyt.

Hvorfor Rivya har et API

Studio er nyttig når en person fortsatt velger modeller, former prompter, gjennomgår outputer og bestemmer hva som skal skje videre.

API-et er nyttig når den beslutningen har blitt til en repeterbar produkt- eller operasjonell arbeidsflyt.

Vanlige eksempler når API-tilgang er aktivert, er:

• et produkt skal generere bildevarianter etter at en bruker sender inn en oppdragsbeskrivelse

• en markedsføringsarbeidsflyt må lage visuelle utkast fra strukturerte kampanjeinputer

• et internt verktøy må sende inn video- eller lydjobber uten å be noen åpne nettleseren

• et support- eller innholdssystem vil ha en chatmodellrunde inne i sitt eget grensesnitt

• en serversidetjeneste vil ha signerte tilbakekall når genereringsoppgaver er ferdige

I slike tilfeller holder Rivya API arbeidet koblet til samme Rivya-konto i stedet for å tvinge frem en separat stack for fakturering, modellvalg og oppgavestatus.

Hva API-et ikke erstatter

API-et erstatter ikke alle grunner til å bruke Rivya direkte.

Bruk Studio eller de offentlige arbeidsflatene når:

• prompten fortsatt trenger menneskelig utforsking

• modellvalget ikke er stabilt

• en kreatør må sammenligne outputer visuelt

• prosjektet avhenger av lagret historikk og manuell gjennomgang

• teamet ikke har bestemt hvilket inndata- og resultatformat som bør kunne gjentas

Bruk API-et når arbeidsflyten er tydelig nok til å automatiseres.

Den grensen betyr noe. Et vagt kreativt spørsmål hører vanligvis hjemme i Studio først. En kjent produktflyt med forutsigbare inputer kan flyttes til API-et.

De viktigste byggeklossene

Tenk på API-et som seks koblede deler.

API-dokumentasjonen er kilden for request- og response-form. Denne artikkelen skal hjelpe deg å avgjøre hvilken del du trenger først.

Slik fungerer kreditter

API-bruk trekker fra den samme kredittsaldoen på Rivya-kontoen som Studio.

Det betyr at API-et ikke er en anonym modellmellomtjener. En forespørsel tilhører en Rivya-konto, bruker en API-nøkkel opprettet av den kontoen og følger samme kredittgrenser på produktnivå som beskrives i API-kreditter.

Dette er nyttig for team fordi Studio-eksperimenter og API-bruk blir værende i én operasjonell modell. Du kan teste en modell manuelt og deretter flytte den repeterbare delen inn i en integrasjon uten å lage et ekstra faktureringslag.

Hvordan filer passer inn

Noen modeller kan kjøre fra tekst alene. Andre trenger et referansebilde, en video eller en lydfil.

For API-integrasjoner bør disse referansene gå gjennom Fil-API. Opplastingen oppretter en administrert filoppføring som kan sendes inn i støttede modellparametere.

Den praktiske regelen er enkel:

• hvis en modell bare aksepterer tekstinndata, starter du med genereringsendepunktet

• hvis en modell trenger referansemedier, last opp filen først

• hvis modellen er en chatmodell med bildevedlegg, bruk Chat API og file IDs

Ikke design integrasjonen rundt browser-only opplastingsflyter eller lagrede Studio-sesjoner. API-et har sin egen offentlige filgrense av en grunn.

Der webhooks hjelper

Regelmessig statusspørring er den enkleste første integrasjonsstien. Send inn en genereringsoppgave, lagre den offentlige oppgave-ID-en og spør etter status til oppgaven lykkes eller mislykkes.

Når webhooks er aktivert for distribusjonen, blir de nyttige etter hvert som integrasjonen får mer produksjonspreg:

• du vil ikke ha en bakgrunnsprosess som spør etter status for hver oppgave

• appen din må oppdatere en oppføring når genereringen er ferdig

• du vil ha en signert hendelse som kan prøves trygt igjen

• feilede jobber må flyttes inn i en tydelig recovery-sti

Bruk API Webhooks for kontrakten for signerte hendelser. Bekreft at funksjonen er tilgjengelig før du bygger løsningen rundt den. Hold webhook-mottakeren smal: verifiser signaturer, håndter dupliserte hendelser og unngå å skrive hemmelige verdier i logger.

Et godt første API-prosjekt

Det beste første API-prosjektet er vanligvis lite og konkret.

For eksempel:

1. bekreft at API-tilgang er aktivert for distribusjonen og kontoen

2. opprett en API-nøkkel i innstillingene

3. hent modellisten

4. velg en API-klar modell

5. send inn én genereringsoppgave med en idempotensnøkkel

6. kontroller statusendepunktet med jevne mellomrom

7. sjekk kreditter før og etter

8. legg først deretter til Fil-API, Chat API eller webhooker som distribusjonen tilbyr

Den stien gir deg en fungerende integrasjon uten å blande alle API-funksjoner inn i første test.

Når API-et er feil startpunkt

API-et er sannsynligvis ikke riktig første steg når:

• teamet ennå ikke har valgt en modellfamilie

• ønsket resultat fortsatt endrer seg for hver kjøring

• prompten avhenger av manuell smak og gjennomgang

• integrasjonen ville skjule kredittbruk for dem som må forstå den

• produktet trenger en offentlig demo før det trenger automatisering

I slike tilfeller starter du fra Image, Video, Audio, Chat eller AI Models. Når stien er repeterbar, flytter du den stabile delen til API-et.

Hvor du går videre

• Åpne Developers for den offentlige API-huben og debuggeren.

• Les Rivya API Quickstart for å gjøre den første trygge forespørselen.

• Les API-autentisering før du legger en nøkkel på en server.

• Les API-modeller før du velger modell-ID-er.

• Les Når du bør bruke Rivya API i stedet for Studio hvis produktgrensen fortsatt er uklar.

• Les Slik bygger du en multimodal AI-arbeidsflyt med Rivya API når du planlegger en full bilde-, video-, lyd- eller chatintegrasjon.