Aufträge abfragen und alle nutzbaren Ausgaben herunterladen
Behandle asynchrone Zustände, Credit-Abrechnung, Teilergebnisse, Abbruch und ablaufende Asset-URLs ohne Zugangsdaten offenzulegen.
Auf dieser Seite
Eine Erstellungsantwort ist keine fertige Animation
POST /animations liefert HTTP 202 mit Auftrags-ID und Retry-After. Speichere zuerst diese ID. Die Aufnahme in die Warteschlange beweist keine abgeschlossene Produktion.
Frage GET /animations/{id} ab. Bevorzuge das serverseitige Retry-After, derzeit typischerweise fünf Sekunden, ergänze begrenztes Backoff bei vorübergehenden Fehlern und eine Gesamtfrist. Erstelle wegen langsamer Abfragen keinen weiteren Auftrag. Der öffentliche Ablauf basiert derzeit auf Polling, nicht Webhooks.
Zustände und Phasen
| Zustand | Verhalten des Clients |
|---|---|
queued |
Warten; ein Worker hat den Auftrag noch nicht abgeschlossen |
running |
Weiter abfragen, Phase und Fortschritt prüfen |
cancelling |
Abbruch angefordert, noch nicht endgültig; weiter abfragen |
succeeded |
Endzustand; Ausgaben prüfen und herunterladen |
failed |
Endzustand; Fehler und vorhandene Ausgaben prüfen |
cancelled |
Endzustand; fertige Ausgaben und Abrechnung prüfen |
stage nennt gegebenenfalls video_generation oder animation_export. progress liegt zwischen 0 und 1 und ist keine garantierte Zeitprognose. Zwischen Abfragen können Zustände übersprungen erscheinen.
credits.quoted, credits.held und credits.charged beschreiben unterschiedliche Buchungszustände. Der erste Kostenvoranschlag ist nicht zwingend die Endbelastung; addiere die drei Werte nicht.
Teilergebnisse sind wichtig
Ein Ein-Aufruf-Auftrag kann ein brauchbares Quellvideo erzeugen und erst beim Export scheitern. Lies im Endzustand immer outputs, auch wenn status nicht succeeded ist.
Lade jedes verfügbare Asset, dokumentiere Fehler und fehlende Formate und melde Teilerfolg korrekt. Wiederhole nur die nötige Operation: Ein vorhandenes Quellvideo lässt sich über /animation-exports exportieren, ohne Bewegung neu zu generieren.
Sicher herunterladen
Jedes Asset hat id, format, mime_type, byte_size, download_url und download_expires_at.
- Speichere Auftrags- oder Asset-ID als dauerhaften Anwendungszustand.
- Lade die Bytes über die zurückgegebene signierte URL.
- Sende keinen API-Bearer-Header an die signierte URL oder einen weitergeleiteten Speicherhost.
- Speichere unter einem von deiner Anwendung gewählten Namen und prüfe den vollständigen Download.
- Bei Ablauf fordere über
GET /assets/{asset_id}mit API-Schlüssel einen neuen Link an.
Links sind gewöhnlich kurzlebig; nutze download_expires_at statt einer festen Lebensdauer. Eine Asset-Abfrage stellt keine gemäß Speicher-/Aufbewahrungsregeln nicht mehr verfügbare Datei wieder her.
Behandle signierte URLs als temporäre Zugangsdaten. Veröffentliche sie nicht in Logs, Analyse, Fehlertrackern oder KI-Chatprotokollen.
Abbruch
Nutze POST /animations/{id}/cancel für einen eigenen Auftrag. Abbruch erfolgt nach bestem Bemühen und kann einen Zwischenzustand liefern. Frage bis zum Endzustand ab; Fertigstellung kann einem Abbruch zuvorkommen.
Bereits ausgeführte Produktion kann berechnet bleiben. Ungenutzte Reservierungen können freigegeben werden. Prüfe die tatsächliche Abrechnung statt volle Erstattung zu versprechen.
Vor dem Export prüfen: zweistufiger Ablauf
Erstelle über POST /video-generations und frage GET /video-generations/{id} ab, um das Video-Asset zu erhalten. Nach Prüfung erstelle mit source_video_asset_id, Auswahl und Einstellungen über POST /animation-exports einen Export und frage GET /animation-exports/{id} ab.
Kalkuliere jede neue kostenpflichtige Erstellung und verwende einen Idempotenzschlüssel. Asset-ID und Auftrags-ID sind unterschiedliche Ressourcen und nicht austauschbar. Das Schnellstartbeispiel zeigt den einfacheren Ein-Aufruf-Lebenszyklus.
War diese Seite hilfreich?
Es werden keine Suchbegriffe, Codes oder Freitexte erfasst. Dieser Schalter steuert nur Dokumentationsinteraktionen; allgemeine Website-Analysen folgen der Datenschutzerklärung. Datenschutzerklärung