Event Reactions verstehen

Event Reactions (im Dashboard heißt die Seite „🔔 Alerts & Reaktionen") sind automatische Antworten auf Twitch-Events — Follow, Sub, Raid, Cheer, Hype Train & Co. Twitch meldet „das ist gerade passiert", Chatlix reagiert: eine Chat-Nachricht deines Bots plus, wenn ein Overlay verbunden ist, automatisch ein visueller Alert im Stream.

Wichtiger Realitäts-Check vorweg: Dieses Kapitel wurde 2026-07-08 komplett gegen den produktiven Code geprüft. Ältere Fassungen dieser Seiten beschrieben ein Konzept mit frei wählbaren „Actions" (Sound-Datei, Overlay-Text, TTS, Combo, Sequenz mit Delays) pro Reaction. Das gibt es in „Event Reactions" nicht. Was wirklich existiert:

Pro Event-Typ gibt es genau eine konfigurierbare Chat-Nachricht (Textvorlage mit Variablen).
Der visuelle Overlay-Alert (Sound + Animation) läuft automatisch mit, sobald ein Overlay verbunden ist — du schaltest ihn pro Event-Typ nur an/aus und stellst Priorität/Sound ein (Tab „Alert-Steuerung"), du baust ihn nicht selbst aus Einzel-Actions zusammen.
Mehrstufige Sequenzen mit Pausen, Bedingungen oder Zählern gehören ins Buch Automations, nicht hierher.

Abgrenzung zu Rewards und Commands

Reward-Binding = Zuschauer löst aktiv einen Channel-Points-Reward ein (eigenes Buch Rewards).
Command = Zuschauer tippt !irgendwas in den Chat (Buch Commands).
Event Reaction = Twitch meldet ein Ereignis von selbst (neuer Sub, Raid, Cheer …), Chatlix reagiert ohne Zutun des Zuschauers.

Unterstützte Event-Typen (Stand Code, nicht geraten)

Das sind die Event-Typen, die die Chat-Reaktions-Engine kennt (EventReactions::ALLOWED_TYPES). In der UI unter „Chat-Reaktionen" bekommt jeder davon eine eigene Karte — mit Ausnahme von donation, das aktuell nur über die API/Automations konfigurierbar ist, aber (noch) keine eigene Karte im Dashboard hat.

Event-Typ (intern)	Label im Dashboard	Variablen im Template
`follow`	👋 Neuer Follower	`{user}`
`sub`	💜 Neue Subscription	`{user}`, `{tier}`
`resub`	🎉 Resub	`{user}`, `{months}`, `{tier}`
`sub_prime`	👑 Prime Sub	`{user}`
`sub_prime_upgrade`	⬆️ Prime → Paid Upgrade	`{user}`
`gift_sub`	🎁 Gifted Sub	`{user}`, `{amount}` (Anzahl verschenkter Subs)
`raid`	🚀 Raid	`{user}`, `{viewers}`
`cheer`	💎 Cheer (Bits)	`{user}`, `{amount}` (Bits)
`host`	📡 Host	`{user}`, `{amount}`
`goal`	🎯 Goal erreicht	`{amount}`
`hype_train_begin`	🚂 Hype Train startet	`{level}`, `{total}`
`hype_train_progress`	🚂 Hype Train Fortschritt	`{level}`, `{total}`
`hype_train_end`	🏁 Hype Train endet	`{level}`, `{total}`
`donation`	(keine eigene Karte, per API/Automation)	`{user}`, `{amount}`, `{currency}`, `{message}`
`external.custom`	🔌 Extern: Custom	`{user}`, `{message}`, `{source}`
`external.button`	🎛️ Extern: Button	`{user}`, `{source}`
`external.scene`	🎬 Extern: Szene	`{user}`, `{message}`, `{source}`
`external.lumia`	💡 Extern: Lumia	`{user}`, `{message}`, `{source}`
`external.streamerbot`	🤖 Extern: Streamer.bot	`{user}`, `{message}`, `{source}`
`external.firebot`	🔥 Extern: Firebot	`{user}`, `{message}`, `{source}`

Es gibt kein separates „Host"-Deprecation-Problem und keine „Stream Online/Offline"-Reaction in diesem System — das war in einer älteren Fassung dieser Seite falsch angegeben. stream.online/stream.offline sind zwar Twitch-EventSub-Topics, die Chatlix intern für andere Zwecke (z. B. Session-Tracking) abonniert, aber sie tauchen nicht als Event-Reaction-Typ mit eigenem Template auf.

Sub-Tiers sind Twitch-Rohwerte, nicht 1/2/3

Ein häufiger Stolperstein: {tier} bei sub/resub liefert die rohen Twitch-Werte 1000, 2000, 3000 (Tier 1, 2, 3) — nicht die Zahlen 1/2/3. Ein Template wie Danke für den Tier-{tier}-Sub! zeigt also „Tier 1000" an, wenn du nicht selbst um das Tausenderformat weißt. Willst du „Tier 1" ausgeben, musst du das im Text fest verdrahten oder mit einer Bedingung (siehe Seite Reaction-Tiers) unterscheiden.

Genau eine Reaction pro Event-Typ und Channel

Die Datenbanktabelle event_reactions hat einen UNIQUE KEY (channel_id, event_type) — du kannst also nicht mehrere Reactions für z. B. sub parallel anlegen, um Tier 1/2/3 unterschiedlich zu behandeln. Jeder Event-Typ hat genau eine Karte, genau ein Template, genau einen Cooldown, genau eine optionale Mindestmenge (min_amount) und optional einen Satz Bedingungen. Speicherst du erneut, wird die bestehende Zeile überschrieben (ON DUPLICATE KEY UPDATE), es entsteht keine zweite.

Wenn du wirklich unterschiedliche Texte/Effekte je nach Tier oder Bit-Menge willst, geht das nur über Bedingungen innerhalb der einen Reaction (die Reaction feuert dann nur bei Match, immer mit demselben Template) oder über das Buch Automations, das echte Verzweigung kann. Details dazu auf der Seite Reaction-Tiers (Bits/Sub-Tiers).

Wie das technisch läuft

Chatlix abonniert über den Twitch-EventSub-Service die Channel-Events deines Kanals (Klassen Chatlix\Twitch\EventSub, EventSubManager, EventSubFanout). Twitch ruft den Webhook /v1/twitch/eventsub/webhook (bzw. legacy /webhook/twitch/eventsub) auf. Von dort geht der normalisierte Event an EventReactions::evaluateTrigger() in Chatlix\Service\EventReactions — dieselbe Methode wird auch vom tokenbasierten External-Action-Ingress für external.*-Events genutzt (eine Engine, kein zweiter Auswertungspfad).

Prüfreihenfolge in evaluateTrigger(): Reaction vorhanden + enabled? → min_amount erreicht? → bei Hype-Train zusätzlich min_level/min_total aus config_json? → Bedingungen (ConditionEvaluator, deklarativ, kein eval()) erfüllt? → Cooldown frei (Redis, NX+EX)? → Template rendern → fired_count/last_fired_at hochzählen. Ein Non-Match vor dem Cooldown-Schritt verbraucht keinen Cooldown-Slot.

Relevante Routen:

GET /v1/event-reactions — Liste der Reactions für einen Channel.
POST /v1/event-reactions — Reaction anlegen/aktualisieren (Upsert nach event_type).
DELETE /v1/event-reactions/{id} — Reaction löschen.
POST /v1/event-reactions/trigger — interner Chokepoint, über den Worker + External-Ingress feuern.
GET /v1/eventsub/subscriptions, POST /v1/eventsub/subscriptions, DELETE /v1/eventsub/subscriptions/{id}, POST /v1/eventsub/sync-pending — EventSub-Abo-Verwaltung.
GET/PUT /v1/alert-control/settings, GET/POST /v1/alert-control/history, POST /v1/alert-control/replay — Overlay-Alert-Steuerung (separat von den Chat-Reaktionen).

Wo du das im Dashboard findest

/dashboard/events-reactions — die Hauptseite „Alerts & Reaktionen" (Achtung: mit „s" — nicht /dashboard/event-reactions). Vier Tabs:
- 🔔 Testen — feuert simulierte Events direkt an dein verbundenes Overlay, ohne echten Twitch-Event.
- Chat-Reaktionen — die Templates pro Event-Typ (das eigentliche „Event Reactions"-Feature).
- Event-Abos — Twitch-EventSub-Subscriptions verwalten (siehe Seite Erste Reaction einrichten).
- ⚙️ Alert-Steuerung — pro Event-Typ Overlay-Alert an/aus, Sound an/aus, Priorität; plus Alert-Verlauf mit Re-Fire-Funktion.
/dashboard/stream-reactions — eine ältere, als „Legacy" markierte Seite im Nav-Menü unter „Reaktionen & Effekte". Verwechsle sie nicht mit der aktuellen Seite — im Menü steht dort ausdrücklich „Legacy — siehe Reaktionen".
/dashboard/reward-bindings — Channel-Points-Redemptions sind ein eigenes Thema, siehe Buch Rewards.

Was zählt als eine Reaction

Eine Reaction ist die Kombination „Event-Typ + optionale Mindestmenge/Bedingungen + Chat-Text". Beispiele, wie sie real im Editor aussehen:

follow → Willkommen im Channel, @{user}! 👋
sub → 💜 Megadanke @{user} für die Sub! Tier {tier}
raid, Min. Viewer 50 → 🚀 HYPE! Willkommen @{user}-Raid mit {viewers} Viewern!
cheer, Min. Bits 1000 → @{user} hat {amount} Bits dagelassen — WOW!

Läuft ein Overlay, feuert bei aktiver Reaction zusätzlich automatisch ein visueller Alert (sofern in der Alert-Steuerung nicht deaktiviert) — das ist kein separater Konfigurationsschritt innerhalb der Reaction selbst.

Nächste Schritte

Erste Reaction einrichten — der praktische Einstieg, inkl. EventSub-Abo und Alert-Steuerung.
Reaction-Tiers (Bits/Sub-Tiers) — was mit „nur eine Reaction pro Event-Typ" wirklich an Differenzierung geht.
Combos + Sequenzen — was es an Mehrfach-Aktionen wirklich gibt, und wo stattdessen Automations hingehört.