AI-Videogenerierungs-API in Python integrieren: Polling, Webhooks und Kostenkontrolle

Ergebnismodus wählen

Die Videogenerierung ist im Vergleich zu den meisten API-Aufrufen langsam. Eine Anfrage, die ein paar Sekunden Video erzeugt, kann von Dutzenden Sekunden bis zu mehreren Minuten dauern, was bedeutet, dass die HTTP-Antwort auf die Aufgabenerstellung fast nie die Antwort mit dem Video ist. Bevor Sie eine Zeile Python-Code schreiben, entscheiden Sie, wie Sie die Ergebnisse abrufen. Es gibt drei praktische Modi.

Modus 1: Absenden und pollen

Sie senden eine Generierungsanfrage, erhalten sofort ein Aufgaben-Handle und rufen dann in festen Intervallen den Status-Endpunkt auf, bis die Aufgabe einen Endzustand erreicht. Dies ist der am einfachsten zu implementierende und zu debuggende Modus: Es ist gewöhnlicher Anfrage-/Antwort-Code, funktioniert hinter jeder Firewall und stellt keine Anforderungen an eingehenden Netzwerkverkehr. Der Nachteil ist eine Latenzuntergrenze – die Aktualität der Ergebnisse hängt nur von Ihrem Polling-Intervall ab – und es verschwendet Aufrufe, wenn schneller gepollt wird, als die Aufgabe voranschreitet.

Polling eignet sich für interaktive Workloads: Ein Benutzer wartet in der UI, die Aufgabe wird voraussichtlich in begrenzter Zeit abgeschlossen, und Sie möchten einen einzigen nachvollziehbaren Codepfad.

Modus 2: Webhook-Callback

Sie übermitteln die Aufgabe mit einer Callback-URL, geben die Kontrolle an den Aufrufer zurück und lassen die Plattform das Ergebnis per POST an Ihren Endpunkt senden, wenn die Aufgabe abgeschlossen ist. Dies eliminiert das Polling vollständig und liefert nahezu sofortige Benachrichtigungen. Außerdem funktioniert es weiter, wenn der Prozess, der die Aufgabe übermittelt hat, neu startet, da die Zustellung extern gesteuert wird.

Der Preis ist operativer Natur: Sie benötigen einen öffentlich erreichbaren HTTPS-Endpunkt, müssen verifizieren, dass der Callback tatsächlich vom Anbieter stammt, und müssen den Fall behandeln, dass der Callback nie ankommt – denn Netzwerke fallen aus, Endpunkte werden falsch konfiguriert, Nutzlasten gehen verloren.

Webhooks eignen sich für lang laufende oder Batch-Workloads: große Aufgabenwarteschlangen, asynchrone Pipelines und jede Situation, in der das Aufrechterhalten einer Verbindung oder eine Leerlaufschleife für mehrere Minuten Verschwendung wäre.

Modus 3: Hybrider Modus mit Fallback

Der Modus, den die meisten Produktionssysteme letztendlich verwenden: Webhooks als primäres Signal, aber mit einer langsamen periodischen Abgleichsrunde, die Aufgaben pollt, die nach Überschreiten einer Veraltungsschwelle noch als ausstehend markiert sind. Wenn ein Callback verpasst wird, fängt der Poller ihn ab. Wenn der Poller verzögert ist, kommt der Callback normalerweise zuerst an und markiert die Aufgabe als abgeschlossen.

Wählen Sie nach Workload, nicht nach Codebasis. Interaktive Endpunkte können pollen; Hintergrundwarteschlangen können Callbacks verwenden; der gemeinsame Aufgabenspeicher und die Endzustandslogik sollten für beide identisch sein, sodass die Abrufstrategie geändert werden kann, ohne den Rest des Systems zu berühren.

Client einrichten und Aufgaben übermitteln

Das Übermittlungsgerüst sollte schlank bleiben. Alles im Folgenden setzt voraus, dass es genau einen Ort für Ihren API-Schlüssel und die Basis-URL gibt sowie eine Funktion, die Prompt plus Parameter in ein Aufgaben-Handle umwandelt.

Konfiguration und Schlüsselverwaltung

Schlüssel niemals fest im Code hinterlegen. Lesen Sie sie aus Umgebungsvariablen und schlagen Sie beim Start laut fehl, wenn sie fehlen, damit Sie das Problem nicht erst bei der ersten Kundenanfrage entdecken.

import os

BASE_URL = os.environ.get("HIAPI_BASE_URL", "https://api.hiapi.ai")
API_KEY = os.environ["HIAPI_API_KEY"]  # KeyError beim Start ist beabsichtigt

Halten Sie Schlüssel aus Logs heraus. Wenn Sie Anfragen zum Debuggen protokollieren, protokollieren Sie Prompt und Parameter, aber maskieren Sie den Authorization-Header.

Einzelner Übermittlungsaufruf

Der Übermittlungsaufruf sollte nur eines tun: die von Ihnen kontrollierten Parameter validieren, die Anfrage senden und die Aufgabenkennung zurückgeben. Starten Sie darin kein Polling und laden Sie nichts herunter.

import requests

def submit_video_job(prompt: str, *, idempotency_key: str, **params) -> dict:
    payload = {"prompt": prompt, **params}
    resp = requests.post(
        f"{BASE_URL}/v1/video/generations",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
            "Idempotency-Key": idempotency_key,
        },
        json=payload,
        timeout=(5, 30),  # Verbinden, Lesen
    )
    resp.raise_for_status()
    return resp.json()

Idempotenzschlüssel sind wichtig. Wenn Ihr Übermittlungsaufruf eine Zeitüberschreitung erleidet, wissen Sie nicht wirklich, ob die Aufgabe erstellt wurde. Ein erneuter Versuch mit demselben Schlüssel ist sicher – er sendet erneut, statt doppelte Aufgaben zu erzeugen und dafür zu bezahlen.

Was sofort persistent gespeichert werden sollte

In dem Moment, in dem die Übermittlung zurückkehrt, schreiben Sie – bevor Sie irgendetwas anderes tun – eine Zeile in Ihre eigene Datenbank:

• Aufgaben-ID und Idempotenzschlüssel
• Ihre eigene interne Anfrage-ID sowie den Benutzer oder Batch, zu dem sie gehört
• Die exakten Anfrageparameter, damit Sie sie reproduzieren oder prüfen können
• Status pending und einen Zeitstempel

Wenn Ihr Prozess nach der Übermittlung, aber vor dem persistenten Speichern abstürzt, existiert die Aufgabe upstream, aber es gibt keinen lokalen Datensatz. Erst speichern, dann weitermachen – so wird Ihre Datenbank zur Quelle der Wahrheit für das, was Sie abgleichen müssen.

Ergebnisse auf die richtige Weise pollen

Polling-Schleifen lassen sich leicht schlecht schreiben. Die naive Version – eine while True-Schleife ohne Schlafphase – verbraucht Kontingent, hämmert auf die API ein und macht Ihre Logs unlesbar. Eine korrekte Schleife hat vier Eigenschaften: Intervall, Backoff, harte Obergrenze und Endzustandsprüfung.

Die Schleife

import time, random

def poll_job(job_id: str, *, max_attempts: int = 60, base: float = 2.0, cap: float = 20.0):
    for attempt in range(1, max_attempts + 1):
        resp = requests.get(
            f"{BASE_URL}/v1/video/generations/{job_id}",
            headers={"Authorization": f"Bearer {API_KEY}"},
            timeout=(5, 15),
        )
        resp.raise_for_status()
        body = resp.json()
        status = body["status"]

        if status == "succeeded":
            return body
        if status in {"failed", "cancelled"}:
            raise RuntimeError(f"Aufgabe {job_id} endete mit {status}: {body.get('error')}")

        delay = min(cap, base * (2 ** (attempt - 1)))
        time.sleep(delay + random.uniform(0, 1.0))

    raise TimeoutError(f"Aufgabe {job_id} ist nach {max_attempts} Versuchen noch ausstehend")

Warum jeder Teil wichtig ist

Backoff. Generierungsaufgaben schreiten in Phasen voran: Warteschlange, Ausführung, Rendering. In der frühen Warteschlangenphase zwanzigmal pro Sekunde zu pollen, liefert zwanzigmal dieselbe Antwort. Mit einigen Sekunden zu beginnen und bis zur Obergrenze zu verdoppeln, macht die Anzahl der Aufrufe proportional zur Aufgabendauer statt zu Ihrer Geduld.

Jitter. Zufällige Zehntelsekunden hinzuzufügen verhindert, dass jeder von Ihnen betriebene Client nach einem Deployment oder einer Wiederholungsstorm synchron pollt.

Maximale Versuche und Wall-Clock-Zeitbudget. Exponentielles Backoff ohne Obergrenze für die Versuche kann stundenlang laufen. Wählen Sie eine Obergrenze basierend auf der erwarteten ungünstigsten Aufgabendauer und behandeln Sie deren Überschreitung als Fehler, den Sie offenlegen sollten, statt als Schleife, die still weiterläuft. Verfolgen Sie außerdem die verstrichene Zeit – sobald die Intervallobergrenze greift, ist die Anzahl der Versuche allein irreführend.

Endzustandserkennung. Unterscheiden Sie klar zwischen Erfolg, Fehlschlag und Abbruch. Eine fehlgeschlagene Aufgabe sollte vom Poller nicht erneut versucht werden; sie sollte mit dem Fehlerbericht des Anbieters zurückgegeben werden, damit Sie entscheiden können, ob Sie mit anderen Parametern erneut übermitteln.

Noch eine Regel: Pollen Sie nicht innerhalb eines Web-Anfragehandlers. Verlagern Sie die Schleife in einen Hintergrund-Worker, damit langsame Aufgaben Ihren Anfrage-Thread-Pool nicht belegen.

Ergebnisse über Webhook-Callbacks empfangen

Ein Webhook-Endpunkt ist eine öffentliche, standardmäßig nicht authentifizierte HTTP-Route, an die jeder POSTen kann. Behandeln Sie ihn entsprechend.

Den Absender verifizieren

Wenn die Plattform Callbacks signiert, verifizieren Sie die Signatur über dem rohen Anfragekörper, bevor Sie das JSON parsen – die Signaturprüfung läuft über Bytes, und das erneute Serialisieren der Nutzlast kann diese verändern. Vergleichen Sie mit einer Funktion für konstante Zeit und weisen Sie Nichtübereinstimmungen mit einem Nicht-2xx-Status zurück. Wenn keine Signatur verfügbar ist, verwenden Sie zumindest ein geheimes Pfadsegment plus eine Allowlist oder ein gemeinsames Header-Token und vertrauen Sie dem Inhalt niemals, bevor Sie die Nutzlast einer von Ihnen erstellten Aufgabe zugeordnet haben.

Schnell zurückgeben, später arbeiten

Die einzige Aufgabe Ihres Endpunkts ist es, den Empfang zu bestätigen. Parsen, validieren, in die Warteschlange stellen, antworten. Alles Langsame – das Video herunterladen, die Datenbank unter einer Sperre aufrufen, nachgelagerte Dienste aufrufen – geschieht im Worker, nicht im Handler. Der Anbieter wiederholt Callbacks, die keine schnelle Erfolgsantwort erhalten haben, und ein langsamer Handler macht aus einem Ereignis mehrere.

from flask import Flask, request, abort

app = Flask(__name__)

@app.post("/callbacks/video")
def video_callback():
    raw = request.get_data()
    if not verify_signature(raw, request.headers):
        abort(401)
    event = request.get_json(force=True)
    job_id = event.get("job_id")
    if not job_id:
        abort(400)
    queue.enqueue("process_video_event", event)  # sofort zurückkehren
    return {"ok": True}, 200

Mit Ihren Datensätzen abgleichen

Bevor Sie aufgrund eines Callbacks handeln, schlagen Sie die Aufgaben-ID in Ihrer eigenen Tabelle nach. Dieser Lookup führt zu drei Fällen:

• Unbekannte Aufgaben-ID: Dies könnte ein veraltetes Ereignis einer gelöschten Aufgabe oder eine gefälschte Anfrage sein. Protokollieren und verwerfen Sie es. Erstellen Sie keine Datensätze aus eingehenden Nutzlasten.
• Aufgabe bereits als abgeschlossen markiert: Dies ist eine doppelte Zustellung. Bestätigen Sie sie, tun Sie nichts weiter. Erneutes Herunterladen und erneutes Abrechnen für dieselbe Aufgabe ist der klassische Webhook-Fehler.
• Aufgabe ausstehend: Markieren Sie sie als abgeschlossen (oder fehlgeschlagen), speichern Sie die Asset-Referenz und übergeben Sie sie an den Download-Schritt.

Machen Sie Zustandsübergänge vom aktuellen Zustand abhängig – also ein Update, das nur gelingt, wenn die Aufgabe noch ausstehend ist – damit zwei gleichzeitige Zustellungen nicht beide gewinnen können. Kombinieren Sie dies mit dem zuvor beschriebenen hybriden Poller, damit selbst dann keine Aufgabe verloren geht, wenn der Callback nie eintrifft.

Timeouts, Wiederholungen und Fehlerbehandlung

Wiederholungen sind der Ort, an dem Integrationen stillschweigend Probleme bekommen. Die folgenden Regeln gelten für Übermittlung, Polling und Callbacks, aber die sicheren Grenzen unterscheiden sich.

Fehler zuerst klassifizieren

Vorübergehend: Verbindungsabbrüche, 5xx-Antworten, Ratenbegrenzungsantworten, Lese-Timeouts. Diese können beim zweiten Versuch gelingen.

Endgültig: 4xx-Validierungsfehler, nicht unterstützte Parameter, Authentifizierungsfehler und aufgabenbezogene Fehlschläge (z. B. abgelehnter Prompt). Diese erneut zu versuchen, wiederholt nur denselben Fehlschlag und bei übermittelten Aufgaben auch die Kosten.

Prüfen Sie im Zweifel den Statuscode und den Fehlerkörper, anstatt standardmäßig alles erneut zu versuchen.

Backoff mit Jitter und harter Stopp

Verwenden Sie exponentielles Backoff mit zufälligem Jitter für vorübergehende Fehler und begrenzen Sie sowohl die Anzahl der Versuche als auch die Gesamtdauer. Eine Wiederholungsstrategie ohne Obergrenze ist ein Fehlergenerator: Wenn eine Abhängigkeit schlechter wird, vervielfacht Ihr Wiederholungsvolumen die Last genau dann, wenn sie am wenigsten verkraftbar ist.

def with_retries(fn, *, attempts: int = 4, base: float = 0.5, cap: float = 8.0):
    for i in range(attempts):
        try:
            return fn()
        except TransientError:
            if i == attempts - 1:
                raise
            delay = min(cap, base * (2 ** i))
            time.sleep(delay + random.uniform(0, delay / 2))

Idempotenz über Grenzen hinweg

• Übermittlung: Senden Sie beim erneuten Übermitteln immer denselben Idempotenzschlüssel. Dies ist der einzige sichere Weg, sich von einer Anfrage-Timeout zu erholen, bei der die Aufgabe möglicherweise bereits erstellt wurde. Erzeugen Sie den Schlüssel einmal, speichern Sie ihn zusammen mit der erwarteten Anfrage und verwenden Sie ihn wieder.
• Polling: Von Natur aus idempotent – nur lesend. Kann innerhalb Ihres Zeitbudgets frei wiederholt werden.
• Callbacks: Die Zustellung ist grundsätzlich mindestens einmal. Deduplizieren Sie nach Aufgaben-ID plus Ereignistyp und machen Sie die Zustandsübergänge des Handlers bedingt, damit doppelte Zustellungen zu No-Ops werden.

Endzustände offenlegen

Jeder Aufgabenpfad sollte schließlich genau ein Ergebnis speichern: Erfolg mit Asset-Referenz oder Fehlschlag mit Ursache und Versuchshistorie. Lassen Sie Aufgaben niemals unbegrenzt im Status pending – Ihr hybrider Poller existiert genau dafür, nach einer Veraltungsschwelle eine Entscheidung zu erzwingen. Legen Sie diesen Zustand für die Partei offen, die die Aufgabe konsumiert, damit der Upstream-Code entscheiden kann, erneut zu übermitteln, zu alarmieren oder Aufmerksamkeit zurückzugeben, anstatt ewig zu warten.

Fertige Videos herunterladen und speichern

Die URL in der Abschlussnutzlast ist temporär. Sie kann signiert sein, ablaufen, und ihr Host ist nichts, worauf sich Ihre Anwendung beim Lesen verlassen sollte. Der letzte Schritt der Integration besteht darin, das Artefakt in einen Speicher zu verschieben, den Sie kontrollieren.

Das Asset abrufen

Laden Sie mit einer Streaming-Anfrage herunter, damit große Dateien nicht als einzelnes Bytes-Objekt im Speicher landen, und setzen Sie Timeouts, die die Dateigröße widerspiegeln, nicht einen typischen API-Aufruf.

def download_asset(url: str, dest_path: str) -> None:
    with requests.get(url, stream=True, timeout=(5, 300)) as r:
        r.raise_for_status()
        with open(dest_path, "wb") as f:
            for chunk in r.iter_content(chunk_size=1 << 20):
                f.write(chunk)

Wenn Ihr Speicher-Backend Streaming-Schreibvorgänge unterstützt, übergeben Sie den Antwort-Iterator direkt daran, anstatt ihn in einer lokalen Datei zwischenzuspeichern.

Vor dem Vertrauen verifizieren

Prüfen Sie mindestens, dass der Antwortstatus erfolgreich ist, die Inhaltslänge mit einer angegebenen Größe übereinstimmt und die Dateigröße nicht trivial ist. Wenn die Abschlussnutzlast Metadaten zu Dauer oder Format enthält, prüfen Sie stichprobenartig, ob das heruntergeladene Artefakt plausibel ein Video ist und nicht eine Fehlerseite oder eine abgeschnittene Teil-Datei. Ein beschädigtes Asset, das den Benutzer erreicht, ist schlimmer als eine Aufgabe, die Sie als fehlgeschlagen markieren und erneut übermitteln.

In Ihren eigenen Speicher verschieben

Schreiben Sie das Objekt in Ihren Bucket oder CDN-Ursprung, mit einem Schlüssel, der von Ihrer internen Aufgaben-ID abgeleitet ist, und zeichnen Sie diesen Schlüssel in der Aufgabenzeile auf. Bedienen Sie Benutzer von Ihren eigenen URLs. Die Vorteile summieren sich:

• Temporäre Anbieter-URLs gelangen nie in Ihr Frontend, Ihre E-Mails oder Ihre Logs.
• Ablauf spielt keine Rolle mehr; Sie können Derivate oder Neukodierungen nach Ihrem eigenen Zeitplan neu generieren.
• Aufbewahrung, Zugriffskontrolle und Löschung werden zu Ihrer Richtlinie statt zu der des Anbieters.

Halten Sie den Download-Schritt idempotent: Wenn der Zielschlüssel bereits existiert und gültig ist, überspringen Sie den Abruf. Bei doppelten Callbacks ist genau diese Prüfung das, was einen zweiten Download und ein zweites Schreiben in den Speicher verhindert.

Generierungskosten kontrollieren

Die Generierung wird nach dem Arbeitsaufwand pro Anfrage abgerechnet – in der Regel nach Ausgabedauer oder tokenäquivalenten Einheiten, wobei der genaue Tarif im Preispaneel der Plattform angezeigt wird. Da jeder Aufruf deutlich teurer ist als eine typische Textanfrage, sollte die Kostenkontrolle am Aufrufpunkt erfolgen, nicht in einer monatlichen Überprüfung.

Parallelität begrenzen

Die wirksamste einzelne Leitplanke ist die Begrenzung der Anzahl gleichzeitiger Generierungsaufgaben. Ohne sie können Wiederholungsstürme, außer Kontrolle geratene Schleifen oder plötzliche Benutzeranfragen die Ausgaben schneller vervielfachen, als jedes Dashboard anzeigen kann. Platzieren Sie vor der Übermittlung ein Semaphor oder einen begrenzten Worker-Pool und legen Sie dessen Größe bewusst fest.

from threading import Semaphore

_submit_gate = Semaphore(5)  # an Ihr Budget und die Anbieterlimits anpassen

def guarded_submit(prompt, *, idempotency_key, **params):
    with _submit_gate:
        return submit_video_job(prompt, idempotency_key=idempotency_key, **params)

Vor dem Absenden validieren

Die meisten unbeabsichtigten Kostenüberschreitungen stammen von Anfragen, die gar nicht hätten gesendet werden sollen: Dauerparameter, die weit über dem liegen, was das Feature benötigt; Wiederholungsschleifen, die laufende Aufgaben erneut übermitteln; leere Prompts, die einen Client-Fehler auslösen. Validieren Sie die Parameter – Dauer, Auflösung, Prompt-Länge, Eingabemedien-Referenzen – bevor die Anfrage Ihren Prozess verlässt, und lehnen Sie früh mit einem klaren Fehler ab.

Aufgabenvolumen protokollieren, nicht nur Fehler

Protokollieren Sie jede Übermittlung mit ihren Parametern, der Anfragedauer, dem Benutzer und dem Idempotenzschlüssel. Zählen Sie Aufgaben pro Funktion und pro Benutzer pro Zeitraum. Aggregiertes Aufgabenvolumen ist die Metrik, mit der Sie Ausgaben wirklich verfolgen, und sie ermöglicht es Ihnen, abnormale Muster – ein Aufrufer, der zehnmal so schnell wie normal generiert – zu erkennen, solange sie noch klein sind.

Nicht zweimal für dieselbe Aufgabe bezahlen

Fehlermuster bei doppelter Generierung haben drei häufige Ursachen, jede mit einer Gegenmaßnahme:

• Übermittlungs-Timeout-Wiederholungen ohne Idempotenzschlüssel. Verwenden Sie den Schlüssel wieder.
• Webhook-Neuzustellungen, die einen neuen Download oder eine neue Aufgabe auslösen. Deduplizieren Sie nach Aufgaben-ID und machen Sie Übergänge bedingt.
• Ein Poller gibt auf und übermittelt erneut, während die ursprüngliche Aufgabe noch läuft. Prüfen Sie den Status der vorhandenen Aufgabe, bevor Sie eine Ersatzaufgabe erstellen, und verfolgen Sie Nachfolgebeziehungen in der Aufgabentabelle.

Behandeln Sie jede erneute Übermittlung als Entscheidung, die einen dokumentierten Grund erfordert, nicht als Standard-Wiederherstellungspfad.

Checkliste vor dem Go-Live

Bevor die Integration live geht, validieren Sie diese Entscheidungen und Fehlermuster Ende-zu-Ende.

Abruf und Lebenszyklus

• Der Abrufmodus wird nach Workload gewählt, mit hybridem Fallback, damit verpasste Callbacks keine Aufgaben verlieren.
• Nach der Übermittlung wird die Aufgabenzeile vor jedem anderen Seiteneffekt geschrieben, mit Parametern, Idempotenzschlüssel und Eigentümer.
• Jede Aufgabe erreicht genau einen Endzustand; eine Veraltungsschwelle erzwingt eine Entscheidung für alles, was noch ausstehend ist.
• Zustandsübergänge sind vom aktuellen Zustand abhängig, sodass doppelte Zustellungen und gleichzeitiges Polling harmlos sind.

Netzwerkverhalten

• Jede Anfrage hat Verbindungs- und Lese-Timeouts, einschließlich Downloads.
• Vorübergehende und endgültige Fehler werden klassifiziert, nur vorübergehende werden erneut versucht.
• Wiederholungen verwenden exponentielles Backoff mit Jitter und harten Obergrenzen für Versuche und verstrichene Zeit.
• Das Polling-Backoff hat sowohl eine Intervallobergrenze als auch ein Wall-Clock-Zeitbudget, und die Polling-Schleife läuft im Worker statt im Anfragehandler.

Callback und Speicher

• Der Callback-Endpunkt verifiziert den Absender anhand des rohen Körpers, gibt schnell zurück und stellt die Arbeit in die Warteschlange.
• Jeder Callback wird vor jeder Aktion mit Ihren eigenen Aufgabenaufzeichnungen abgeglichen.
• Abgeschlossene Assets werden per Streaming in Ihren eigenen Speicher übertragen, verifiziert und nur von Ihren URLs bereitgestellt; der Download-Schritt ist idempotent.

Kosten und Betrieb

• Übermittlungen werden durch Parallelitätslimits und Parameterprüfung für Dauer, Auflösung und Eingaben kontrolliert.
• Aufgabenvolumen wird pro Funktion und pro Benutzer protokolliert, sodass Ausgaben als Trend sichtbar werden statt als Überraschung.
• Pfade für doppelte Generierung – Übermittlungswiederholungen, Webhook-Neuzustellungen, Poller-Neuübermittlungen – werden alle explizit behandelt.
• Es gibt Warnungen für Aufgaben, die über eine Schwelle hinaus ausstehend bleiben, und für Situationen, die kontinuierlich das Parallelitätslimit erreichen.

Führen Sie eine echte Aufgabe durch jeden Pfad aus – Erfolg, Fehlschlag, verpasster Callback, doppelter Callback – und bestätigen Sie, dass Endzustände, Speicherschreibvorgänge und Zähler korrekt aussehen. Wenn jeder der obigen Punkte in dieser Übung standhält, ist die Integration bereit für den Go-Live mit der HiAPI.ai-Videogenerierungs-API.