API-Integration

Video-Translation-API für Multi-Region-Release-Operations

Lokalisieren Sie ein Quellvideo in mehrere marktreife Ausgaben mit statusgesteuerter Automatisierung, Fehlerisolierung auf Locale-Ebene und kontrollierten Rollout-Workflows.

Problem

Globale Launches scheitern oft an der Synchronisation, nicht an der Übersetzungsqualität: Die Primärsprache wird zuerst veröffentlicht, während regionale Varianten hinterherhinken und das Kampagnen-Timing bricht.

Ergebnis mit Ssemble

Ssemble ermöglicht Source-once-, Localize-many-Operationen mit Locale-spezifischer Zustandsverfolgung, sodass Teams in kontrollierten Wellen releasen und partielle Fehler schnell beheben können.

Wesentliches zur Implementierung

Base URL: https://aiclipping.ssemble.com/api/v1

Integrationsarchitektur (Ingest → Verarbeitung → Poll/Webhook → Veröffentlichung)

1) Ingest

Erstellen Sie ein Translation-Manifest: Source, Locale-Liste, Rollout-Policy und Fallback-Verhalten.

2) Verarbeitung

Senden Sie Locale-spezifische Create-Requests und persistieren Sie eine übergeordnete Release-ID für durchgängige Nachvollziehbarkeit.

3) Poll / Webhook

Verfolgen Sie jeden Locale-Zustand unabhängig, um Szenarien mit Teilerfolg und Teilausfall schnell zu erkennen.

4) Veröffentlichung

Releasen Sie Locales, die die QA-/Policy-Gates bestehen, und stellen Sie fehlgeschlagene Locales mit begrenzter Retry-Strategie erneut in die Queue.

Endpoint-Beispiele

POST /shorts/create— Locale-spezifische Verarbeitungsjobs erstellen
GET /shorts/:id/status— Lifecycle-Zustand jeder Locale verfolgen
GET /shorts/:id— Fertige lokalisierte Ausgabe für das Release abrufen

Hinweise zur Authentifizierung

Halten Sie API-Keys und Rollout-Kontrollen ausschließlich in Backend-Services. Segmentieren Sie Schlüssel pro Umgebung und beschränken Sie den Zugriff auf Produktions-Rollouts eng.

Rate Limits und Retries

Reihen Sie Locale-Submissions in kontrollierten Batches ein, nicht als vollständige Fan-out-Bursts. Verwenden Sie exponential Backoff bei 429/5xx und begrenzen Sie Retries.

Request-Beispiel

POST /shorts/create
{
  "fileUrl": "https://cdn.example.com/master-campaign.mp4",
  "start": 30,
  "end": 420,
  "language": "ko",
  "captionLanguage": "ja",
  "preferredLength": "under60sec",
  "layout": "auto"
}

Response-Beispiel

200 OK
{
  "data": {
    "requestId": "665a1b2c3d4e5f6a7b8c9d0e",
    "status": "processing",
    "creditsUsed": 1,
    "estimatedCompletionTime": "2026-03-10T07:00:00.000Z"
  }
}

Beispiel für ein Fehlerszenario

500 Internal Server Error
{
  "error": {
    "code": "internal_error",
    "message": "An internal error occurred. Please try again.",
    "details": null
  }
}

Versionierung

Erfassen Sie Schema-/Versionsmetadaten für jeden Locale-Request, damit Regressionen über Locales hinweg nach API-Änderungen diagnostizierbar sind.

Support

Persistieren Sie bei jedem Statusübergang die übergeordnete Release-ID + Locale + requestId für eine schnelle Incident-Recovery bei Teil-Launches.

Quickstart

Definieren Sie die Locale-Matrix und die Rollout-Strategie in der Backend-Konfiguration.
Erstellen Sie einen Verarbeitungs-Request pro Locale unter Verwendung der Felder language/captionLanguage.
Pollen Sie den Status und aktualisieren Sie das Release-Board, bis jede Locale terminal ist.
Rufen Sie fertige Ausgaben ab und führen Sie Locale-spezifische QA-Prüfungen durch.
Veröffentlichen Sie bestehende Locales sofort und routen Sie fehlgeschlagene Locales in eine begrenzte Retry-Queue.

Translation-Workflow-Dokumentation öffnen

Integration starten

1) Authentifizierung

Server-only-API-Key-Muster

2) Status-Lifecycle

Queued/processing/completed/failed-Modell

3) Rate-Limit-Strategie

Header, Reset-Fenster und Polling-Disziplin

4) Fehler-Taxonomie

Programmatische Handhabung nach error.code

3-Schritt-Workflow

Ingesten Sie ein Quell-Asset mit Ziel-Locale-Matrix und Rollout-Policy.
Verarbeiten Sie Locale-Jobs asynchron mit unabhängiger Statusverfolgung pro Locale.
Veröffentlichen Sie fertige Locales über regionale Queues, während fehlgeschlagene Locales in kontrollierte Retries geroutet werden.

Warum sich Teams für Ssemble entscheiden

Konzipiert für regionale Channel-Teams, bei denen die Release-Koordination ebenso kritisch ist wie die Content-Qualität.
Isoliert Fehler pro Locale, sodass ein einzelnes Problem nicht ganze Kampagnen-Launches blockiert.
Funktioniert mit Posting-Automatisierung für Follow-the-Sun-Distributions-Workflows.

Nächster Schritt

Translation-API-Quickstart öffnen Preise ansehen Entwicklerdokumentation

FAQ

Wie verhindern wir, dass eine Locale alle Regionen blockiert?

Verwenden Sie Zustandsmaschinen und Release-Gates pro Locale, sodass jede Locale unabhängig veröffentlicht werden kann, sofern die Policy nicht eine Synchronisation aller Locales verlangt.

Sollten wir alle Locales auf einmal einreichen?

Meist nicht. Kontrolliertes Batching schützt die Rate-Budgets und vereinfacht die Incident-Triage, wenn ein Locale-Pfad degradiert.

Was ist der minimale Observability-Payload?

Verfolgen Sie für jeden Job die übergeordnete Release-ID, den Locale-Code, requestId, Statusübergänge, Error-Code und Retry-Count.

Welche Fehler sollten automatisch wiederholt werden?

Wiederholen Sie transiente Transport-, 429- und 5xx-Fehler mit Backoff. Scheitern Sie schnell bei Validierungsfehlern und routen Sie diese zur Config-/Daten-Korrektur.

Können Übersetzung und Posting getrennt werden?

Ja. Viele Teams halten den Abschluss der Übersetzung und das Channel-Publishing in separaten Queues für bessere Kontrolle und Rollback-Sicherheit.

Garantiert dies gleiche Ergebnisse über alle Locales hinweg?

Es sollte keine Garantie angenommen werden. Messen Sie Abschlusszeit, Fehlerrate und QA-Bestehensrate pro Locale und passen Sie die Rollout-Policy entsprechend an.