Verfuegbare APIs im Overlay

Verfügbare APIs im Overlay

Der Pro Editor spricht mit dem Backend über REST-Routen unter /v1/overlays. Wenn du "nur" Overlays im Editor baust, brauchst du davon nichts — aber wenn du Overlays automatisiert anlegen, per Skript ändern oder in ein eigenes Tool integrieren willst, ist hier der aktuelle Überblick. Authentifizierung: API-Token im Header Authorization: Bearer <token>, anlegbar unter /dashboard/tokens. (Der Editor selbst nutzt intern Session+CSRF statt API-Token — für deine eigenen Skripte ist der API-Token der richtige Weg.)

Overlay-Routen

Route	Methode	Zweck
`/v1/overlays`	GET	Alle Overlays des Accounts auflisten
`/v1/overlays`	POST	Neues Overlay anlegen
`/v1/overlays/{id}`	GET	Einzelnes Overlay laden (Definition inkl. `layout_json` + Metadaten)
`/v1/overlays/{id}`	PATCH	Overlay updaten (Name, `layout_json` usw.) — nicht PUT
`/v1/overlays/{id}`	DELETE	Overlay löschen (sofort, endgültig, kein Papierkorb)
`/v1/overlays/{id}/duplicate`	POST	Klon mit eigenem Token
`/v1/overlays/{id}/regenerate-token`	POST	Browser-Source-Token rotieren
`/v1/overlays/{id}/elements`	GET	Nur Lesen — Elemente eines Overlays einzeln abfragen. Ändern von Elementen geht ausschließlich über ein PATCH auf `/v1/overlays/{id}` mit komplettem `layout_json`, es gibt keine Einzel-Element-POST/PUT-Route auf diesem Pfad
`/v1/overlays/{id}/usage`	GET	Nutzungs-/Limit-Infos zum Overlay (z. B. Elementzahl vs. Plan-Limit)
`/v1/overlays/{id}/test-alert`	POST	Löst einen Test-Alert im Overlay aus, ohne ein echtes Event zu brauchen — praktisch zum Prüfen von Animationen ohne echten Follow/Sub
`/v1/overlays/{id}/emote-storm/fire`	POST	Löst einen Emote-Storm-Effekt im Overlay aus
`/v1/overlays/{id}/debug`	GET	Dieselben Diagnosedaten wie die Debug-Seite im Dashboard (Token-Status, WS-Status, letzte Fehler)
`/v1/overlays/{id}/renderer-error`	POST	Interner Endpunkt, über den die Browser-Source selbst Renderer-Fehler meldet — für eigene Skripte i. d. R. nicht relevant
`/v1/overlays/validate-token`	GET	Prüft, ob ein Overlay-Token noch gültig ist
`/v1/overlays/all-channel-bindings`	GET	Übersicht, welches Overlay an welchen Twitch-Channel gebunden ist

Szenen

Korrektur gegenüber einer früheren Version dieser Seite: Es gibt sehr wohl eine eigenständige Ressource /v1/overlay-scenes/ zusätzlich zu den Szenen-Routen direkt am Overlay:

Route	Methode	Zweck
`/v1/overlays/{overlay_id}/scenes`	GET	Szenen eines Overlays auflisten
`/v1/overlays/{overlay_id}/scenes`	POST	Neue Szene anlegen
`/v1/overlay-scenes/{id}`	GET	Einzelne Szene laden
`/v1/overlay-scenes/{id}`	DELETE	Szene löschen
`/v1/overlay-scenes/{id}/duplicate`	POST	Szene duplizieren

Denk dran: Szenen desselben Overlays teilen sich eine OBS-URL. Über die API kannst du damit z. B. automatisiert neue Szenen aus einem Template-Skript erzeugen, aber das Umschalten "welche Szene ist gerade live" ist ein Editor-/Dashboard-Vorgang, kein URL-Parameter beim Abrufen des Overlays.

Versionen

Auch die Versionshistorie hängt direkt am Overlay, nicht an einer separaten Ressource:

Route	Methode	Zweck
`/v1/overlays/{id}/versions`	GET	Versions-Liste
`/v1/overlays/{id}/versions/{version_id}`	GET	Eine konkrete Version laden
`/v1/overlays/{id}/versions/{version_id}/restore`	POST	Diese Version sofort wiederherstellen (legt vorher automatisch eine Sicherungsversion des aktuellen Stands an)

Templates

/v1/overlay-templates/ ist die kuratierte Vorlagen-Bibliothek von chatlix — keine Ablage für eigene Overlays:

Route	Methode	Zweck
`/v1/overlay-templates`	GET	Verfügbare Templates auflisten (optional Filter `?category=`)
`/v1/overlay-templates/{id}`	GET	Ein Template im Detail anschauen
`/v1/overlay-templates/{id}/use`	POST	Neues Overlay aus diesem Template erzeugen

Es gibt keinen POST auf /v1/overlay-templates zum Anlegen eigener Templates aus deinem Overlay — diese Funktion existiert nicht.

Overlay Builder (abgeschaltet)

Alle Routen unter /v1/overlay-builder/* liefern seit der Abschaltung des alten Overlay Builders (siehe Vom Builder zum Pro Editor) durchgehend HTTP 410 mit Fehlercode builder_retired. Es lohnt sich nicht mehr, Skripte gegen diesen Pfad zu bauen — der saubere Weg für alles Programmatische ist /v1/overlays mit einem Layout im Pro-Editor-layout_json-Format.

Camera-Sync

/v1/cam/ ist die interne Multi-Cam-Sync-Schnittstelle. Deutlich umfangreicher als "eine Quelle aktiv setzen": inzwischen gibt es dafür ein eigenes, größeres API-Bündel unter /v1/cam-server/ mit Kamera-Verwaltung (CRUD), Publish-/Subscribe-Tokens für die Übertragung und einer eigenen Hintergrundbibliothek (/v1/cam-server/backgrounds für Upload/Verwaltung eigener Cam-Hintergründe). Für den Alltag im Pro Editor musst du davon nichts wissen: Das Kamera-Element zeigt automatisch die aktuell aktive Quelle, die Verwaltung läuft über das Dashboard, nicht über manuelle API-Aufrufe.

Laufzeit-Updates im Renderer

Alerts, Zähler, Hype-Train & Co. aktualisieren sich in der laufenden Browser-Source über WebSocket. Das ist ein interner Mechanismus, den die Browser-Source selbst herstellt — es gibt keine öffentlich dokumentierte, stabile window.Chatlix-JS-API, die du in eigenem Custom-JS innerhalb eines Elements ansprechen könntest. Falls du das irgendwo gelesen hast (z. B. ein Chatlix.on('follow', …)-Snippet): das gibt es im aktuellen Renderer-Code nicht, verlass dich nicht darauf. Wenn du auf Events reagieren willst, ist der unterstützte Weg entweder ein eigenes Backend, das per API-Token pollt/abonniert, oder du nutzt die vorhandenen Widgets (Event-Liste, Latest-Label, Alert-Element), die diese Events bereits eingebaut anzeigen.