Rivya AI
Dziennik Rivya
Autor
Kategorie
Eksploruj dalej
Kontynuuj z powiązanymi przewodnikami, notatkami produktowymi i omówieniami przepływów pracy od zespołu Rivya.
Rivya API to kontrakt dla programistów, który pozwala używać obsługiwanych możliwości modeli Rivya we własnym produkcie, skrypcie lub procesie, gdy dostęp do Public API jest włączony we wdrożeniu i dostępny dla konta.
Nie jest to osobny produkt względem Rivya Studio. Używa tej samej granicy konta, tego samego portfela kredytów i tej samej publicznej warstwy modeli, którą użytkownicy widzą w Rivya. Różnica dotyczy tego, jak zaczyna się praca: zamiast klikać przez Studio, twoja aplikacja wysyła żądania z kluczem API.
Jeśli potrzebujesz szczegółów punktów końcowych, zacznij od Przeglądu Rivya API i Szybkiego startu Rivya API. Ten artykuł wyjaśnia na poziomie produktu, do czego służy API, gdzie się sprawdza i kiedy nie powinno być pierwszym wyborem.
Rivya API v1 pozwala uprawnionemu, zalogowanemu kontu tworzyć klucze API i wywoływać modele Rivya gotowe do API poza interfejsem WWW. Strony deweloperskie opisują wdrożony kontrakt; możliwość uruchomienia zależy od aktywnego wdrożenia, uprawnień konta i gotowości modelu.
Wdrożona powierzchnia API obejmuje:
odkrywanie modeli przez listę modeli API
asynchroniczne zadania generowania obrazów, wideo i audio
przesyłanie plików przez Files API dla modeli, które potrzebują mediów referencyjnych
odpytywanie statusu generowania za pomocą publicznych identyfikatorów zadań
sprawdzanie kredytów konta
tury Chat API, w tym opcjonalne przesyłanie strumieniowe SSE
podpisane webhooki ukończenia generowania, jeśli webhooki są włączone we wdrożeniu
wersja beta zestawu TypeScript SDK dla zespołów, które chcą gotowego klienta
Publiczny hub deweloperski to Developers. To najlepsze wejście, jeśli chcesz prowadzony przegląd, linki do ustawień API key i bezpieczny przepływ debuggera.
Studio jest użyteczne, gdy człowiek nadal wybiera modele, formułuje polecenia, przegląda wyniki i decyduje, co zrobić dalej.
API jest użyteczne, gdy decyzja zmieniła się w powtarzalny proces produktowy lub operacyjny.
Typowe przykłady, gdy dostęp do API jest włączony:
produkt chce generować warianty obrazów po tym, jak użytkownik prześle brief
proces marketingowy musi tworzyć szkice wizualne ze strukturyzowanych danych kampanii
narzędzie wewnętrzne musi wysyłać zadania wideo albo audio bez proszenia kogoś o otwarcie przeglądarki
system wsparcia albo treści chce turę modelu chatu we własnym interfejsie
usługa backendowa chce podpisanych callbacków po zakończeniu zadań generowania
W takich przypadkach Rivya API zachowuje pracę na tym samym koncie Rivya, bez tworzenia osobnego systemu rozliczeń, wyboru modeli i śledzenia statusu zadań.
API nie zastępuje każdego powodu, aby używać Rivya bezpośrednio.
Użyj Przewodnik po Rivya Studio albo publicznych powierzchni pracy, gdy:
polecenie nadal wymaga pracy i oceny człowieka
wybór modelu nie jest stabilny
twórca musi wizualnie porównać wyniki
projekt zależy od zapisanej historii i ręcznego przeglądu
zespół nie zdecydował, który format wejścia i wyjścia powinien stać się powtarzalny
Użyj API, gdy proces jest na tyle jasny, że można go zautomatyzować.
Ta granica ma znaczenie. Niejasne pytanie kreatywne zwykle najpierw należy do Studio. Znany przepływ produktowy z przewidywalnymi wejściami może przejść do API.
Myśl o API jak o sześciu połączonych częściach.
| Element | Co obsługuje | Gdzie czytać dalej |
|---|---|---|
| API keys | Dostęp server-to-server z twojego konta | Uwierzytelnianie API |
| Models | Publiczne ID modeli i informacje o gotowości | Modele API |
| Generations | Asynchroniczne zadania obrazów, wideo i audio | Utwórz generowanie |
| Files | Przesyłanie obrazów, wideo albo audio referencyjnych | Files API |
| Chat | Tury czatu bez przesyłania strumieniowego lub ze strumieniem | Chat API |
| Webhooki | Podpisane zdarzenia ukończenia zadań generowania, gdy funkcja jest włączona | Webhooki API |
Dokumentacja API jest źródłem prawdy dla kształtu żądań i odpowiedzi. Ten artykuł ma pomóc ci zdecydować, której części potrzebujesz najpierw.
Użycie API pobiera środki z tego samego portfela kredytów konta Rivya co Studio.
Oznacza to, że API nie jest anonimowym proxy modeli. Żądanie należy do konta Rivya, używa klucza API utworzonego przez to konto i podąża za tą samą produktową granicą kredytów opisaną w Kredyty API.
Dla zespołów jest to użyteczne, bo eksperymenty w Studio i użycie API pozostają w jednym modelu operacyjnym. Możesz przetestować model ręcznie, a potem przenieść powtarzalną część do integracji bez tworzenia drugiej warstwy rozliczeń.
Niektóre modele mogą działać wyłącznie na tekście. Inne potrzebują obrazu, wideo albo pliku audio jako referencji.
W integracjach API takie materiały referencyjne powinny przechodzić przez Files API. Przesłanie tworzy zarządzany rekord pliku, który można przekazać do obsługiwanych parametrów modelu.
Praktyczna reguła jest prosta:
jeśli model przyjmuje wyłącznie tekst, zacznij od punktu końcowego generowania
jeśli model potrzebuje mediów referencyjnych, najpierw prześlij plik
jeśli model chatu używa załączników obrazów, użyj Chat API i file IDs
Nie projektuj integracji wokół przesyłania plików dostępnego tylko w przeglądarce ani zapisanych sesji Studio. API ma własną publiczną granicę obsługi plików z konkretnego powodu.
Regularne odpytywanie to najprostsza pierwsza ścieżka integracji. Wyślij zadanie generowania, zapisz jego publiczny identyfikator i sprawdzaj status, aż zadanie zakończy się powodzeniem lub błędem.
Gdy webhooki są włączone we wdrożeniu, stają się przydatne wraz z dojrzewaniem integracji:
nie chcesz, aby proces roboczy odpytywał każde zadanie
aplikacja musi zaktualizować rekord po zakończeniu generowania
potrzebujesz podpisanego zdarzenia, które można bezpiecznie ponowić
nieudane zadania muszą trafiać do jasnej ścieżki odzyskiwania
Kontrakt podpisanych zdarzeń opisano w Webhookach API. Zanim oprzesz na nich projekt, potwierdź dostępność funkcji. Ogranicz odpowiedzialność odbiornika webhooków: weryfikuj podpisy, obsługuj duplikaty i nie zapisuj sekretów w logach.
Najlepszy pierwszy projekt API jest zwykle mały i konkretny.
Na przykład:
potwierdź, że dostęp do API jest włączony dla wdrożenia i konta
utwórz klucz API w ustawieniach
pobierz listę modeli
wybierz jeden model gotowy do API
wyślij jedno zadanie generowania z kluczem idempotencji
odpytuj punkt końcowy statusu
sprawdź kredyty przed i po
dopiero wtedy dodaj Files API, Chat API lub webhooki udostępniane przez wdrożenie
Ta ścieżka daje działającą integrację bez mieszania wszystkich funkcji API w pierwszym teście.
API prawdopodobnie nie jest właściwym pierwszym krokiem, gdy:
zespół nie wybrał jeszcze rodziny modeli
pożądany wynik zmienia się w każdym uruchomieniu
polecenie wymaga wyczucia i ręcznej oceny
integracja ukrywałaby użycie kredytów przed osobami, które muszą je rozumieć
produkt potrzebuje publicznego demo, zanim potrzebuje automatyzacji
W takich przypadkach zacznij od Image, Video, Audio, Chat albo AI Models. Gdy ścieżka stanie się powtarzalna, przenieś stabilną część do API.
Otwórz Developers, aby zobaczyć publiczny hub API i debugger.
Przeczytaj Szybki start Rivya API, aby wykonać pierwsze bezpieczne żądanie.
Przeczytaj Uwierzytelnianie API, zanim umieścisz klucz na serwerze.
Przeczytaj Modele API, zanim wybierzesz model IDs.
Przeczytaj Kiedy używać Rivya API zamiast Studio, jeśli granica produktowa nadal jest niejasna.
Przeczytaj Jak zbudować multimodalny proces AI z Rivya API, gdy planujesz pełną integrację obrazu, wideo, audio albo czatu.
