Szybki start

Wybierz model i endpoint w Katalogu, a następnie wyślij wymagane dane wejściowe tego endpointu. Ten przykład uruchamia zadanie generowania obrazu z tekstu Flux 2:

Zaakceptowane żądanie asynchroniczne zwraca 202 Accepted z identyfikatorem zadania (Task):

Przechowaj id razem z rekordem aplikacji. Jest to stabilny identyfikator używany do sondowania, obsługi technicznej i uzgadniania wywołań zwrotnych.

Media Input Fields to pola żądania zawierające adresy URL multimediów: pola najwyższego poziomu, których nazwy kończą się na _url lub _urls, np. image_url lub image_urls, pole url każdego elementu video_list oraz pola element_input_urls, element_input_video_urls i element_input_audio_urls każdego elementu kling_elements. callback_url to endpoint dostarczania, a nie Media Input Field. Każda wartość Media Input Field może być publicznym adresem URL HTTPS lub data URI w formacie data:<mime>;base64,<data>, do 10 MB na jeden data URI. RunAPI zapisuje każdy data URI jako tymczasowy File Upload, który wygasa po godzinie, i używa go w Task. Data URI, którego nie można zapisać, zwraca 422 z kodem błędu invalid_media_input.

Endpointy edycji GPT Image akceptują w source_image_urls wyłącznie adresy URL HTTPS. Aby wysłać lokalny obraz do tych endpointów, najpierw utwórz File Upload i przekaż zwrócony adres URL.

W przypadku plików większych niż 10 MB najpierw utwórz File Upload za pomocą POST /api/v1/files i przekaż zwrócony adres URL. File Upload typu multipart lub ze źródła URL akceptuje pliki do 50 MB. Adresy URL File Upload również wygasają po godzinie, więc dla każdego Task uruchamianego po tym czasie utwórz nowy File Upload.

Punkty końcowe tworzenia zadań przyjmują opcjonalny nagłówek Idempotency-Key z nieprzezroczystą wartością do 512 znaków. Wygeneruj jedną wartość dla każdego zadania logicznego i przechowuj ją wraz z żądaniem, dopóki nie wiesz, czy zostało przyjęte.

Jeśli przekroczenie limitu czasu lub awaria połączenia pozostawia wynik nieznany, ponów dokładnie to samo żądanie utworzenia zadania z tym samym kluczem. RunAPI zwraca oryginalne zadanie zamiast tworzyć i naliczać opłatę za drugie. Użycie klucza z innym żądaniem utworzenia zadania zwraca 409 Conflict. Wygeneruj nowy klucz dla celowo nowego zadania i nie używaj X-Client-Request-Id jako tego klucza.

Powolne synchroniczne punkty końcowe zazwyczaj utrzymują połączenie otwarte i zwracają tę samą terminalową odpowiedź co dotychczas. Żadne zmiany sondowania nie są wymagane w istniejących integracjach.

Aby celowo skrócić budżet czasu połączenia, wyślij nagłówek Prefer: wait=N. Jeśli zadanie (Task) nadal działa po upływie tego jawnego budżetu, RunAPI zwraca 202 Accepted z tym samym id zadania, nieprzejrzystym adresem URL Location do odzyskania oraz Retry-After sugerującym opóźnienie kolejnego zapytania. Podążaj dokładnie za Location zamiast samodzielnie konstruować adres URL wyniku. Ukończony wynik zadania (Task Result) zachowuje terminalny status HTTP, dozwolone nagłówki, typ treści i treść; dekoduj response.body zgodnie z response.content_type, który nie zawsze jest JSON.

Dołącz identyfikator zadania (Task) do tej samej ścieżki punktu końcowego:

Kontynuuj, dopóki status ma wartość processing. Używaj ograniczonego wycofywania między żądaniami zamiast ciągłego odpytywania. Zadanie staje się końcowe, gdy jego status wynosi completed lub failed.

Odpowiedź completed zawiera id zadania (Task), terminalny status, pola wynikowe specyficzne dla danego punktu końcowego oraz usage.cost jako kwotę float USD dla tego Task. Zachowaj potrzebny wynik i zatrzymaj odpytywanie. Zapoznaj się z dokumentacją interfejsu API danego punktu końcowego, aby poznać dokładny kształt wyniku — nie zakładaj, że każdy punkt końcowy dla mediów zwraca te same pola.

Envelopy Task dla utworzenia, processing i failed pomijają usage.

Zadania wymagające końcowego rozliczenia na podstawie multimediów pozostają w stanie processing do czasu zarejestrowania ostatecznej opłaty. Wywołanie zwrotne informujące o ukończeniu jest wysyłane dopiero po tym rozliczeniu; jego usage.cost odpowiada wartości zwracanej przez kolejne zapytania o zadanie. Brakujące dane księgowe nie są przedstawiane jako zero: zadanie pozostaje w stanie processing podczas uzgadniania tych danych. Potwierdzona opłata zerowa jest zwracana jako usage.cost: 0.

Odpowiedź failed zawiera id zadania (Task), terminalny status oraz autorski komunikat error RunAPI, jeśli jest dostępny. Zatrzymaj odpytywanie, zapisz identyfikator i błąd, a ponowną próbę podejmuj tylko wtedy, gdy aplikacja zakwalifikowała błąd jako przejściowy. Ponowna próba powoduje utworzenie nowego identyfikatora zadania (Task).

Dodaj publiczny adres HTTPS callback_url do żądania tworzenia, jeśli chcesz, aby RunAPI wysyłał zdarzenia wywołania zwrotnego opisane dla danego punktu końcowego:

Każde wywołanie zwrotne odpowiada jednemu zdarzeniu cyklu życia w dokumentacji API danego endpointu. Completed callback współdzieli usage.cost z completed odpowiedzią odpytywania; callbacki utworzenia, processing i failed pomijają usage. Terminalne wywołania zwrotne zawierają te same pola wynikowe co terminalne odpowiedzi odpytywania; niektóre endpointy wysyłają również udokumentowane wywołania zwrotne processing. Szybko zwróć pomyślną odpowiedź HTTP i utrzymuj dostępność odpytywania na potrzeby uzgadniania w przypadku opóźnionego dostarczenia lub niedostępności obsługi wywołań zwrotnych.

Przeczytaj artykuł Wywołania zwrotne, aby dowiedzieć się, jak utworzyć sekret wywołania zwrotnego, weryfikować podpisy i bezpiecznie obsługiwać ponowne próby.

Użyj POST /api/v1/vidu/image_to_video z model: "vidu-q4-image-to-video" i first_frame_image_url. Użyj POST /api/v1/vidu/reference_to_video z model: "vidu-q4-reference-to-video", niepustym prompt i uporządkowanymi 1–15 reference_image_urls. Pobierz każde zadanie za pomocą GET po jego utworzeniu ścieżka, po której następuje /:id. Ukończone zadania zawierają tablicę videos wynikowe adresy URL. Do kompletacji możesz także dostarczyć callback_url powiadomienia.

Obydwa punkty końcowe akceptują domyślnie liczbę całkowitą duration_seconds od 3 do 16 5 i output_resolution z 540p, 720p, 1080p, 2k lub 4k, domyślny 720p. audio to wartość logiczna JSON, domyślnie true; wyraźne false wyłącza generowany dźwięk. Podpowiedzi akceptują do 20 000 postacie. Monit o zamianę obrazu na wideo jest opcjonalny i dotyczy pierwszej klatki określa jego proporcje. Odniesienie do wideo akceptuje aspect_ratio z 16:9, 9:16, 1:1, 4:3 lub 3:4, domyślny 16:9 i do 3 reference_audio_urls.

Użyj publicznych adresów URL multimediów HTTP(S). Obrazy muszą mieć format JPG/JPEG, PNG lub WEBP; obraz pierwszej klatki nie może być większy niż 50 MB. Każdy dźwięk referencyjny plik musi mieć format MP3, mieć długość 3–12 sekund i nie być większy niż 50 MB. RunAPI sprawdza typy pól, schematy adresów URL i liczbę odwołań. Pokolenie dostawca sprawdza zdalny format multimediów, rozmiar i czas trwania dźwięku asynchronicznie. Nieprawidłowy nośnik może spowodować niepowodzenie zadania normalna awaria i zwrot pieniędzy.

Cennik obrazu na film. Cennik referencji na film.