Schnellstart

Wählen Sie ein Modell und einen Endpunkt im Catalog, senden Sie dann die erforderlichen Eingaben des Endpunkts. Dieses Beispiel startet einen Flux 2 Text-to-Image-Task:

Eine akzeptierte asynchrone Anfrage gibt 202 Accepted mit einem Task-Bezeichner zurück:

Speichern Sie id zusammen mit Ihrem Anwendungsdatensatz. Es ist der stabile Bezeichner für Polling, Support und Callback-Abgleich.

Media Input Fields sind die Anfragefelder, die Medien-URLs enthalten: Felder auf oberster Ebene, deren Namen auf _url oder _urls enden, zum Beispiel image_url oder image_urls, die url jedes video_list-Elements sowie element_input_urls, element_input_video_urls und element_input_audio_urls jedes kling_elements-Elements. callback_url ist ein Zustellendpunkt und kein Media Input Field. Jeder Wert eines Media Input Field kann eine öffentliche HTTPS-URL oder eine Data-URI im Format data:<mime>;base64,<data> sein, mit bis zu 10 MB pro Data-URI. RunAPI speichert jede Data-URI als temporären File Upload, der nach einer Stunde abläuft, und verwendet diesen Upload für den Task. Eine Data-URI, die nicht gespeichert werden kann, gibt 422 mit dem Fehlercode invalid_media_input zurück.

GPT-Image-Bearbeitungsendpunkte akzeptieren in source_image_urls nur HTTPS-URLs. Um ein lokales Bild an diese Endpunkte zu senden, erstellen Sie zuerst einen File Upload und übergeben die zurückgegebene URL.

Für Dateien über 10 MB erstellen Sie zuerst mit POST /api/v1/files einen File Upload und übergeben die zurückgegebene URL. Ein File Upload per Multipart oder URL-Quelle akzeptiert Dateien bis 50 MB. File-Upload-URLs laufen ebenfalls nach einer Stunde ab. Erstellen Sie daher für jeden Task, der nach diesem Zeitraum startet, einen neuen File Upload.

Task-Erstellungsendpunkte akzeptieren einen optionalen Idempotency-Key-Header mit einem undurchsichtigen Wert von bis zu 512 Zeichen. Generieren Sie einen Wert für jede logische Task und behalten Sie ihn bei der Anfrage, bis Sie wissen, ob sie akzeptiert wurde.

Wenn ein Timeout oder ein Verbindungsfehler das Ergebnis unbekannt lässt, wiederholen Sie dieselbe Task-Erstellungsanfrage mit demselben Schlüssel. RunAPI gibt den ursprünglichen Task zurück, anstatt einen zweiten zu erstellen und dafür zu berechnen. Die Wiederverwendung eines Schlüssels mit einer anderen Task-Erstellungsanfrage gibt 409 Conflict zurück. Generieren Sie einen neuen Schlüssel für einen absichtlich neuen Task und verwenden Sie X-Client-Request-Id nicht als diesen Schlüssel.

Langsame synchrone Endpunkte halten die Verbindung in der Regel offen und geben dieselbe terminale Antwort wie zuvor zurück. Für bestehende Integrationen sind keine Polling-Änderungen erforderlich.

Für ein absichtlich kürzeres Verbindungsbudget senden Sie Prefer: wait=N. Wenn der Task nach diesem expliziten Budget noch läuft, gibt RunAPI 202 Accepted mit derselben Task-id, einer undurchsichtigen Location-URL zur Wiederherstellung und Retry-After für die empfohlene Abfrageverzögerung zurück. Folgen Sie Location exakt, anstatt eine Ergebnis-URL zu konstruieren. Ein abgeschlossenes Task-Ergebnis bewahrt den abschließenden HTTP-Status, erlaubte Header, den Inhaltstyp und den Body; dekodieren Sie response.body gemäß response.content_type, was nicht immer JSON ist.

Hängen Sie den Task-Bezeichner an denselben Endpunktpfad an:

Fortfahren, solange status den Wert processing hat. Verwenden Sie begrenztes Backoff zwischen Anfragen statt kontinuierlichem Polling. Ein Task wird terminal, wenn sein Status completed oder failed ist.

Eine completed-Antwort enthält die Task-id, den terminalen status, die endpunktspezifischen Ergebnisfelder und usage.cost als float-USD-Betrag für diese Task. Speichern Sie das benötigte Ergebnis und beenden Sie das Polling. Entnehmen Sie die genaue Ergebnisstruktur der API-Referenz des Endpunkts, anstatt davon auszugehen, dass jeder Medienendpunkt dieselben Felder zurückgibt.

Create-, processing- und failed-Task-Envelopes lassen usage weg.

Tasks, die eine medienbasierte Endabrechnung erfordern, bleiben im Status processing, bis ihr endgültiger Abrechnungsbetrag erfasst ist. Der Abschluss-Callback wird erst nach dieser Abrechnung gesendet; sein usage.cost stimmt mit späteren Task-Abfragen überein. Fehlende Abrechnungsdaten werden nicht als null ausgewiesen: Die Task bleibt im Status processing, während diese Daten abgeglichen werden. Ein bestätigter Abrechnungsbetrag von null wird als usage.cost: 0 zurückgegeben.

Eine failed-Antwort enthält die Task-id, den terminalen status und einen von RunAPI verfassten error, sofern vorhanden. Beenden Sie das Polling, notieren Sie Bezeichner und Fehler, und wiederholen Sie den Vorgang nur, wenn Ihre Anwendung den Fehler als vorübergehend eingestuft hat. Ein erneuter Versuch erstellt einen neuen Task-Bezeichner.

Fügen Sie der Erstellungsanfrage eine öffentliche HTTPS-callback_url hinzu, wenn RunAPI die für diesen Endpunkt dokumentierten Callback-Ereignisse senden soll:

Jeder Callback-Body entspricht einem Lebenszyklusereignis in der API-Referenz des Endpunkts. Ein completed-Callback teilt usage.cost mit der completed-Polling-Antwort; Create-, Processing- und Failed-Callbacks lassen usage weg. Abschließende Callbacks enthalten dieselben Ergebnisfelder wie abschließende Abrufantworten; einige Endpunkte senden auch dokumentierte processing-Callbacks. Geben Sie schnell eine erfolgreiche HTTP-Antwort zurück und halten Sie Polling für den Abgleich bereit, wenn die Zustellung verzögert ist oder Ihr Callback-Handler nicht verfügbar ist.

Lesen Sie Callbacks, um einen Callback-Secret zu erstellen, Signaturen zu verifizieren und Wiederholungsversuche sicher zu behandeln.

Verwenden Sie POST /api/v1/vidu/image_to_video mit model: "vidu-q4-image-to-video" und first_frame_image_url. Verwenden Sie POST /api/v1/vidu/reference_to_video mit model: "vidu-q4-reference-to-video", einem nicht leeren prompt und der Reihenfolge 1–15 reference_image_urls. Rufen Sie jede Aufgabe bei ihrer Erstellung mit GET ab Pfad gefolgt von /:id. Abgeschlossene Aufgaben enthalten ein videos-Array von Ergebnis-URLs. Sie können auch callback_url zur Vervollständigung bereitstellen Benachrichtigungen.

Beide Endpunkte akzeptieren standardmäßig Ganzzahlen duration_seconds von 3 bis 16 5 und output_resolution von 540p, 720p, 1080p, 2k oder 4k, Standard 720p. audio ist ein boolescher JSON-Wert, standardmäßig ist true; explizit false deaktiviert generiertes Audio. Eingabeaufforderungen akzeptieren bis zu 20.000 Charaktere. Die Bild-zu-Video-Eingabeaufforderung ist optional und das erste Bild bestimmt das Seitenverhältnis. Referenz-zu-Video akzeptiert aspect_ratio von 16:9, 9:16, 1:1, 4:3 oder 3:4, Standard 16:9 und bis zu 3 reference_audio_urls.

Verwenden Sie öffentliche HTTP(S)-Medien-URLs. Bilder müssen JPG/JPEG, PNG oder WEBP sein; Das Bild des ersten Frames darf nicht größer als 50 MB sein. Jedes Referenzaudio Die Datei muss MP3 sein, 3–12 Sekunden lang und darf nicht größer als 50 MB sein. RunAPI prüft Feldtypen, URL-Schemata und Referenzanzahlen. Die Generation Der Anbieter überprüft das Format, die Größe und die Audiodauer der Remote-Medien asynchron. Ungültige Medien können dazu führen, dass die Aufgabe fehlschlägt normaler Fehler- und Rückerstattungsfluss.

Preise für Bild zu Video. Preise für Referenzen zu Video.