Riferimento degli eventi dal vivo

Questa pagina documenta i payload canonici degli eventi che Social Stream Ninja emette per le principali piattaforme. Usala come riferimento condiviso quando colleghi nuove sorgenti, risolvi problemi delle integrazioni o uniformi le etichette dell'interfaccia. Per una matrice più breve orientata ai consumer, vedi Compatibilità di eventi e avvisi.

Importante: La disponibilità degli eventi dipende dalla sorgente, dalle autorizzazioni e dalle impostazioni di acquisizione. Per nascondere le righe contrassegnate come eventi negli overlay dock o in primo piano, aggiungi &hideevents oppure &hideallevents. Per nascondere eventi selezionati, usa &filterevents=subscription_gift,new_follower,gifted. Questi filtri possono nascondere anche le righe a pagamento che contengono un event; le normali righe di donazione senza un indicatore evento non corrispondono ai filtri eventi. Gli altri filtri dei messaggi si applicano comunque.

Scegli il metodo di acquisizione: Per YouTube, Twitch e Kick, Modalità WebSocket offre in genere una copertura eventi più ampia. L'acquisizione DOM standard legge le righe e le schede effettivamente renderizzate nella pagina. Super Chat, Super Sticker e regali Jewel di YouTube hanno percorsi di acquisizione in entrambe le modalità; gli altri eventi di regalo, mancia e abbonamento variano in base alla sorgente. Consulta le tabelle delle piattaforme per i percorsi supportati e le impostazioni richieste.

Stai creando automazioni? Consulta la Guida a Event Flow per imparare a usare questi payload evento nei trigger personalizzati, negli avvisi e nei flussi di lavoro. La guida include un Riferimento delle variabili dei template per la formattazione del testo.

Struttura del payload: Le righe chat in stile donazione devono usare hasDonation e il facoltativo donoValue. Non impostare event: "donation" solo perché una normale riga chat/mancia ha un valore; usa nomi evento specifici solo per vere azioni della piattaforma o tipi di articoli a pagamento, come superchat, supersticker, gift, oppure jeweldonation. Usa meta solo per dati strutturati aggiuntivi di cui i consumer hanno effettivamente bisogno e che non sono già coperti dai campi esistenti.

Disponibilità rapida delle funzionalità

Usa questa tabella per vedere quali tipi di avviso fornisce attualmente ciascun metodo di acquisizione. Sotto trovi note dettagliate sui payload.

Il Multi-Stream Alert Box dedicato raggruppa gli eventi dal vivo in sei categorie principali di avvisi: Follow, Subscription/Member, Donation, Bits/Cheers, Raid/Host, e Purchase, più due categorie da attivare esplicitamente (Auction e Hype Train) abilitate tramite parametri URL. Ricava queste categorie dai valori esistenti event, membership, subtitle, hasDonation, e meta campi documentati qui; non è richiesto un formato di payload separato.

Sorgente	Nuovi abbonati / membri	Nuovi follower	Donazioni	Conteggi ed extra
YouTube (bridge Data API)	Nuovi abbonamenti, rinnovi, regali	Avvisi sui singoli abbonati* + totali	Super Chat e Super Sticker	Totali di spettatori, abbonati e visualizzazioni (polling)
Twitch – Acquisizione DOM	Righe dei pacchetti regalo e avvisi sui destinatari	-	Bit identificati tramite `hasDonation`	Numero di spettatori, schede ricompensa e schede delle evidenziazioni della community
Twitch – EventSub/Websocket	Abbonamenti, rinnovi e regali istantanei	Follow istantanei + totale follower	Cheers, Power-up e riscatti dei punti canale	Totali spettatori/abbonati/follower, stato della diretta, avvisi pubblicitari
TikTok Live	-	Schede di follow (quando TikTok le mostra)	Regali convertiti in totali di monete	Numero di spettatori, avvisi di ingresso e raffiche di Mi piace
YouNow	-	Attività dei fan e del pubblico	-	Numero di spettatori dal pannello del pubblico dal vivo
Favorited Studio	-	-	-	Numero di spettatori dalla scheda degli spettatori dal vivo
Whatnot	-	-	-	Numero di spettatori, avvisi di ingresso, metadati delle aste dal vivo, prodotti e istantanee dei giveaway
eBay Live	-	-	-	Numero di spettatori, numero di follower, istantanee delle schede degli eventi live, metadati del piè di pagina dell'asta (quando esposti), cuori di reazione e metadati degli eventi in programma
Riquadro avvisi Streamlabs	Abbonamenti, regali, sponsor, follow	Cheer/bit, donazioni (con valuta)	Cheer/bit, donazioni (hasDonation)	Mentre è aperto un riquadro avvisi; disponibile anche tramite `sources/websocket/streamlabs.html` token socket
OBS Flow Actions	-	-	-	Eventi OBS di output, scena, buffer di replay e fine dei contenuti multimediali per Event Flow quando `actions.html` è connesso a OBS WebSocket
Kick – DOM	-	-	-	Numero di spettatori più avvisi di sistema di base per ricompense/regali; usa il bridge Kick per avvisi più completi
Kick – Websocket/Bridge	Nuovi abbonamenti, rinnovi e regali	Avvisi di follow + totale follower	Eventi di supporto/mancia (importo + valuta)	Stato della diretta, riscatti ricompensa e metadati del profilo
Facebook Live	-	-	Stars quando visibili nel DOM	Righe chat, Stars e polling del numero di spettatori
Rumble – Acquisizione DOM	-	-	Prezzi Rant visibili	Chat, raid in arrivo e polling del numero di spettatori
Rumble – Websocket/URL API	Nuovi abbonamenti e abbonamenti regalati	Avvisi di follow + totale follower	Rant/mance (importo + valuta)	Totali spettatori, totali abbonati, stato live e feed chat
Streamplace	-	-	-	Numero di spettatori più nomi, colori, badge, risposte e link della chat
WorldsWave	-	-	Etichette delle donazioni, quando presenti	Chat dal vivo renderizzata più aggiornamenti del numero di spettatori da attivare esplicitamente
CHZZK	-	-	Righe visibili delle donazioni cheese	Righe chat, immagini dei badge, emoticon e polling del numero di spettatori
BEAM	-	-	-	Righe chat e polling del numero di spettatori quando la pagina con la sola chat espone un contatore spettatori
Seal Team Sloth	-	-	-	Righe chat renderizzate in finestra separata più `viewer_update` interroga quando il conteggio spettatori è abilitato
Castyr	-	-	-	Righe chat renderizzate in finestra separata più aggiornamenti del numero di spettatori da attivare esplicitamente
RPLAY	-	-	-	Con accesso effettuato `/live/chat/box/` finestra separata: `type: "rplay"` chat, avatar, immagini dei badge dei livelli ed emoticon. Le mance in monete mantengono importo/unità in `hasDonation` per la conversione USD condivisa, senza un evento di donazione. Il facoltativo `viewer_update` polling usano un intero `meta` dall'endpoint pubblico delle dirette RPLAY. Le righe Twitch inoltrate sono escluse.
FLEX TV	-	-	-	Righe chat renderizzate con nomi, colori degli autori, immagini dei badge e metadati dei membri

*Gli avvisi sugli iscritti YouTube vengono rilevati tramite polling e possono essere ritardati o incompleti. La documentazione API non garantisce una finestra fissa di consegna di quattro ore. Vedi la limiti dell'API ufficiale degli abbonamenti.

Panoramica dei campi

data qui indica l'oggetto messaggio, non un ulteriore involucro da aggiungere. Le righe chat e gli eventi con soli metadati hanno strutture diverse: contatori e istantanee di stato possono omettere chatname/chatmessage. Nelle tabelle delle piattaforme, messaggio descrive una normale riga chat, non un valore letterale event: "message".

Campo	Struttura	Utilizzo
`data.type`	stringa	Identificatore della sorgente usato da overlay, filtri ed Event Flow. Instagram mantiene la chat dal vivo come `instagramlive` e i commenti non in diretta come `instagram`. Vedi la Guida ai tipi di sorgente per varianti, sorgenti generiche e instradamento in uscita.
`data.chatname`	stringa	Nome visualizzato fornito dalla sorgente, usato nell'elaborazione dei messaggi e negli output diversi dagli overlay. Un alias del nome visualizzato configurato può sostituire questo valore solo nelle copie dei payload di trasporto del dock e degli overlay.
`data.username`	stringa	Nome utente della sorgente, quando disponibile. Un payload del dock o dell'overlay con alias può aggiungere questo campo per mantenere il valore originale `chatname` per le azioni utente; il messaggio canonico resta invariato.
`data.userid`	stringa	Identificatore utente specifico della piattaforma. Le azioni utente preferiscono questo valore a `username` e `chatname`.
`data.platform`	stringa (facoltativa)	Alcune integrazioni includono questo insieme a `type`. Molti adattatori delle sorgenti lo omettono; usa `type` per l'instradamento della sorgente.
`data.id`	stringa \| numero (facoltativo)	Identificatore del messaggio o dell'evento. Il suo significato dipende dalla sorgente e dal trasporto; non presumere che sia sempre un ID di moderazione nativo della piattaforma. Usa `meta.messageId` quando l'adattatore lo espone per la sincronizzazione delle eliminazioni.
`data.donoValue`	numero (facoltativo)	Equivalente numerico in USD fornito dalla sorgente, incluse le stime. Un valore valido (compreso zero) prevale sulla conversione di currency.js. In sua assenza, i consumer stimano gli USD da hasDonation e dal contesto della sorgente. Importi e unità originali restano in hasDonation e nei metadati esistenti del provider.
`data.chatbadges`	array \| stringa (facoltativo)	URL delle immagini dei badge o oggetti badge (`type: "img"` con `src`, `type: "svg"` con `html`, oppure `type: "text"` con `text`). Il relay mantiene l'etichetta letterale di un badge testuale nel campo facoltativo `rawText` e produce valori con escape `text` per gli overlay precedenti. Nei successivi passaggi del relay, rigenera `text` da `rawText`; non applicare l'escape a `text` di nuovo. I renderer attuali visualizzano `rawText` letteralmente quando presente e mantieni altrimenti la gestione precedente del testo codificato. È un campo di rappresentazione, non un'autorizzazione a renderizzare HTML. Le sorgenti precedenti possono inviare una singola stringa HTML anziché un array. Gli overlay che renderizzano i badge accettano entrambi i formati e sanificano localmente HTML e URL dei badge, anche quando il mittente è un'estensione precedente. I badge non validi non devono impedire la visualizzazione del messaggio chat o di abbonamento.
`data.event`	stringa \| booleano	Identificatore dell'attività di sistema (ad esempio `viewer_update`, `subscription_gift`, `giftpurchase`). La chat normale deve lasciare questo campo vuoto/false, affinché gli overlay possano distinguere gli avvisi di sistema dal testo della conversazione.
`data.chatmessage`	stringa	Corpo del messaggio. Può contenere HTML sanificato/renderizzabile solo quando `data.textonly` è false.
`data.textonly`	booleano	Si applica solo a `data.chatmessage`. `true` significa renderizzare `chatmessage` come testo semplice, mantenendo i tag letterali e il testo che assomiglia a entità; non decodificare, non sanificare come HTML e non aggiungere tag di formattazione a quel corpo. Applica lo stile dell'evento all'elemento visualizzato. `false` significa `chatmessage` può contenere HTML sanificato/renderizzabile; i messaggi precedenti senza l'indicatore mantengono quel comportamento HTML. Gli altri campi normali sono testo semplice, eccetto i campi multimediali come `chatimg` e `contentimg`. Visualizza i campi di testo semplice con `textContent`, oppure applica l'escape una sola volta quando costruisci un template HTML; non rimuovere parti del contenuto e non decodificarlo ripetutamente.
`data.contentimg`	stringa (facoltativa)	Immagine del contenuto o URL multimediale supportato. Nell'estensione e nell'app desktop, l'opzione `allowExternalGifs` riempie un campo vuoto con il primo link GIF HTTP(S) diretto nel testo del messaggio o in un link HTML. Il percorso dell'URL deve terminare con `.gif` (senza distinzione tra maiuscole e minuscole); i parametri di query e i frammenti vengono mantenuti. Non richiede una chiave API, mantiene `chatmessage` e gli allegati esistenti, e rispetta `removeContentImage`. Il facoltativo `hideExternalGifUrl` aggiunge `meta.hideExternalGifUrl: true`; il dock e l'overlay in primo piano nascondono poi il link GIF corrispondente solo dopo il caricamento dell'immagine, mantenendo il testo circostante e il payload originale. Se un'immagine non si carica o scade il tempo di attesa, il contenitore dell'allegato si chiude e il link resta visibile. L'overlay solo GIF prova a visualizzare direttamente l'immagine se il recupero dei byte fallisce, usando il tempo di visualizzazione configurato quando non è disponibile la durata dell'animazione; i caricamenti falliti o bloccati fanno avanzare la coda. Non aggiunge un `event` oppure cambia la sorgente `type`. Le immagini esterne non vengono sottoposte a filtri dei contenuti e potrebbero non caricarsi se l'host ne blocca l'incorporamento.
`data.membership`	stringa	Stato leggibile dell'abbonamento, come `MEMBERSHIP`, `new_sponsor`, `gift_recipient`. Le interfacce lo usano per badge, filtri e annunci.
`data.subtitle`	stringa	Descrizione aggiuntiva (anzianità dell'abbonamento, upgrade del livello, regalato da...). Mantienila breve e in solo testo, affinché gli overlay possano inserirla sotto il nome visualizzato.
`data.hasDonation`	stringa	Importo monetario o di un regalo virtuale (`$5.00`, `500 bits`, `300 coins`). Compila anche quando `data.event` è vuoto affinché gli overlay delle donazioni possano rilevarlo.
`data.meta`	numero \| oggetto \| stringa (precedente)	Usa interi semplici per i singoli contatori (spettatori, follower, abbonati) e oggetti per un contesto più ricco. Alcuni eventi precedenti, come Twitch DOM `community_highlight`, contengono una stringa. Verifica la struttura specifica dell'evento prima di leggere le proprietà dell'oggetto; i nuovi dettagli strutturati devono essere inseriti in un oggetto.
`data.firsttime`	booleano	Imposta su `true` quando sono abilitati il rilevamento di chi scrive per la prima volta e il database locale, e questo è il primo messaggio chat salvato per quell'utente/sorgente. Il dock lo usa per l'evidenziazione e i filtri del segnale acustico dei nuovi partecipanti; l'impostazione facoltativa del badge per chi scrive per la prima volta antepone un badge foglia a `chatbadges`.
`data.lastactivity`	numero	Timestamp Unix in secondi della precedente attività chat salvata di quell'utente, quando sono abilitati il rilevamento di chi scrive per la prima volta e il database locale. Omesso per gli utenti completamente nuovi.

Il trasporto dei controlli dell'overlay è separato dalla chat e dagli eventi acquisiti. I ricevitori aggiornati usano un ssnControl involucro contenente un identificatore di consegna id, funzionalità target, canale di risposta e ID del client per l'istantanea facoltativi. I corpi delle funzionalità esistenti restano intatti. I controlli pubblici delle funzionalità usano il canale 7; Actions mantiene il canale 6. Lo stato di Poll e Map include un host epoch, revision e reset indicatore; Timer, Ticker e Spotify usano ssnState con un'epoca e una revisione. Questi indicatori descrivono lo stato dell'host, non una cronologia ripristinata di voti/chat. Le sorgenti non devono aggiungere campi dell'involucro di controllo ai messaggi acquisiti. Una conferma di ricezione non dimostra il completamento dell'azione né la visibilità in OBS. Vedi la stato della migrazione per le funzionalità supportate, la negoziazione delle risposte e i limiti di riconnessione.

Phrase Guess usa il nativo {response: text} richiesta per le risposte chat server2 e {action: "phraseGuessResponse", value: {type: "bot", chatname: name, chatmessage: text}} per annunci destinati solo al dock. L'host deve abilitare i messaggi server3 in arrivo; disabilitare il controllo dell'host blocca comunque queste richieste. Gli annunci del dock vengono inoltrati come normali righe chat bot con textonly: true, senza inviarli agli input della chat delle sorgenti di acquisizione. La modalità API precedente mantiene il formato di comando esistente.

Convenzioni di meta

Per mantenere coerenti dashboard e automazioni, segui queste convenzioni quando estendi data.meta:

viewer_update, follower_update, subscriber_update, e likes_update usano un intero semplice meta valore. likes_update è un totale autorevole della piattaforma: i consumer devono impostare il valore visualizzato anziché sommarlo. Lo script in background aggrega il numero di spettatori in viewer_updates con un oggetto indicizzato per data.type.
giveaway_state è un'istantanea con soli metadati generata dall'host per le visualizzazioni gestite. meta.giveaway versione 2 include giveawayId, persistente roundId/epoch, aumentando generation tra i nuovi turni, revision all'interno di un turno, status, open, draw, keyword, count, ticketCount, congelato config, fino a 120 anteprime entrants, e gli ultimi 20 winners. Le voci espongono id, name, platform e tickets; i vincitori aggiungono drawnAt e assegnati points. Coin Flip Pot aggiunge outcome; Number Hunt aggiunge number con il pubblico low, high e recenti guesses, mai il segreto. I consumer filtrano per ID del giveaway e scartano le generazioni/revisioni precedenti. Si tratta di esempi da visualizzare, non di un registro completo dei biglietti né di un'istruzione di pagamento. Chiavi dei portafogli, saldi e prenotazioni restano esclusi dalle istantanee per il pubblico. L'host pubblica sul giveaway Etichetta P2P e feed WebSocket degli overlay abilitati; questo non implica visibilità in OBS. Guida.
meta.giveawayControlResult contiene il risultato di un'azione giveaway di Event Flow (ok, facoltativo error, giveaway oppure simulated). meta.giveawayHandled elenca gli ID dei giveaway già gestiti da un'azione del flusso di partecipazione/acquisto, affinché il comando chat automatico non possa addebitarli di nuovo. L'editor aggiunge meta.economyTest per azioni giveaway simulate; non è un evento della piattaforma sorgente né una credenziale di autorizzazione.
video_stats usa un valore strutturato meta oggetto per lo stato di salute di encoder/server esterni, inclusi provider, label, online, bitrateKbps, rttMs, bufferMs, contatori di pacchetti persi/scartati e dettagli del codec facoltativi.
Gli eventi in stile donazione possono includere un oggetto descrittivo: ad esempio { amount, currency, supporter } per Kick, { bits } per i cheer Twitch. Gli eventi di abbonamento hanno metadati specifici della sorgente; non sono automaticamente donazioni monetarie.
I messaggi webhook normalizzati di Stripe, Ko-fi, Buy Me a Coffee e Fourthwall includono identificatori limitati al provider meta.webhookId, copiato dall'identificatore stabile dell'evento del provider, affinché le pagine a valle possano eliminare i duplicati causati da nuovi tentativi e trasporti misti.
I raid Twitch passano { fromId, fromLogin, viewers }. Le altre sorgenti differiscono: Whatnot usa meta.numRaiders, mentre SharePlay usa il facoltativo meta.fromLogin/meta.viewers. Controlla la riga specifica della sorgente prima di leggere i metadati del raid.
I riscatti ricompensa Twitch EventSub espongono meta.rewardId, cost, rewardTitle, redemptionId, e un precedente alias insieme al messaggio preparato. Le schede ricompensa DOM e le altre sorgenti possono fornire meno campi o campi diversi.
user_banned contiene solo metadati per i widget di moderazione. Omette intenzionalmente chatname e chatmessage; usa meta.username, meta.displayName, meta.avatarUrl, e meta.profileUrl.
I trasporti chat che supportano la sincronizzazione delle eliminazioni tramite controllo della sorgente devono esporre l'identificatore nativo della chat della piattaforma come meta.messageId anziché basarsi sul valore interno del dock data-mid valore.
Le eliminazioni dalla sorgente usano {delete: {type, id}} per un ID messaggio noto del dock, oppure {delete: {type, meta: {messageId}}} per un ID messaggio nativo della piattaforma. Un ID noto rimuove solo i messaggi corrispondenti. Quando è noto soltanto l'utente destinatario, invia {delete: {type, userid}} oppure {delete: {type, chatname}} per rimuovere i messaggi di quell'utente da quella piattaforma. Non sostituire mai l'identità del moderatore a quella dell'utente interessato. Le eliminazioni in arrivo non richiedono l'impostazione facoltativa di sincronizzazione della moderazione dal dock alla piattaforma.
I metadati di identità della sorgente SSApp possono aggiungere meta.ssnAccountRole, meta.ssnSourceId, e meta.ssnSession quando a una sorgente viene assegnato un ruolo account diverso da quello normale.
Event Flow può richiedere un'evidenziazione impostando meta.featured = true nel payload chat, che porta automaticamente il messaggio in primo piano negli overlay dock/featured.
AI Event Overlay: l'azione showAiEventOverlay invia una copia del messaggio che l'ha attivata all'etichetta aievent-CONFIGURATION_ID, aggiungendo meta.aiEventOverlay: {profile: "CONFIGURATION_ID"}. I campi esistenti del messaggio e i metadati in forma di oggetto vengono preservati; i metadati scalari vengono conservati in meta.value. Si tratta di un invio mirato, non di un nuovo evento della piattaforma. Il messaggio originale non viene modificato. Consulta la guida alla configurazione.
Facoltativo meta.aiEventOverlay.variation seleziona una frase esatta approvata nelle impostazioni salvate dell’overlay. Il testo dello spettatore e i metadati compilano i campi del modello dopo la generazione.
Le richieste di visualizzazione di AI Event Overlay richiedono un profilo e il relativo token privato di visualizzazione. Impostazioni e chiavi API si gestiscono solo dal popup locale di SSN. Le risposte usano {aiEventResponse: {target, value}} oppure {aiEventResponse: {target, error}}. I risultati generati contengono template, duration, warnings, e URL di dati multimediali facoltativi in image/audio.
Le ricompense degli overlay IA pagate con punti usano aiEventPresentation (id, profile, expiresAt, result, message) e confermano la ricezione con aiEventDelivered (ID di consegna). Le ricevute degli addebiti e gli importi dei rimborsi restano sull’host.
Event Flow può richiedere di fissare un messaggio nel dock impostando meta.pinned = true; facoltativo meta.pinnedTarget limita quel fissaggio a un dock con il corrispondente label.
La stampa termica di Event Flow registra il risultato sotto meta.thermalPrintResult (success e il facoltativo code/error), mantenendo l'evento chat e gli altri metadati. Per gli eventi con metadati numerici o comunque diversi da un oggetto, la diagnostica resta nel risultato dell'azione e l'evento rimane invariato.
Ricompense sticker SSN da attivare esplicitamente: event: "sticker" viene inviato solo al stickers etichetta dell'overlay dopo un addebito di punti fedeltà. Imposta platform e type al campo del messaggio originale type, e mantiene chatname, con vuoto chatmessage, textonly: true, e contentimg contenente un percorso relativo di un'immagine inclusa nel pacchetto o un URL multimediale HTTPS approvato dall'host. meta.sticker contiene id, pack, name, cost, duration (secondi), motion, redemptionId, e expiresAt (millisecondi Unix). È una ricompensa SSN, non una donazione della piattaforma né un evento dei punti canale nativi. Vedi la galleria e guida alla configurazione.
Il lettore di sticker restituisce un pacchetto di controllo {action: "stickerReceipt", meta: {sticker: {redemptionId, success}}} al mittente quando l'immagine viene caricata o il caricamento fallisce. Solo le conferme provenienti da un dispositivo connesso stickers peer risolvono un riscatto in attesa. Una consegna non riuscita o non confermata attiva un rimborso; questo pacchetto di controllo non è un evento chat. È consigliata una sola visualizzazione sticker attiva per sessione.
I comandi dell'overlay del palco IA usano { action: "aiOverlay", target, meta } oppure la riproduzione del cohost controllata dal dock usa { action: "cohostOverlay", target, meta }; mantieni tutti i dettagli del comando, come command, text, emotion, avatar, e tts dentro meta.
Se una piattaforma espone più contatori insieme, preferisci un oggetto strutturato con chiavi esplicite (meta.viewer_count, meta.follower_count) invece di sovraccaricare le stringhe.
Gli overlay per il commercio devono usare gli oggetti istantanea sotto meta (ad esempio auction_update e commerce_update) ed evita campi aggiuntivi non standard al livello principale.

Copertura delle piattaforme

YouTube – Acquisizione DOM standard

Implementazione: sources/youtube.js

Mantieni aperta la scheda della chat dal vivo. L'acquisizione legge le schede degli abbonamenti e dei regali renderizzate in quella sessione; non richiede che lo spettatore sia il proprietario del canale o un moderatore. L'accesso all'account e la vista chat selezionata possono influire sulle righe visibili.
Aprendo l’overlay del numero di spettatori e dell’attività della chat con gli spettatori visualizzati, viene richiesto automaticamente il numero di spettatori. Le opzioni Mostra il numero di spettatori e Monitora i partecipanti attivi alla chat attivano anche la raccolta dei dati.
Per gli avvisi sui follower e altri eventi, abilita la modalità WebSocket nelle impostazioni dell'estensione.

Evento	Quando si attiva	Note sul payload
`sponsorship`	Intestazione di benvenuto per un abbonamento senza testo chat esplicito (nuovi membri, arrivo di pacchetti regalati), incluse schede di benvenuto strutturate o testo localizzato “Benvenuto in …”.	`membership` compilato con la traduzione di “MEMBERSHIP”; `subtitle` contiene serie/livello quando rilevati; `nameColor` usa il verde degli abbonamenti quando consentito.
`giftpurchase`	Banner di acquisto di un pacchetto regalo (`ytd-sponsorships-live-chat-gift-purchase`).	`membership` diventa `gift_giver`; `subtitle` contiene il numero di regali quando noto; nessun `hasDonation` oppure `donoValue`.
`giftredemption`	Annuncio di riscatto del regalo per i destinatari.	`membership` diventa “MEMBERSHIP”; `subtitle` include “Regalato da …”.
`resub`	Banner di upgrade che includono “upgraded to …”.	`subtitle` acquisisce l'etichetta del nuovo livello; `membership` rimane “MEMBERSHIP”.
`superchat`, `supersticker`, `jeweldonation`	Super Chat, Super Sticker, schede di annuncio donazione e YouTube Gifts basati su Jewels (`yt-gift-message-view-model`).	`hasDonation` contiene il valore; `event` identifica il tipo di articolo a pagamento YouTube. YouTube Gifts usa `N Jewels` quando presente, oppure `1 YouTube Gift` quando YouTube nasconde il conteggio. Le immagini dei regali usano `contentimg`, le etichette dei regali usano `subtitle`, e i dettagli minimi del regalo vengono replicati sotto `meta.youtubeGift`.
`jeweldonation` effetto regalo	YouTube mostra un regalo Jewel animato sopra la chat dal vivo (`ytls-gift-overlay-item-view-model`).	Inviato direttamente alla destinazione GIF/media dedicata, affinché l'animazione possa essere riprodotta senza duplicare la normale riga del regalo. `contentimg` contiene la risorsa animata e `meta.youtubeGift.animationUrl`/`animationDescription` mantengono i dettagli dell'effetto.
`reaction`	Una reazione di uno spettatore compare nella cascata di emoji dal vivo di YouTube.	Inviato direttamente alla destinazione dedicata alle reazioni. L'emoji anonima e l'URL dell'immagine vengono mantenuti in `chatmessage`/`contentimg` e sotto `meta.reactionType`/`reactionImage`. Le varianti dal vivo note includono ❤, 😄, 🎉, 😳 e 💯.
`thankyou`	Messaggio di ripiego quando esiste un importo di donazione ma non è stato fornito testo chat.	Mantiene `hasDonation` e inserisce automaticamente “Grazie per la donazione!” per gli overlay.
`redirect`	Un banner di reindirizzamento YouTube compare nella chat dal vivo (l'equivalente più simile a un avviso di raid).	Acquisizione solo DOM da `yt-live-chat-banner-redirect-renderer`. Imposta `event` a `redirect` e usa `membership` come etichetta, affinché gli overlay lo renderizzino come gli altri avvisi di sistema.
`viewer_update`	Polling ogni 30 s dell'endpoint spettatori Social Stream (ripiego sullo scraping della pagina in caso di errori di quota).	`meta` è il numero intero di spettatori dal vivo; contribuisce all'aggregato `viewer_updates` nello script in background.

I blocchi degli abbonamenti impostano anche membership per la chat di moderatori/membri, mentre subtitle contiene il numero di mesi o il nome del livello. sourceName/sourceImg vengono compilati una volta getChannelInfo riesce. La chat DOM standard ora include meta.messageId quando YouTube espone un ID nativo del messaggio della chat dal vivo, che il dock usa per la sincronizzazione delle eliminazioni.

YouTube – Acquisizione Websocket/Data API

Implementazione: sources/websocket/youtube.html, funzioni di supporto condivise sotto shared/

Usa per impostazione predefinita gli ambiti OAuth youtube.readonly e youtube.channel-memberships.creator. L'accesso in scrittura facoltativo aggiunge youtube.force-ssl per invio chat, moderazione, ban e modifica dei dettagli della diretta; Google può presentarlo come un'autorizzazione ampia di gestione YouTube, poiché YouTube non offre un ambito di scrittura limitato alla chat.
Le statistiche del canale rispettano le singole opzioni (showsubscount, showviewercount).
L'API non può fornire immagini personalizzate dei badge; i badge di ripiego usano le icone emoji indicate sotto.
Quando l'API segnala esplicitamente authorDetails.isChatModerator: true, i payload di chat, Super Chat, Super Sticker, YouTube Gift e regali di abbonamenti includono mod: true. Lo stato di moderatore non viene dedotto né memorizzato tra un evento e l'altro.
Gli avvisi sui nuovi abbonati usano il myRecentSubscribers API (polling ogni 5 minuti). Nota: i risultati possono arrivare in ritardo o essere incompleti; è possibile identificare solo le iscrizioni pubblicamente visibili.
I banner di reindirizzamento YouTube non sono esposti dalla Data API, quindi redirect rimane disponibile solo dall'acquisizione DOM standard.

Evento	Quando si attiva	Note sul payload
`superchat`	Voci Super Chat dalla cronologia della Data API o dal polling della diretta.	`hasDonation` mantiene l'importo del sito (valuta + valore); `event` è `superchat`. Le build WebSocket precedenti usavano `event: "donation"` per questa riga, quindi i consumer possono continuare ad accettarlo come alias precedente.
`supersticker`	Super Sticker (solo testo di ripiego del messaggio, nessuna immagine dall'API).	`hasDonation` contiene l'importo; `chatmessage` contiene il testo decodificato della descrizione.
`jeweldonation`	YouTube `giftEvent` messaggi quando gli spettatori riscattano Jewels per Gifts.	`hasDonation` contiene `N Jewels`, oppure `1 YouTube Gift` quando YouTube nasconde il conteggio; `contentimg` usa l'URL della risorsa regalo quando esposto; `subtitle` contiene l'etichetta del regalo; `meta.youtubeGift` contiene dettagli aggiuntivi del regalo.
`sponsorship`	Un nuovo membro si iscrive tramite `newSponsorEvent`.	`membership` diventa `new_sponsor` oppure `new_member`; `meta` include `originalEventType`, durate e informazioni sul livello.
`resub`	Rinnovi degli abbonamenti o upgrade del livello.	`membership` diventa `renewed_member` (rinnovi) oppure `upgraded_member` (upgrade); `subtitle` mostra il livello.
`giftpurchase`	Pacchetti regalo acquistati tramite l'API.	`membership` impostato su `gift_giver`; `subtitle` elenca numero/livello; nessun `hasDonation` oppure `donoValue`.
`giftredemption`	Notifiche di riscatto dei regali.	`membership` `gift_recipient`; i badge predefiniti sono 🎁; `subtitle` indica il livello regalato.
`membermilestone`	Messaggi chat dei traguardi (`memberMonth` oppure `displayMessage` presente).	`membership` `member_milestone`; `subtitle` riepiloga mesi + livello; `meta` acquisisce la mappatura grezza del traguardo.
`viewer_update`	Statistiche della diretta (spettatori simultanei) quando la segnalazione degli spettatori è abilitata.	`meta` è un conteggio intero; rispecchia lo scripting DOM affinché i consumer a valle possano unire entrambi i flussi. Un dock che usa `&showviewercount` richiede la raccolta del numero di spettatori per 70 minuti e rinnova la richiesta ogni ora senza modificare permanentemente l'impostazione globale.
`likes_update`	Polling delle statistiche video ufficiali quando Invia i totali dei Mi piace della piattaforma è abilitato.	`meta` è il numero intero corrente dei Mi piace del video. Viene emesso quando il conteggio cambia e periodicamente anche quando resta invariato, per mantenere aggiornati i consumer. L'opzione globale `captureliketotals` abilita questa funzione; il precedente `captureyoutubelikes` rimane un alias di compatibilità. Abilitando nel popup l'opzione per singolo dock `&showlikecount` abilita anche in modo persistente quelle impostazioni globali di acquisizione, mentre aggiungere manualmente il parametro URL controlla solo il rendering. Disattivare l'opzione di visualizzazione non disabilita la raccolta globale.
`subscriber_update`	Polling statistiche del canale (abbonati) quando `showsubscount` non disabilitato esplicitamente.	`meta` è il numero totale di abbonati; l'interfaccia aggiorna i contatori della dashboard.
`view_update`	Polling statistiche del canale (visualizzazioni totali) quando `showviewercount` oppure la modalità hype è attiva.	`meta` è il numero intero delle visualizzazioni.
`live_chat_ended`	La chat dal vivo diventa indisponibile per la trasmissione associata.	`meta.streamTitle` compilato quando i metadati della diretta erano memorizzati nella cache.
`user_banned`	`userBannedEvent` dall'API della chat dal vivo o dal flusso gRPC.	Evento con soli metadati per i widget di moderazione. `meta` include nome utente/nome visualizzato, ID canale, avatar/URL del profilo, moderatore, durata di ban/timeout e permanenza.
`new_follower`	Nuovo abbonato rilevato tramite `myRecentSubscribers` API (polling ogni 5 minuti).	`chatname` è il nome del canale dell'abbonato; `chatmessage` è vuoto a meno che i messaggi di avviso sugli iscritti siano abilitati nella pagina sorgente YouTube. `meta` include `channelId`, `title`, `subscribedAt`, e le raffiche raggruppate aggiungono `grouped`, `count`, `others`, e `subscribers`. Nota: i risultati possono arrivare in ritardo o essere incompleti; è possibile identificare solo le iscrizioni pubblicamente visibili.

I messaggi chat inoltrati dall'API usano meta.plainText per il messaggio in testo semplice insieme al contenuto ricco chatmessage contenuto. È testo, non HTML, e può comunque contenere emoji Unicode. I badge di abbonamento ripiegano su emoji (⭐, 💝, 🏅, ecc.) per restare coerente con l'acquisizione DOM. I payload della chat normale includono anche meta.messageId affinché le azioni di eliminazione dal dock possano tornare all'API di moderazione YouTube.

Avvisi sugli iscritti YouTube (new_follower)

Social Stream ora può rilevare i nuovi iscritti YouTube usando la myRecentSubscribers endpoint API. Il funzionamento è simile a quello degli avvisi sugli abbonati di Streamlabs.

Come funziona:

Interroga l'API YouTube ogni 5 minuti per gli iscritti recenti
Memorizza gli abbonati già visti in localStorage per rilevarne di nuovi
Emette new_follower eventi con nome dell'abbonato, avatar e ID canale
Mantiene disabilitati per impostazione predefinita i messaggi di avviso sugli abbonati; abilitandoli si usa la stringa di traduzione corrente per alert-just-subscribed
Raggruppa per impostazione predefinita le raffiche di oltre tre nuovi abbonati, così le riconnessioni non riempiono di eventi gli overlay o Event Flow
Richiede l'abilitazione della modalità WebSocket nelle impostazioni dell'estensione

Limitazioni (sono restrizioni dell'API YouTube, non di Social Stream):

Nessun ritardo di consegna garantito – SSN esegue il polling ogni cinque minuti, ma l'API può restituire risultati ritardati o incompleti. Non fare affidamento su una finestra fissa di quattro ore.
Solo iscrizioni pubbliche – Gli iscritti che hanno reso privato l'elenco delle proprie iscrizioni non attivano avvisi. Le iscrizioni sono private per impostazione predefinita su YouTube.
Solo proprietario del canale – Puoi ricevere avvisi sugli iscritti solo per i canali che possiedi e con i quali sei autenticato.
Utilizzo della quota API – Ogni polling costa 1 unità API. Con intervalli di 5 minuti, vengono usate circa 288 unità al giorno (sulle 10.000 della quota giornaliera predefinita).

Trigger dell'editor Event Flow: Usa data.event === "new_follower" e data.type === "youtube"

YouTube Websocket: riferimento rapido di eventi e abbonamenti

`data.event`	`data.membership`	Scenario
`sponsorship`	`new_sponsor`	Nuovo membro tramite `newSponsorEvent`
`sponsorship`	`new_member`	Nuovo membro tramite `processMembership`
`resub`	`renewed_member`	Rinnovo dell'abbonamento
`resub`	`upgraded_member`	Upgrade del livello
`giftpurchase`	`gift_giver`	Abbonamenti regalati al canale
`giftredemption`	`gift_recipient`	Abbonamento ricevuto in regalo
`membermilestone`	`member_milestone`	Messaggio chat dell'anniversario di abbonamento
`superchat`	-	Super Chat
`supersticker`	-	Super Sticker
`user_banned`	-	Evento ban/timeout con soli metadati
`new_follower`	-	Nuovo abbonato (polling; può arrivare in ritardo)

Twitch – Acquisizione DOM standard

Implementazione: sources/twitch.js

Mantieni aperta la chat Twitch. Gli abbonamenti e gli avvisi utente vengono acquisiti quando Twitch li renderizza; non sono limitati agli account broadcaster o moderatore. Per le funzionalità specifiche dell'account potrebbe servire l'autenticazione.
Le richieste del numero di spettatori raggiungono https://api.socialstream.ninja/twitch/viewers ogni 30 secondi.
Per avvisi sui follower, raid e supporto completo degli eventi, abilita la modalità WebSocket nelle impostazioni dell'estensione.
Gli avvisi Watch Streak condivisi dagli spettatori sono disabilitati per impostazione predefinita e richiedono l'opzione Mostra le serie di visione Twitch (Watch Streaks) impostazione.
L'opzione da attivare esplicitamente PluralMind può sostituire chatname, nameColor, e la parte avvolta dal proxy di chatmessage, e può aggiungere un badge testuale con i pronomi. username rimane il nome di accesso Twitch; le eliminazioni correlate contengono delete.meta.pluralmind affinché il dock usi quel nome di accesso stabile.

Evento	Quando si attiva	Note sul payload
`reward`	Schede di riscatto dei punti canale (incluso il contenitore ricompense 7TV).	`chatmessage` contiene il testo del riscatto; `membership` invariato.
`giftpurchase`	Righe di sistema come “L'utente regala X abbonamenti nel canale”.	`chatmessage` è la riga di sistema, che consente agli overlay di evidenziare le campagne di chi regala.
`subscription_gift`	Avvisi di abbonamenti regalati (“L'utente ha regalato un abbonamento a …”).	Contrassegna l'evento per i filtri delle evidenziazioni; `membership` rimane l'etichetta del badge del destinatario.
`viewer_update`	Richiesta ogni 30 s al proxy spettatori Social Stream (0 in caso di errore).	`meta` numero intero di spettatori.
`hype_train`	L'evidenziazione fissa della community di Twitch mostra un Hype Train attivo nella chat in finestra separata.	Ripiego DOM con soli metadati e `meta.sourceMode` impostato su `dom`. Usa livello, timer e valore visibili `meta.progressPercent` quando Twitch non espone i totali punti EventSub.
`community_highlight`	Elementi nel widget “Community Highlight” di Twitch.	`meta` è il testo di evidenziazione estratto per gli agganci delle automazioni.
`knock`	Inviti a collaborare con Stream Together visualizzati sopra la chat.	`chatmessage` contiene il testo dell'invito; `chatname` deriva dall'utente dell'avviso quando disponibile.
`watch_streak`	Avviso Watch Streak condiviso volontariamente dallo spettatore e renderizzato nella chat Twitch.	`meta.streakCount` contiene il conteggio visibile quando rilevato; `meta.milestoneId` usa l'identificatore dell'avviso DOM quando disponibile.

Bits/Cheers compilano hasDonation (ad esempio “500 bits”) anche se data.event resta vuoto; usa quel campo quando renderizzi i widget delle donazioni. Le informazioni sulla serie di abbonamenti compaiono in subtitle quando i badge espongono i mesi.

Twitch – EventSub/Websocket

Implementazione: sources/websocket/twitch.js con il core condiviso providers/twitch/chatClient.js

Ambiti OAuth: chat:read, chat:edit, user:write:chat, bits:read, moderator:read:followers, moderator:read:chatters, channel:read:subscriptions, channel:read:hype_train, channel:moderate, moderator:manage:banned_users, moderator:manage:chat_messages, channel:manage:broadcast, channel:read:redemptions, channel:read:ads, channel:manage:ads. I token broadcaster consentono di ottenere il numero di abbonati/follower.
Eventi consegnati da EventSub, più polling Helix per i totali di spettatori/follower/abbonati.
La modalità WebSocket fornisce in tempo reale avvisi sui follower, eventi di abbonamento, raid, cheer, Power-up, riscatti dei punti canale e metadati hype train.
Le righe Shared Chat usano Twitch IRC source-room-id per compilare sourceName/sourceImg con il canale di origine quando è diverso da quello connesso.
Gli avvisi Watch Streak condivisi dagli spettatori sono disabilitati per impostazione predefinita e richiedono l'opzione Mostra le serie di visione Twitch (Watch Streaks) impostazione.
L'opzione da attivare esplicitamente PluralMind può sostituire chatname, nameColor, e la parte avvolta dal proxy di chatmessage, e può aggiungere un badge testuale con i pronomi. username e userid mantengono l'identità Twitch; le eliminazioni correlate contengono delete.meta.pluralmind affinché il dock usi quei campi stabili.

Evento	Quando si attiva	Note sul payload
`cheer`	Notifiche Cheer da EventSub `channel.bits.use`.	`hasDonation` “N bits”; `meta.bits` numerico; `chatmessage` mantiene il messaggio grezzo; chi invia cheer ed è identificato include `chatimg`.
`powerup`	Notifiche Power-up integrate o personalizzate da EventSub `channel.bits.use`.	Payload con il solo evento e un campo vuoto `chatmessage` e nessun `hasDonation`, quindi non crea una normale riga della chat. `meta.bits` è numerico e `meta.powerUp` mantiene il sottotipo Twitch, titolo/id ricompensa, dettagli dell'effetto e testo del messaggio fornito, quando disponibili.
`new_subscriber`	`channel.subscribe` oppure USERNOTICE con `msg-id=sub`.	`meta` include `{ userId, tier, isGift }`; il totale memorizzato degli abbonati aumenta quando disponibile; i totali degli spettatori vengono rilevati separatamente tramite polling.
`resub`	`channel.subscription.message` oppure USERNOTICE `msg-id=resub`.	`meta` contiene la serie e i mesi cumulativi; `chatmessage` include il testo del rinnovo.
`subscription_gift`	`channel.subscription.gift` oppure USERNOTICE `msg-id=subgift`.	`meta` espone il totale regalato e il livello; `chatmessage` riepiloga l'azione.
`reward`	`channel.channel_points_custom_reward_redemption.add`.	`meta` include id, titolo, costo e prompt della ricompensa, input utente, id/stato del riscatto e alias precedente. Nessun campo al livello principale `reward` oggetto viene emesso da questo gestore EventSub. I consumer precedenti potrebbero ancora esporre `channel_points` come alias deprecato.
`raid`	EventSub `channel.raid` oppure USERNOTICE `msg-id=raid`.	`meta` = { fromId, fromLogin, viewers }.
`watch_streak`	Notifica Twitch IRC USERNOTICE da attivare esplicitamente, con `msg-id=viewermilestone` e `msg-param-category=watch-streak`.	Include lo spettatore in `chatname`, il testo dell'avviso Twitch in `chatmessage`, e `meta.streakCount`/`meta.milestoneId`. Gli altri tipi generici di USERNOTICE continuano a essere ignorati.
`new_follower`	`channel.follow` Notifiche EventSub.	Incrementa automaticamente `follower_update`; `meta` registra `{ userId, followedAt }`.
`viewer_update`	Helix `streams` polling ogni 30 secondi.	`meta` numero intero di spettatori; soppresso a meno che le statistiche spettatori siano abilitate nelle impostazioni.
`follower_update`	Totale follower Helix, richiesto dopo gli eventi di follow o tramite polling periodico.	`meta` numero intero di follower.
`subscriber_update`	Totale abbonati Helix (richiede un token broadcaster con l'ambito relativo agli abbonamenti).	`meta` numero intero di abbonati.
`stream_online` / `stream_offline`	EventSub `stream.online`/`stream.offline`.	`meta.startedAt` presente per gli eventi online; offline usa un oggetto vuoto.
`ad_break` / `ad_request` / `ad_schedule`	Risposte API del gestore annunci (`channel.ad_break.begin`, manuale `POST channels/ads`, `GET channels/ads`).	`meta` fornisce dettagli su durata, richiedente e payload della programmazione per le dashboard.
`hype_train`	EventSub `channel.hype_train.begin`, `channel.hype_train.progress`, e `channel.hype_train.end` notifiche v2.	Evento con soli metadati: nessun `chatname` oppure `chatmessage`. `meta.phase` è `begin`, `progress`, oppure `end`; `meta` include id del treno, livello, avanzamento, obiettivo, totale, contributori, campi temporali, indicatore del treno condiviso e `trainType`. I treasure train vengono esposti tramite `meta.trainType` quando Twitch li etichetta.
`user_banned`	EventSub `channel.ban`, oppure IRC `CLEARCHAT` ripiego quando gli eventi ban EventSub non sono disponibili.	Evento con soli metadati per i widget di moderazione. `meta` include nome utente/nome visualizzato, ID utente, avatar/URL del profilo, moderatore, motivo, durata di ban/timeout e permanenza.

I payload chat riutilizzano il provider condiviso, quindi data.event viene compilato per `/me` (action) e il precedente bits tag anche fuori dai flussi EventSub. I messaggi GIF Twitch inseriscono la risorsa Giphy in contentimg, lascia chatmessage vuoto, e mantieni l'etichetta di ripiego di Twitch in meta.gifLabel. La logica di deduplicazione ed eliminazione usa gli ID dei messaggi; i messaggi inviati tramite SSN usano il nativo message_id dall'eco IRC di Twitch in data.id.

Metadati Twitch Hype Train

hype_train contiene solo metadati e non include chatname oppure chatmessage. Le dashboard devono aggiornare la visualizzazione di un treno esistente tramite meta.id anziché aggiungere ogni aggiornamento dell'avanzamento come chat. La Meta Data Bar (meta.html) visualizza questi eventi come una barra di avanzamento superiore.

Campo	Scrivi	Note
`type`	stringa	Sempre `twitch`.
`event`	stringa	Sempre `hype_train`.
`meta.phase`	stringa	`begin`, `progress`, oppure `end`.
`meta.id`	stringa	ID stabile del treno. Usalo per inserire o aggiornare un unico widget visibile del treno.
`meta.broadcasterUserId`	stringa	ID utente del broadcaster Twitch.
`meta.broadcasterUserLogin`	stringa	Nome di accesso del broadcaster Twitch.
`meta.broadcasterUserName`	stringa	Nome visualizzato del broadcaster Twitch.
`meta.total`	numero \| null	Valore totale del supporto segnalato da Twitch per il treno.
`meta.progress`	numero \| null	Avanzamento attuale verso l'obiettivo del livello.
`meta.goal`	numero \| null	Obiettivo del livello corrente.
`meta.progressPercent`	numero \| null	Percentuale di ripiego dal DOM quando Twitch espone solo la barra di avanzamento visibile nella finestra separata.
`meta.level`	numero \| null	Livello corrente o finale del treno.
`meta.topContributions`	array	Principali contributori. Ogni voce include `userId`, `userLogin`, `userName`, `type`, e il valore numerico `total`.
`meta.lastContribution`	oggetto \| null	Contributo più recente, con la stessa struttura di contributo di `topContributions`.
`meta.sharedTrainParticipants`	array	Dati grezzi dei partecipanti al treno condiviso, quando forniti da Twitch.
`meta.startedAt`	stringa	Timestamp ISO dell'inizio del treno.
`meta.expiresAt`	stringa	Timestamp ISO della scadenza del treno corrente.
`meta.endedAt`	stringa	Timestamp ISO della fine del treno, oppure vuoto prima della fine.
`meta.cooldownEndsAt`	stringa	Timestamp ISO della fine del cooldown, oppure vuoto prima della fine.
`meta.isSharedTrain`	booleano	True quando Twitch contrassegna il treno come condiviso.
`meta.trainType`	stringa	Di solito `regular`; i treasure train vengono esposti qui quando Twitch li identifica come tali.
`meta.allTimeHighLevel`	numero \| null	Livello massimo storico del treno, quando fornito da Twitch.
`meta.allTimeHighTotal`	numero \| null	Totale massimo storico del treno, quando fornito da Twitch.
`meta.sourceMode`	stringa	Indicatore di sorgente facoltativo come `dom`.
`meta.eventSubType`	stringa	Tipo EventSub originale: `channel.hype_train.begin`, `channel.hype_train.progress`, `channel.hype_train.end`, oppure `dom.community_highlight`.

Twitch EventSub: riferimento rapido degli eventi

`data.event`	Scenario
`new_follower`	Un utente ha seguito il canale
`new_subscriber`	Nuovo abbonamento
`resub`	Rinnovo dell'abbonamento con messaggio
`subscription_gift`	Abbonamenti regalati al canale
`cheer`	Bit donati
`powerup`	Power-up integrato o personalizzato usato
`reward`	Riscatto punti canale
`raid`	Raid in arrivo
`viewer_update`	Numero di spettatori simultanei
`follower_update`	Numero totale di follower
`subscriber_update`	Numero totale di abbonati
`stream_online`	Diretta iniziata
`stream_offline`	Diretta terminata
`ad_break`	Interruzione pubblicitaria iniziata
`hype_train`	Metadati di stato di Hype Train/Treasure Train
`user_banned`	Un utente è stato bannato o messo in timeout

OBS Flow Actions

Implementazione: actions.html tramite gli eventi OBS WebSocket v5, con dock.html Eventi della sorgente browser OBS come ripiego

Mantieni aperto l'overlay Flow Actions con la stessa sessione Social Stream dell'editor Event Flow/background, oppure mantieni il dock caricato in OBS.
Configura OBS WebSocket v5 su OBS 28+; l'URL predefinito è ws://127.0.0.1:4455.
Sono eventi di sistema di Event Flow. Non includono chatname oppure chatmessage, e i dettagli OBS aggiuntivi restano dentro meta.

Evento	Quando si attiva	Note sul payload
`stream_started`	OBS segnala che l'output della diretta ha raggiunto lo stato avviato.	`type` è `obs`; `event` è `stream_started`; `meta.source` è `obs-websocket` oppure `obs-browser-source`; `meta.outputState` può contenere lo stato grezzo dell'output OBS.
`stream_stopped`	OBS segnala che l'output della diretta ha raggiunto lo stato arrestato.	`type` è `obs`; `event` è `stream_stopped`; `meta.outputActive` può essere `false`.
`recording_started`	OBS segnala l'avvio della registrazione.	`type` è `obs`; `meta.obsEvent` identifica la sorgente dell'evento OBS.
`recording_stopped`	OBS segnala l'arresto della registrazione.	`type` è `obs`; `meta.outputState` può contenere lo stato grezzo WebSocket.
`scene_changed`	OBS cambia la scena attiva del programma.	`type` è `obs`; `meta.sceneName` contiene il nome della scena quando OBS lo fornisce.
`media_ended`	Un input multimediale OBS termina la riproduzione.	`type` è `obs`; `meta.inputName` e `meta.inputUuid` identificano l'input multimediale.
`replay_buffer_saved`	OBS salva il buffer di replay.	`type` è `obs`; `meta.savedReplayPath` può contenere il percorso del replay salvato.

Riquadro avvisi Streamlabs

Implementazione: sources/streamlabs.js (DOM del riquadro avvisi); bridge socket facoltativo in sources/websocket/streamlabs.html

Mantieni aperto il riquadro avvisi Streamlabs in una scheda o sorgente browser per renderizzare gli avvisi; il content script legge messaggi, immagini e token dal DOM degli avvisi.
Gli avvisi in stile donazione impostano hasDonation (ad esempio, “$10 USD” o “100 bits”) e il facoltativo donoValue in USD.
Tipi di evento dedotti: follow, subscription, gift, cheer, donation, superchat, raid, redeem, merch, sponsor.
Per il bridge socket, incolla il token Socket API di Streamlabs e connettiti; gli avvisi vengono inoltrati senza la pagina del riquadro avvisi.

Evento	Quando si attiva	Note sul payload
`donation`	Mance, beneficenza, JustGiving o avvisi generici di donazione.	`hasDonation` mantiene il testo della valuta (ad es. “$36” o “$10 CAD”); `donoValue` viene fornito solo quando è disponibile un valore in USD; gli altri importi etichettati usano la conversione valuta condivisa.
`cheer`	Avvisi Twitch di bit/cheer.	`hasDonation` diventa “100 bits” e `donoValue` acquisisce il valore in USD.
`subscription`	Avvisi sugli abbonamenti.	Campi standard impostati; `chatmessage` è la riga dell'avviso; `meta.tokens` contiene i valori suddivisi in token (name, amount, levelName, ecc.).
`gift`	Abbonamenti regalati.	`meta.tokens.amount` può mostrare il numero di regali; `meta.tokens.levelName` può contenere il livello.
`follow`	Avvisi sui follower.	Nessun campo donazione; `chatname` rispecchia il token del nome dell'avviso.
`raid`	Avvisi di raid.	`meta.tokens.count` contiene il numero di partecipanti al raid quando presente.
`redeem`	Avvisi di riscatto Cloudbot.	`meta.tokens.product` acquisisce l'articolo riscattato.
`merch`	Avvisi di acquisto di merchandising.	`meta.tokens.product` contiene il nome dell'articolo acquistato.
`superchat`	Avvisi in stile Super Chat da YouTube o da integrazioni avvisi supportate.	`hasDonation` contiene l'importo; i consumer possono continuare ad accettare il precedente `donation` alias.
`sponsor`	Avvisi in stile sponsor/membro esposti da Streamlabs.	Campi standard; nessuna donazione a meno che il testo includa un importo.

TikTok Live – Acquisizione DOM e feed TikFinity

Implementazione: sources/tiktok.js per le pagine native TikTok e sources/tikfinity.js per il widget/iframe del feed attività TikFinity. SSApp dispone ancora di un'integrazione TikTok nativa con la copertura eventi più ampia (vedi la documentazione SSApp).

Funziona sulla pagina live del broadcaster. I banner di regali/Mi piace/follow vengono compilati solo quando la sessione è autenticata.
TikTok fornisce molti eventi tramite rilevamento DOM senza richiedere la modalità WebSocket – regali, follow, Mi piace e ingressi da attivare esplicitamente vengono acquisiti dalle righe renderizzate.
Pagine widget TikFinity su tikfinity.zerody.one/widget/activity-feed* funzionano anche. L'iframe incorporato del feed attività emette gli stessi campi canonici dei payload TikTok per chat, follow, condivisioni, regali, abbonamenti, ingressi da attivare esplicitamente e forzieri.
Non è richiesta un'ulteriore autenticazione API.
Modalità nativa SSApp aggiunge comunque eventi oltre ai percorsi di acquisizione della pagina/del widget: question_new, emote, viewer_update, e l'aggregato facoltativo likes_update.

Evento	Quando si attiva	Note sul payload
`gift`	Righe dei banner regalo o `DivGiftMessage` voci.	`hasDonation` converte in “N coins” (con ricerca del regalo come ripiego); `membership` usa il testo del badge quando disponibile.
`joined`	Notifiche di ingresso quando l'opzione globale Acquisisci gli eventi di ingresso “joined” nella diretta è abilitata.	Salta le notifiche di condivisione; `chatname` può essere vuoto per alcune stringhe di sistema.
`followed`	Messaggi di follow estratti dalle schede social.	Garantisce `chatname` esista prima di emettere.
`shared`	Righe di condivisione TikFinity.	`chatmessage` è il testo renderizzato della condivisione.
`subscribe`	Righe di abbonamento TikFinity.	`membership` viene impostato su `SUBSCRIBER`.
`envelope`	Righe dei forzieri TikFinity.	`meta.coins` e `meta.canOpen` contengono i dettagli del forziere.
`liked`	Riepiloghi delle raffiche di Mi piace attivati dalle schede social TikTok.	`chatname` è incluso quando TikTok lo espone; possono comunque essere emesse schede Mi piace anonime/di sistema. TikTok lo invia tramite il normale percorso in background. Il background instrada una copia al Reactions Overlay, poi prosegue verso il flusso principale chat/eventi solo quando `capturelikeevent` è abilitato.
`likes_update`	SSApp riceve un totale cumulativo autorevole di TikTok LIVE mentre `captureliketotals` è abilitato.	`meta` è il totale corrente intero. SSApp invia subito il primo valore, raggruppa le raffiche in al massimo un aggiornamento ogni cinque secondi, ripete l'ultimo valore circa ogni 90 secondi e invia zero quando la diretta termina. È separato dal valore specifico dello spettatore `liked` eventi.
`true` (booleano)	Trasmissioni social/di sistema generiche per le quali TikTok non fornisce un sottotipo.	Usa `chatmessage` per decidere la presentazione; il booleano `true` indica “evento di sistema – tipo sconosciuto”.

membership rispecchia i tooltip dei badge (livelli degli abbonati). La cache degli avatar mantiene chatimg valido tra gli eventi; se il DOM sopprime il colore dei moderatori, lo script svuota nameColor. Le righe regalo TikFinity impostano anche contentimg sull'icona del regalo quando disponibile. Gli aggiornamenti delle serie regalo del DOM nativo e di TikFinity includono meta.tiktokGiftStreakId, meta.tiktokGiftCount, e meta.tiktokGiftQuietMs affinché gli overlay possano raggruppare gli aggiornamenti ripetuti; gli ID delle serie precedenti sono univoci per l'istanza della pagina. I metadati del regalo possono includere anche tiktokGiftMessageId (l'ID originale del messaggio TikTok), tiktokGiftSenderId, groupId, giftId, giftName, streakable, e repeatEnd. Gli ID nativi identificano lo stesso regalo nelle diverse finestre di acquisizione; un ID gruppo diverso da zero, insieme agli ID del mittente e del regalo, identifica gli aggiornamenti cumulativi delle serie. L'acquisizione WebSocket di SSApp fornisce gli stessi campi dopo il consolidamento della serie, con count mantenuto per compatibilità. La relativa opzione donazioni viene controllata quando si inoltra ogni regalo: disabilitare le donazioni TikTok rimuove hasDonation e donoValue mantenendo l'evento regalo e i metadati. La sintesi vocale usa queste identità per raggruppare gli aggiornamenti ed eliminare i duplicati completati per un massimo di dieci minuti (cache limitata), e legge i regali TikTok come mittente, quantità e nome del regalo. I payload precedenti ripiegano sui rispettivi ID serie e testi dei messaggi esistenti; non viene dedotta alcuna identità dal solo testo del regalo. La lettura dei regali TikTok usa la lingua TTS/della voce selezionata, indipendentemente dalla lingua dell'interfaccia. I verbi degli annunci sono localizzati per inglese, spagnolo, portoghese, francese, tedesco, italiano e olandese; le altre lingue usano mittente, quantità e nome del regalo senza un verbo inglese. La sintesi vocale semplificata mantiene quel formato neutro. I nomi dei regali restano quelli forniti dalla piattaforma; questo non traduce automaticamente i cataloghi dei regali o i messaggi chat e non deduce la lingua di una diretta.

Per questi aggiornamenti delle serie, il conteggio e l'etichetta della donazione sono cumulativi: 1, 2, 3 significa tre regali, non sei. I consumer dei totali devono aggiungere solo l'incremento rispetto all'importo massimo già visto per quell'ID serie. L'acquisizione standard supporta le classi regalo precedenti e le attuali righe immagine/conteggio; entrambe mantengono event: "gift" e hasDonation. Per i prezzi sconosciuti, il numero e il nome dei regali vengono mantenuti per la visualizzazione e si usa una stima in USD di una moneta per regalo. Il valore fornito dalla sorgente donoValue ha la precedenza; i metadati del regalo renderizzato possono fornire coinsPerGift oppure diamondsPerGift prima che servano la tabella dei regali o il valore predefinito. Le stime in monete Standard/TikFinity e quelle in diamanti native di SSApp usano le rispettive conversioni esistenti; nessuna rappresenta un pagamento in denaro garantito.

Whatnot

Implementazione: sources/whatnot.js

Apri la pagina della diretta Whatnot con la chat visibile; l'acquisizione websocket esistente fornisce chat, notifiche aste/vendite, pagamenti non riusciti, raid, donazioni e aggiornamenti rapidi degli spettatori. Le istantanee di prodotti/giveaway dipendono ancora dalle sezioni DOM renderizzate nella vista della diretta.
Acquisisci eventi della diretta (Capture Stream Events) controlla gli eventi di sistema Whatnot e gli aggiornamenti dei metadati di aste/catalogo; le righe di ingresso richiedono anche Acquisisci gli eventi di ingresso “joined” nella diretta; il numero di spettatori continua a rispettare le opzioni spettatori/hype.

Evento	Quando si attiva	Note sul payload
`viewer_update`	Variazioni del numero di spettatori dagli aggiornamenti websocket della diretta, con polling DOM come ripiego.	`meta` è un numero intero di spettatori.
`donation`	Eventi websocket Whatnot di mance e contributi community boost.	`hasDonation` contiene l'importo formattato; il contesto specifico del websocket resta sotto `meta`.
`raid`	Eventi raid websocket Whatnot, incluse le risposte con attività della cronologia.	`meta.numRaiders` è incluso quando Whatnot lo fornisce.
`joined`	Righe chat il cui corpo normalizzato inizia con `joined`, quando Acquisisci gli eventi di ingresso “joined” nella diretta è abilitato.	Usa etichette evento di tipo stringa per gli avvisi di ingresso (non il booleano `true`).
`auction_update`	Quando cambia lo stato dell'asta nel piè di pagina live (testo vincitore/in vantaggio, titolo, offerte, prezzo, timer, stato venduto), spesso con aggiornamenti più rapidi grazie ai pacchetti websocket del ciclo di vita dell'asta.	Evento con soli metadati. Nessun `chatname`/`chatmessage`; i dati si trovano in `meta` (ad esempio `meta.title`, `meta.bids`, `meta.price`, `meta.timer`, `meta.status`).
`commerce_update`	Quando cambiano le sezioni del catalogo (prodotti, set sorpresa, giveaway in programma), spesso con aggiornamenti più rapidi grazie ai pacchetti websocket del ciclo di vita di giveaway/prodotti.	Istantanea con soli metadati, conteggi delle sezioni e array degli articoli sotto `meta.products`, `meta.surpriseSets`, e `meta.upcomingGiveaways`.
`auction_started`, `new_bid`, `auction_ended`, `product_sold`	Arriva la corrispondente notifica websocket dal vivo. Sono eventi individuali, separati dalle istantanee di visualizzazione esistenti.	`platform/type: "whatnot"`, testo semplice `chatname`, `userid` quando fornito, nome del prodotto in `subtitle`, e un valore in testo semplice `chatmessage` con `textonly: true`. Gli identificatori disponibili e i dettagli dell'asta si trovano sotto `meta`: `productId`, `auctionId`, `orderId`, `transactionId`, `livestreamId`, `bidId`, `bids`, `auctionEndTime`, e `status`. Facoltativo `price` è nelle unità monetarie principali, con `priceText` e `currency` quando fornito.
`payment_failed`	Arriva una notifica websocket dal vivo di pagamento non riuscito.	Gli stessi campi disponibili di acquirente, prodotto e identificatore, con `meta.paymentStatus: "failed"`. Quando solo `product.purchaserUserId` identifica l'acquirente, compila `userid` negli eventi di vendita/pagamento e il nome dell'acquirente resta vuoto. Non viene dedotto alcun acquirente da un'asta diversa o precedente.
`payment_succeeded`	Arriva una notifica websocket dal vivo di pagamento riuscito.	`meta.paymentStatus: "succeeded"`, con acquirente, articolo, ID ordine e altri campi consentiti forniti da quella notifica. Questo rimane un evento di pagamento distinto; non emette un altro `purchase` o donazione. I campi mancanti restano vuoti o omessi, anche se una vendita precedente li aveva forniti.

Gli aggiornamenti della visualizzazione aste/commercio restano istantanee basate sul DOM. Per rilevare un singolo evento websocket in Event Flow, usa Tipo di evento (avanzato), seleziona Evento personalizzato, e inserisci il suo nome esatto. Le etichette possono usare **{username}**\n{subtitle} con il peso del testo selezionato; le condizioni possono confrontare meta.paymentStatus con failed. Un esempio importabile di etichetta Whatnot è disponibile. Le impostazioni esistenti di acquisizione degli eventi della diretta si applicano comunque.

Altri campi facoltativi sono meta.catalogProductId (il campo del pacchetto product.productId), meta.parentProductId (product.parentId), meta.transactionType (il tipo di vendita di Whatnot, invariato), e meta.placeOrderErrorReason (il codice di errore dell'ordine o del pagamento fornito da Whatnot). Questi riferimenti al prodotto descrivono il catalogo o l'inserzione principale; non sostituiscono un ID ordine. La quantità in magazzino non viene considerata una quantità acquistata.

Per l'automazione dei pagamenti riusciti, imposta un Tipo di evento (avanzato) trigger su Evento personalizzato: payment_succeeded, e filtra la sorgente su Whatnot. Le condizioni e i template esistenti possono usare i campi di quell'evento userid, chatname, subtitle e meta.orderId direttamente. Non serve un acquisto memorizzato quando la notifica contiene i dettagli richiesti.

La conclusione di un'asta o un articolo contrassegnato come venduto non confermano il pagamento riuscito: queste notifiche non vengono emesse come eventi pagati purchase eventi e non impostano importi di donazione. Un evento di successo viene emesso solo per un evento ricevuto payment_succeeded notifica; l'acquisizione non interroga il completamento del pagamento e non lo deduce da una vendita. Gli altri paymentStatus valori vengono inoltrati solo quando forniti esplicitamente in un pacchetto acquisito. Gli identificatori mancanti vengono omessi; un solo ID prodotto può coprire più vendite, quindi usa un ID ordine/asta fornito per correlare le notifiche. L'acquisizione non ricorda gli acquisti e non associa gli aggiornamenti di pagamento; un flusso di lavoro di questo tipo deve essere configurato esplicitamente in Event Flow. I pacchetti duplicati ravvicinati provenienti dai due bridge di acquisizione esistenti vengono soppressi. Gli oggetti grezzi ordine/pagamento non vengono inoltrati.

eBay Live

La connessione venditore eBay di Monetizzazione richiede un servizio SSN eBay configurato e il consenso OAuth del venditore; l'acquisizione eBay Live descritta sotto è indipendente. La modalità sandbox usa URL delle inserzioni sandbox, assegna all'acquirente l'etichetta "eBay Sandbox buyer" e antepone al messaggio "Sandbox test purchase:". Gli acquisti sandbox mantengono lo stesso contratto d'acquisto e possono attivare avvisi/azioni chat abilitati durante i test. Il contratto di pagamento implementato emette event: "purchase", con type e platform impostato su ebay. Richiede un ordine pagato che corrisponda a un prodotto selezionato. id è un identificatore opaco stabile della riga d'ordine; chatname è "eBay buyer", chatmessage è testo semplice (textonly: true), subtitle è il nome del prodotto e il facoltativo contentimg è la sua immagine. meta.ebayPurchase contiene itemId, itemName, quantity, e il pubblico url. Nessuna identità dell'acquirente, dato di spedizione, hasDonation oppure donoValue è incluso. Questo differisce dagli aggiornamenti acquisiti tramite scraping di aste o scorte, che non provano un pagamento.

Implementazione: sources/ebay.js

Apri uno dei due /ebaylive/events/<id>/chat oppure /ebaylive/events/<id>/stream. Entrambi ricevono lo stesso flusso delle aste in tempo reale.
Il feed WebSocket pubblico fornisce aste, offerte, vincitori, estensioni del tempo e variazioni delle scorte; una query GraphQL di sola lettura fornisce i dettagli delle inserzioni. L'acquisizione DOM resta un ripiego quando i dati di rete non sono disponibili.
Acquisisci eventi della diretta (Capture Stream Events) controlla le istantanee dei metadati (auction_update, commerce_update); i contatori degli spettatori rispettano comunque le opzioni spettatori/hype.

Evento	Quando si attiva	Note sul payload
`viewer_update`	Quando cambia il numero di spettatori dell'evento attivo (conteggio nell'intestazione o, come ripiego, nell'indicatore dell'evento live).	`meta` è un numero intero di spettatori.
`follower_update`	Quando l'endpoint delle statistiche del venditore restituisce il numero di follower del venditore.	`meta` è un numero intero di follower. La sorgente interroga l'endpoint del venditore ogni 60 secondi; l'endpoint può comunque restituire un valore memorizzato nella cache per un massimo di 5 minuti.
`auction_update`	Quando cambiano i metadati dell'asta attiva.	Evento con soli metadati. L'acquisizione di rete imposta `meta.sourceMode` a `network` e fornisce title, price, bidder, winner, bids, timer ed endingAt. `meta.ebay` contiene eventId, listingId, il record dell'inserzione GraphQL (`listing`), inserzione corrente del socket pubblico (`eventListing`), e ultimo aggiornamento dell'asta (`update`). Questi mantengono categoria, immagini, valute, quantità, dettagli dei case break, risultati delle aste e campi temporali senza eliminare i dettagli della piattaforma. Il record GraphQL è un'istantanea recuperata; l'inserzione e l'aggiornamento del socket contengono uno stato in tempo reale più recente. La cronologia iniziale o ricevuta alla riconnessione viene integrata nell'istantanea corrente, anziché essere emessa come vecchie aggiudicazioni. La rimozione di tutte le inserzioni presentate emette `status: "idle"` con `cardCount: 0` per cancellare l'asta. Il ripiego DOM mantiene i campi della scheda del lettore o dell'anteprima evento.
`commerce_update`	Quando cambiano le sezioni delle istantanee di catalogo/eventi live.	Istantanea con soli metadati sotto `meta`. La modalità di rete include `eventId`, `navigation.viewerCount` e `playerCards` per le inserzioni attualmente presentate, ciascuna con lo stesso contenuto dettagliato `ebay` oggetto come istantanea dell'asta. Un elenco di schede vuoto elimina le inserzioni rimosse. Il ripiego DOM può includere anche `liveEvents`, `livePreview`, `currentEvent` e `upcomingEvents`.
`reaction`	Quando eBay Live renderizza un'animazione cuore/reazione.	Inviato direttamente alla destinazione dedicata alle reazioni. `meta.reactionType` è `heart`; eBay non espone un nome per utente per queste animazioni DOM.

Gli eventi dei metadati eBay omettono intenzionalmente chatname/chatmessage; gli overlay a valle devono renderizzare da data.event + data.meta soltanto.

Kick – Acquisizione DOM standard

Implementazione: sources/kick.js

Richiede una sessione autenticata per recuperare immagini dei profili e badge degli abbonati.
Rilevamento limitato degli eventi tramite corrispondenza del testo chat e badge; il conteggio spettatori funziona comunque quando l'opzione è abilitata.

Evento	Quando si attiva	Note sul payload
`gift`	Regali KICKs rilevati tramite l'immagine dello sticker e l'importo visibile della valuta Kick.	`hasDonation` contiene `N KICKs` (`1 KICK` per uno) quando l'importo visibile è disponibile; `contentimg` contiene l'immagine del regalo. Il testo esistente del messaggio viene mantenuto.
`reward`	Riscatti ricompensa (“ha riscattato …”).	`chatmessage` contiene il testo del riscatto.
`true` (booleano)	Avvisi di sistema generici che non corrispondono agli schemi di regali o ricompense.	Usa `chatmessage` per decidere la presentazione; il booleano `true` indica "evento di sistema – tipo sconosciuto".
`viewer_update`	Interroga l'API del canale Kick ogni 30 secondi (solo quando le statistiche degli spettatori sono abilitate).	`meta` numero intero di spettatori; per abbonamenti, follow o mance usa il bridge Kick sotto.

Kick – Websocket/Bridge

Implementazione: sources/websocket/kick.js con funzioni di supporto condivise sotto providers/kick/core.js

OAuth tramite il bridge Social Stream Kick. Gli ambiti attuali sono user:read, channel:read, channel:write, channel:rewards:read, chat:write, events:subscribe, moderation:ban, moderation:chat_message:manage, e kicks:read. I token vengono aggiornati automaticamente.
L'attivazione dei webhook Kick può richiedere diversi minuti; l'interfaccia elenca le sottoscrizioni attive per ciascun canale.

Evento	Quando si attiva	Note sul payload
`message`	Payload chat del bridge.	`meta.plainText` contiene il messaggio in testo semplice (che può comunque includere emoji); i badge uniscono piattaforma e cache dei profili. Le risposte nei thread compilano `initial`, `reply`, e `meta.reply` quando sono disponibili i dettagli della risposta o un messaggio principale nella cache.
`reward`	`channel.reward.redemption.updated`, oltre ai payload chat/sistema del bridge che sembrano riscatti.	`meta` include id della ricompensa/del riscatto, titolo, costo, stato, input utente e autore del riscatto.
`new_subscriber`	`channel.subscription.new`.	`membership` assegnato al ruolo abbonato; `meta` include { subscriber, plan }.
`resub`	`channel.subscription.renewal`.	`meta.duration` (mesi) e `meta.plan` disponibile; `subtitle` riepiloga la serie.
`subscription_gift`	`channel.subscription.gifts`.	`meta.totalGifted`, `meta.gifter`; i badge usano l'icona 💝 come ripiego.
`donation`	Eventi di supporto/mancia rilevati tramite euristiche sul tipo di evento; i regali KICKs usano `gift` sotto.	`hasDonation` contiene l'importo formattato; `meta` contiene { amount, currency, supporter, message, giftName }.
`gift`	`kicks.gifted` (regali KICKs), in linea con lo scraper DOM.	`hasDonation` contiene `N KICKs` (`1 KICK` per uno); `contentimg` contiene l'immagine del regalo quando disponibile. I dettagli strutturati del regalo restano sotto `meta`.
`raid`	Gestione della compatibilità con payload socket precedenti di tipo host, come `App\Events\StreamHostEvent`.	Il catalogo ufficiale attuale degli eventi Kick non offre sottoscrizioni raid/host. Se arriva un payload precedente compatibile, viene mappato nell'evento canonico `raid`; non basarti su questo per un flusso di lavoro Kick attuale.
`new_follower`	`channel.followed`.	Le icone dei follower derivano dalla cache dei profili; `follower_update` si attiva quando Kick fornisce i totali progressivi.
`follower_update`	Il bridge fornisce il numero di follower nei payload webhook.	`meta` totale intero; usato dalle dashboard per gli obiettivi follower.
`stream_online` / `stream_offline`	`livestream.status.updated`.	`meta` contiene il corpo grezzo dello stato di Kick (is_live, title, ecc.).
`viewer_update`	`livestream.status.updated` quando Kick include i totali degli spettatori simultanei.	`meta` numero intero di spettatori; emette `0` allo stato offline per azzerare i contatori obsoleti.
`user_banned`	`moderation.banned` dal bridge/webhook oppure dagli eventi ban del socket chat Kick.	Evento con soli metadati per i widget di moderazione. `meta` include nome utente/nome visualizzato, ID utente, avatar/URL del profilo, moderatore, motivo, durata di ban/timeout e permanenza.

Le ricerche dei profili usano profileCache; mapBadges unisce le risorse dei badge Kick con gli SVG memorizzati nella cache quando disponibili. Quando Kick segnala donazioni in KICKs, il bridge le converte in hasDonation più meta.amount con currency ripiega su "KICKs". I payload chat includono meta.messageId quando il bridge espone un ID messaggio nativo Kick, affinché la sincronizzazione delle eliminazioni possa individuare il messaggio corretto. I payload delle risposte includono meta.reply con il principale messageId, author, e text quando noto. I dettagli forniti della risposta restano disponibili anche quando il messaggio originale non è nella cache; una risposta con il solo ID, senza contesto memorizzato, può comunque non avere una citazione visibile.

Kick Websocket: riferimento rapido degli eventi

`data.event`	Scenario
`new_follower`	Un utente ha seguito il canale
`new_subscriber`	Nuovo abbonamento
`resub`	Rinnovo dell'abbonamento
`subscription_gift`	Abbonamenti regalati
`reward`	Riscatto ricompensa del canale o messaggio chat/sistema in stile ricompensa
`donation`	Evento mancia/supporto
`gift`	Evento regalo KICKs
`raid`	Input host/raid precedente, solo per compatibilità; non è una sottoscrizione Kick ufficiale attuale
`follower_update`	Numero totale di follower
`stream_online`	Diretta iniziata
`stream_offline`	Diretta terminata
`user_banned`	Un utente è stato bannato o messo in timeout

VPZone - WebSocket

Implementazione: sources/websocket/vpzone.js

Si connette a wss://chat.vpzone.tv/ws?channel=USERNAME; OAuth richiede profile:read, chat:read, chat:write, channel:read, channel:write, e chat:moderate. È possibile fornire manualmente anche un bearer token.
Frame VPZone piatti come type: "msg" vengono normalizzati in payload chat standard.
Lato piattaforma delete_message / clear_chat frame rimuovono le righe corrispondenti dal dock; opzioni facoltative sincronizzano eliminazioni e blocchi dal dock a VPZone (solo proprietario del canale).
I proprietari del canale hanno un pannello Stream Info nella pagina per aggiornare titolo e categoria della diretta (lo stesso schema della pagina sorgente Twitch).

Evento	Quando si attiva	Note sul payload
`message`	VPZone `msg`, `message`, `new_message`, oppure `chat_message` frame websocket.	`chatname` proviene da `username`; `chatmessage` proviene da `body`; gli indicatori abbonato/proprietario/mod/VIP vengono copiati in `chatbadges`, indicatori di ruolo al livello principale e `meta`. Gli ID nativi compilano `data.id` e `meta.messageId`.
`viewer_update`	VPZone `presence` frame con `count` oppure un campo spettatori equivalente.	`meta` è il numero intero di spettatori dal vivo; contribuisce all'aggregato `viewer_updates`.
`new_subscriber`	VPZone `subscribe` / `subscription` frame.	`membership` viene impostato su Subscriber quando sono presenti indicatori di abbonamento.
`subscription_gift`	VPZone `gift` / `gift_subscription` frame.	Usa lo stesso nome evento per gli abbonamenti regalati di Twitch, Kick, Rumble e Velora. `subtitle` contiene il numero di regali (`x5`) o destinatario.
`message` + `hasDonation`	VPZone `system` frame con `metadata.kind: "pixels_cheer"` (mancia Pixels).	Riga chat con donazione; `hasDonation` è l'etichetta dell'importo (ad esempio `100 Pixels`), `meta.pixels` il numero intero. `event` resta vuoto; rileva questa mancia da `hasDonation`. Gli eventi di supporto del bridge Kick usano invece `event: "donation"`.
`message` risposte	VPZone `msg` frame contenente `metadata.reply_to` (ID del messaggio, autore, estratto — denormalizzati lato server).	Renderizzato come le risposte Kick: `initial` contiene l'etichetta "autore: estratto", `reply` il testo grezzo della risposta, `meta.reply` la destinazione strutturata. Rispetta l'opzione escludi “in risposta a” impostazione.
`raid`	VPZone `raid` frame con `metadata.kind: "incoming"`.	I frame dei raid in uscita vengono saltati; `meta.viewers` contiene la dimensione del raid quando fornita.
`shoutout`	VPZone `shoutout` frame (`!so` comando).	`meta.targetUser` indica il nome del canale promosso dallo shoutout.
`reward`	VPZone `system` frame con `metadata.kind: "channel_points_redeem"`.	Riscatto punti canale, con lo stesso nome evento delle ricompense Twitch.
`stream_online` / `stream_offline`	VPZone `system` frame con `metadata.kind: "stream_started"` / `"stream_ended"`.	Attribuito al nome del canale (i frame non contengono alcun attore).
`new_follower`	VPZone `follow` frame.	Mappato nella struttura standard dell'evento follower.
`joined`	Eventi websocket VPZone di ingresso/presenza, quando Acquisisci gli eventi di ingresso “joined” nella diretta è abilitato.	Mappato in un evento di sistema in stile chat con metadati dell'attore VPZone sotto `meta`.

Joystick

Implementazioni: sources/joystick.js, sources/inject/joystick-ws.js, e sources/websocket/joystick.js

La normale sorgente del sito Joystick 2.0 viene eseguita sulla pagina con accesso effettuato /u/<channel>/chat pagina. Legge dalla pagina il campo ChatChannel, WhisperChatChannel, EventLogChannel, e SystemEventChannel Frame Action Cable, con ripiego sulle righe renderizzate per Electron e i casi di riconnessione.
I messaggi chat del sito usano gli stessi campi principali di YouTube, Twitch e Kick: il nativo id, chatname, chatmessage, chatimg, chatbadges, nameColor, membership, mod, private, username/userid, e timestamp quando Joystick li fornisce. Quando il socket omette il colore del nome utente, la riga renderizzata fornisce lo stesso nameColor campo usato dai dock con colori abilitati.
Le modifiche dei messaggi sul sito sostituiscono la riga corrispondente nel dock; eliminazioni, silenziamenti e blocchi rimuovono le righe corrispondenti tramite l'ID nativo o il nome utente.
La sorgente WebSocket separata usa le credenziali bot Joystick (client_id + client_secret); la sorgente del sito usa la sessione della pagina con accesso effettuato.
Autorizza su https://joystick.tv/api/oauth/authorize, poi scambia/aggiorna i token su https://api.joystick.tv/api/oauth/token.
Si connette a wss://api.joystick.tv/cable e si iscrive a GatewayChannel.
Lo scambio di token OAuth facoltativo viene usato per endpoint di supporto come https://api.joystick.tv/api/users/stream-settings.
La sorgente separata con credenziali bot non emette viewer_update. La sorgente del sito con accesso effettuato emette il numero di spettatori quando il socket della pagina lo fornisce, come descritto sotto.

Evento	Quando si attiva	Note sul payload
`message`	Joystick `ChatMessage`, `BotMessage`, `new_message`, `bot_message`, `event_bot_message`, `pvp_message`, e messaggi privati.	La chat normale non ha `event`. L'ID nativo viene inserito al livello principale in `id` e `meta.messageId`; i ruoli e lo stato privato usano i campi esistenti al livello principale/per i badge.
`new_follower`	Joystick `StreamEvent` con tipo `Followed`.	Usa la struttura standard dei follower e viene deduplicato rispetto alla corrispondente riga bot di Joystick. Facoltativo `meta.userId`/`meta.followedAt` sono inclusi solo quando Joystick li fornisce.
`new_subscriber` / `subscription_gift`	Tipi di evento Joystick `NewSubscription` / `GiftedSubscription`.	Usa le chiavi dei metadati di abbonamento compatibili con Kick: `eventType`, `subscriber`, `gifter`, `totalGifted`, `duration`, e `plan`.
`donation`	Joystick `StreamEvent` tipi `Tipped` / `TipMenu`.	`hasDonation` contiene l'importo e l'unità dei token per la conversione USD condivisa, quando disponibili, e la corrispondente riga bot Joystick viene deduplicata. `meta` usa le chiavi esistenti degli eventi di supporto Kick: `eventType`, `supporter`, `amount`, `currency`, `message`, `giftName`, `giftType`, e `tier`.
`stream_online` / `stream_offline`	Joystick `StreamEvent` tipi come `Started`, `StreamResuming`, `Ended`, `StreamEnding`.	Usato per le automazioni online/offline che tengono conto del trasporto.
`user_enter` / `user_leave`	Joystick `UserPresence` tipi `enter_stream` / `leave_stream`.	Le notifiche di presenza vengono emesse come messaggi evento e possono essere soppresse dalle impostazioni per nascondere gli eventi. Queste impostazioni sopprimono anche gli eventi della diretta diversi dalle donazioni.
`viewer_update`	La sorgente del sito con accesso effettuato riceve `ViewerCountUpdated` tramite `EventLogChannel`.	Usa un intero semplice `meta`, in linea con YouTube, Twitch e Kick. Emesso solo quando è abilitata la modalità conteggio spettatori o hype. La sorgente separata con credenziali bot continua a non ricevere il numero di spettatori.
`follower_update` / `subscriber_update`	Eventi Joystick di aggiornamento del numero di follower/abbonati.	Usa un intero semplice `meta`, in linea con il contratto del contatore Twitch.
Notifiche interne ignorate	`ChatMessageReceived`, stato del dispositivo e aggiornamenti di widget non mappati, come lo stato degli obiettivi mance/PvP/subathon.	Sono notifiche del trasporto o dello stato della pagina, non eventi Social Stream. Non vengono convertite in eventi inventati `snake_case` nomi evento; il vero `ChatChannel/new_message` la riga rimane l'unico payload chat.

XP Sync

Implementazione: sources/xpsync.js

Le righe chat usano i campi canonici del payload con type: "xpsync", inclusi autore, messaggio, avatar, badge immagine e SVG incorporati, colore del nome, abbonamento, indicatori moderatore/membro/bot e l'UUID nativo del messaggio come id quando disponibile.
Le risposte seguono la convenzione delle sorgenti DOM YouTube, Twitch e Kick: a meno che i prefissi delle risposte siano disabilitati, initial contiene l'utente a cui si risponde, reply mantiene il messaggio senza prefisso, e chatmessage riceve il prefisso visibile della risposta.
Le righe evidenziate con Sparks vengono acquisite anche se XPSync le renderizza senza la normale classe delle righe chat o l'ID del messaggio; l'importo visibile viene esposto tramite hasDonation come N Sparks.
Quando l'acquisizione eventi è abilitata, le righe che contengono “just followed” o “followed the channel” emettono event: "new_follower".
Quando il conteggio spettatori è abilitato, il dock chat permanente emette event: "viewer_update" dal conteggio del video live già caricato dalla pagina XPSync e lo aggiorna tramite gli aggiornamenti della pagina live di XPSync. Non sono richieste credenziali SSN separate.

Instagram – Acquisizione Live REST e casella delle attività

Implementazione: sources/instagram.js e sources/instagramlive.js (copie identiche)

Nelle pagine della diretta (/<user>/live/?broadcast_id=...), la chat dal vivo proviene dall'API web di Instagram, interrogata periodicamente dalla stessa origine con il cookie di sessione: GET /api/v1/live/{broadcast_id}/get_comment/?last_comment_ts={ts} ogni ~2 s, e POST /api/v1/live/{broadcast_id}/heartbeat_and_get_viewer_count/ ogni ~5 s quando il conteggio spettatori è abilitato. Dopo 3 errori consecutivi (o quando nessun broadcast_id è individuabile) la sorgente ripiega sull'analisi del DOM della chat renderizzata.
Il feed attività dell'account viene interrogato tramite POST /api/v1/news/inbox/ ogni ~45 s su qualsiasi pagina Instagram. Il primo polling inizializza soltanto l'insieme di deduplicazione, quindi la cronologia non viene mai riprodotta; le notizie vengono deduplicate per tuuid.
Intestazioni API richieste (tutte statiche/ricavabili): X-IG-App-ID: 936619743392459, X-CSRFToken (dal cookie), X-ASBD-ID: 359341, X-Requested-With: XMLHttpRequest, Content-Type: application/x-www-form-urlencoded.
Tutti gli eventi del feed attività usano type: "instagram"; la chat dal vivo rimane type: "instagramlive". Gli eventi Mi piace usano il normale percorso in background: il background invia una copia al Reactions Overlay dedicato, poi li include nel flusso principale chat/eventi solo quando capturelikeevent è abilitato, in linea con TikTok e MeetMe. hideevents e il filtro eventi personalizzato li bloccano ovunque. Poiché gli eventi della casella attività appartengono all'account connesso, vengono soppressi quando si guarda la diretta di qualcun altro (sia /<user>/live/ pagine e dirette nel visualizzatore delle storie; la proprietà viene determinata per profilo e la ricerca viene ritentata dopo gli errori) ed emessi nella tua diretta e in tutte le pagine non live. Una sola scheda Instagram attiva alla volta interroga la casella attività dell'account, e il polling avviene solo con accesso effettuato.

Evento	Quando si attiva	Note sul payload
`message` (in diretta)	Nuove voci nel `get_comment` risposta (`comments[]`/`system_comments[]`), oppure nuove righe della chat nel DOM quando REST non è disponibile.	Payload chat standard, `type: "instagramlive"`. REST fornisce il valore esatto `user.username`, `user.profile_pic_url`, e un identificatore univoco `pk` usato per la deduplicazione.
`viewer_update`	`heartbeat_and_get_viewer_count` segnala un valore cambiato `viewer_count`, quando sono abilitati il rilevamento del numero di spettatori o la modalità hype.	`meta` numero intero di spettatori. Il polling si arresta quando `broadcast_status` non è più `"live"`.
`stream_online` / `stream_offline`	`stream_online` si attiva una volta all'avvio di una sessione di trasmissione REST; `stream_offline` si attiva quando l'heartbeat segnala un valore non live `broadcast_status` (richiede il rilevamento del numero di spettatori o la modalità hype).	Eventi con soli metadati coerenti con il vocabolario condiviso dello stato della diretta usato da Twitch e Joystick.
`new_follower`	Una notizia nella casella delle attività con un tipo follow `notif_name` (oppure `story_type 12`) compare.	`chatname` è il nuovo follower, `chatimg` la sua immagine del profilo, `chatmessage` il testo della casella attività (ad esempio "x ha iniziato a seguirti.").
`follow_request`	Un `private_user_follow_request` compare una notizia (gli account privati ricevono richieste anziché follow diretti).	Stessa struttura di `new_follower`, mantenuti distinti affinché le automazioni possano approvare le richieste o salutare in modo diverso.
`liked`	Una notizia nella casella delle attività con un tipo Mi piace `notif_name` (incluso `comment_like`) compare.	Vocabolario dei Mi piace condiviso con TikTok/MeetMe. `chatname` è l'attore, `chatmessage` il testo della casella attività (ad esempio "x ha messo Mi piace alla tua foto.").
`message` (commento sul proprio post)	Una notizia nella casella delle attività con un tipo commento `notif_name` compare.	Riga chat normale (`event: false`), `type: "instagram"`; `chatmessage` contiene il testo della casella attività, incluso l'estratto del commento.
`notification`	Qualsiasi altro tipo di notizia nella casella delle attività (menzioni, tag, shopping e così via).	Categoria generica per tutti gli altri casi; `meta.notifName` e `meta.storyType` mantengono la classificazione grezza della notizia.

Facebook Live

Implementazione: sources/facebook.js (scraping del DOM) e bridge Graph API facoltativo in sources/websocket/facebook.html

L'acquisizione DOM legge i commenti Facebook renderizzati; il bridge Graph API per le Pagine gestite legge i commenti del video. Entrambi usano type: "facebook", i campi chat standard e nessun event per i normali commenti. Il bridge API include anche il facoltativo platform: "facebook".
Il bridge API usa userid per l'ID dell'autore quando disponibile, timestamp per un'ora di creazione valida in millisecondi Unix, e contentimg per un'immagine allegata HTTP(S) fornita dall'API. I commenti con la sola immagine possono avere vuoto il campo chatmessage. textonly si applica solo al corpo del messaggio: testo grezzo quando true, HTML con escape quando false.
Il contesto dei commenti API usa meta.messageId (ID nativo del commento), meta.permalink, meta.videoId, e meta.pageId. Le build API precedenti usavano meta.commentId, campi autore/ora duplicati sotto meta, e vi passava gli allegati grezzi. Le nuove build usano invece i campi standard per autore, ora e contenuti multimediali; questo non aggiunge il supporto alla sincronizzazione delle eliminazioni.
Il numero di spettatori si aggiorna solo quando abilitato. Il bridge API legge i valori simultanei live_views; non sostituisce il dato con le visualizzazioni cumulative del video e non inventa uno zero quando il conteggio non è disponibile. L'acquisizione API non deduce Stars, abbonamenti, evidenziazioni o risposte dal testo dei normali commenti.
Le Stars vengono acquisite dal DOM della chat dal vivo renderizzata quando Facebook mostra l'elemento visibile N sent indicatore; compilano hasDonation e donoValue al tasso di 100 Stars = $1 USD senza impostare data.event.
Per i test, aggiungi ssnreplay=1 all'URL Facebook Live per elaborare le righe chat già visibili dopo l'aggiornamento.

Evento	Quando si attiva	Note sul payload
`viewer_update`	Il DOM interroga il badge degli spettatori dal vivo; il bridge API interroga gli spettatori simultanei della diretta quando abilitato.	`meta` numero intero di spettatori, coerente con le altre sorgenti. I conteggi mancanti o non interpretabili vengono saltati; uno zero effettivo è valido.
`hasDonation`	Facebook Stars renderizzate nel DOM della chat dal vivo.	Payload chat standard; `hasDonation` contiene l'importo Stars visibile, come `100 Stars`, e `donoValue` contiene il valore in USD. Le Stars non impostano `data.event`.
`highlightColor`	Facebook renderizza un elemento visibile `HIGHLIGHTED` etichetta.	Usa i normali campi chat e `highlightColor`; nessun `data.event` è impostato. Le Stars usano ancora `hasDonation`.

Online Church

Implementazione: sources/onlinechurch.js

Si basa sullo scraping DOM della chat pubblica e dell'intestazione multimediale.
Il numero di spettatori si aggiorna solo quando Mostra il numero di spettatori oppure la modalità hype è abilitata.

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove voci sotto `#publicchat`.	Payload chat standard con nome del mittente, avatar, badge ed etichetta facoltativa dell'abbonamento, quando presente nel DOM.
`viewer_update`	Interroga il badge delle presenze dal vivo nell'intestazione multimediale ogni 10 s.	`meta` numero intero di spettatori; invia `0` quando il badge manca o è illeggibile, per azzerare i contatori obsoleti.

SharePlay.tv

Implementazione: sources/shareplay.js

Si basa sullo scraping DOM del pannello chat dal vivo nelle pagine dei canali SharePlay.
Dopo il collegamento dello scraper vengono emesse solo le righe chat e le schede appena inserite; la cronologia esistente viene ignorata intenzionalmente.

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe nel feed chat principale.	Payload chat standard con autore, avatar, immagini dei badge ed emoticon con HTML mantenuto. Le risposte nei thread compilano anche `initial`, `reply`, e `meta.reply` quando la riga principale è ancora presente.
`raid`	SharePlay inserisce una scheda Blitz nel feed della chat dal vivo.	Mappato nell'evento raid canonico. `meta.cardType` è `"blitz"`, con il facoltativo `meta.fromLogin` e `meta.viewers` quando il testo della scheda li espone.
`shoutout`	SharePlay inserisce una scheda shoutout/follow nel feed chat.	Emesso come `data.event = "shoutout"`. L'immagine del banner della scheda viene inoltrata tramite `contentimg`, mentre `meta.cardType` e `meta.action` mantengono l'etichetta della scheda/il testo del pulsante.
`viewer_update`	Interroga il badge spettatori visibile nell'intestazione ogni 10 s.	`meta` numero intero di spettatori; emesso solo quando Mostra il numero di spettatori oppure la modalità hype è abilitata, e invia `0` se il badge diventa illeggibile, per azzerare i contatori obsoleti.

Streamplace

Implementazione: sources/streamplace.js

Legge la pagina live di Streamplace renderizzata con React e salta la cronologia chat visibile al momento del collegamento.
I messaggi in stile relay come Name (Discord): message vengono normalizzati nel nome del mittente inoltrato.

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe chat Streamplace dopo il collegamento.	Payload chat standard con `nameColor`, `chatbadges`, link con HTML mantenuto e campi di risposta `initial`, `reply`, e `meta.reply` quando visibile.
`viewer_update`	Il badge spettatori nell'intestazione cambia mentre è abilitata l'acquisizione del numero di spettatori o la modalità hype.	`meta` numero intero di spettatori.

WorldsWave

Implementazione: sources/worldswave.js

Supporta le pagine live di WorldsWave e gli URL con la sola chat, come https://worldswave.com/kn_livecmd.php?cmd=viewStream&streamId=STREAM_ID&chatonly=1.
Usa l'identificatore stabile data-ww-*/ww-chat-* markup quando disponibile, mantenendo i selettori kontackt precedenti per le pagine con la sola chat e i layout meno recenti.
La cronologia chat esistente viene saltata all'avvio dell'acquisizione; esegui il test con un nuovo messaggio.
Il conteggio degli spettatori richiede Mostra il numero di spettatori oppure la modalità hype. Gli eventi dedicati di regalo/mancia e l'invio di risposte non sono implementati. Una riga renderizzata può comunque fornire un'etichetta di donazione tramite data-ww-donation.

Evento	Quando si attiva	Note sul payload
`message`	Compare una nuova riga chat renderizzata di WorldsWave.	Payload chat standard con `type: "worldswave"`, nome del mittente, avatar, ID utente facoltativo, colore del nome, badge, stato di moderatore, abbonamento, valore della donazione, allegato e identità del canale. Gli ID stabili dei messaggi WorldsWave sono esposti come `meta.messageId` e deduplicati tra pannelli di anteprima e chat completa simultanei. Le immagini in linea dei messaggi restano sanificate quando la modalità solo testo è disabilitata.
`viewer_update`	Il totale visibile degli spettatori dal vivo cambia mentre è abilitata l'acquisizione del numero di spettatori o la modalità hype.	`meta` è il numero intero di spettatori. L'identificatore stabile `data-ww-viewer-count` valore è preferito; i valori compatti precedenti come `1.2K` vengono normalizzati come ripiego.

FLEX TV

Implementazione: sources/flextv.js

Legge il pannello chat renderizzato su https://www.flextv.co.kr/channels/*/live pagine.
Il pannello chat deve essere visibile. La cronologia chat esistente viene saltata quando la sorgente si collega, quindi esegui il test con una nuova riga chat.
Per questa sorgente non è ancora documentato un percorso per conteggio spettatori, donazioni o invio di risposte.

Evento	Quando si attiva	Note sul payload
`message`	Nuovo elemento FLEX TV visibile `.chat-item` righe compaiono nel feed della chat dal vivo.	Payload chat standard con `type: "flextv"`, `chatname`, `chatmessage`, `nameColor`, immagini dei badge in `chatbadges`, e i dettagli dei membri FLEX sotto `meta` quando esposto da `data-member`.

Seal Team Sloth

Implementazione: sources/sealteamsloth.js

Legge la chat renderizzata in finestra separata su https://sealteamsloth.com/popout-chat/* pagine.
Il conteggio degli spettatori richiede Mostra il numero di spettatori oppure la modalità hype.

Evento	Quando si attiva	Note sul payload
`message`	Compare una nuova riga chat renderizzata di Seal Team Sloth.	Payload chat standard con `type: "sealteamsloth"`, nome del mittente, avatar e contenuto del messaggio.
`viewer_update`	Il totale visibile degli spettatori dal vivo cambia mentre è abilitata l'acquisizione del numero di spettatori o la modalità hype.	`meta` è il numero intero di spettatori; i valori compatti come `1.2K` vengono normalizzati.

MeetMe - Acquisizione DOM e WebSocket

Implementazione: sources/meetme.js

Legge il DOM della chat dal vivo renderizzata di MeetMe su app.meetme.com/live/view/... pagine e all'interno del api.gateway.meetme-live.com/web-live/... iframe.
Quando il websocket dell'iframe è disponibile, wss://video-live.meetme.com/ frame vengono analizzati prima del ripiego DOM per acquisire eventi dal vivo più completi.
hideevents sopprime gli eventi diversi dalle donazioni; regali MeetMe e donazioni in diamanti compilano comunque i campi donazione. capturejoinedevent abilita gli avvisi di ingresso/ritorno. I valori specifici dell'attore liked eventi usano l'instradamento condiviso in background controllato da capturelikeevent; aggregato reaction effetti restano destinati esplicitamente al Reactions Overlay.
Il conteggio degli spettatori preferisce il numero visibile nell'intestazione MeetMe, usando i totali websocket solo quando il numero DOM non è disponibile. I conteggi vengono emessi quando cambiano e ripetono l'ultimo valore circa ogni 30 secondi mentre showviewercount/hypemode è abilitato; i totali dei follower vengono inviati solo quando cambiano e con una frequenza massima di circa 60 secondi.

Evento	Quando si attiva	Note sul payload
`message`	Nuovo `SNSChatMessage` arrivano frame websocket, oppure nuovi `ChatMessage_` Le righe DOM compaiono sotto `ChatHistoryContainer_`.	Payload chat standard con nome del mittente, avatar, HTML/testo del messaggio e immagini/testo dei badge. I dettagli della riga DOM sono campi piatti `meta` chiavi, incluse `messageId`, `roomId`, `level`, `levelColor`, `badgeLabels`, `badgeSrcs`, `badgeClasses`, `isBouncer`, `isTopStreamer`, `isBestOfTheWeek`, `rank`, e `rowClassName`. I payload websocket impostano `meta.source = "websocket"`.
`joined` / `rejoined` / `left`	`SNSChatParticipant` arrivano frame websocket di creazione, aggiornamento o eliminazione, oppure MeetMe renderizza un elemento DOM `join-cell` riga. Gli avvisi di ingresso/ritorno richiedono Acquisisci gli eventi di ingresso “joined” nella diretta.	Emette avvisi di sistema in stile chat con nome/avatar dell'attore quando MeetMe li espone. `meta.isNewViewer`, `meta.viewerLevelId`, `meta.isBouncer`, e `meta.isSubscriber` mantengono lo stato dei partecipanti.
`new_follower`	MeetMe renderizza una riga DOM di preferito/follow come `Favorited`.	Usa il vocabolario condiviso dell'evento follower. `chatname` è l'attore, `chatimg` è la foto del profilo rilevata quando disponibile, e i campi piatti `meta.favoriteText`/`meta.targetName` mantengono i dettagli originali della riga.
`gift`	`SNSGiftMessage` arrivano frame websocket, oppure MeetMe renderizza l'immagine di un regalo in una riga chat.	`hasDonation` contiene l'etichetta visibile del regalo o il valore in diamanti, `contentimg` contiene l'immagine del regalo quando esposta, e chiavi piatte come `meta.giftName`, `meta.giftCount`, `meta.amount`, e `meta.currency` mantengono i dettagli strutturati. Il `gift` è riservato ai frame/alle righe di regali effettivi; il rendering delle donazioni deve comunque basarsi su `hasDonation`.
`donation`	`SNSDiamond` frame websocket espongono l'attività dei diamanti.	I frame diamond dedicati vengono trattati come eventi di donazione. `hasDonation` è formattato in diamanti per la conversione USD condivisa, e `meta.amount`/`meta.currency` restano piatti per le automazioni.
`liked` / `reaction`	`SNSLike` arrivano frame websocket.	I Mi piace attribuiti a un attore usano lo stesso `liked` vocabolario e instradamento centralizzato in background di TikTok. I totali aggregati/anonimi dei Mi piace vengono inviati solo alla destinazione delle reazioni come `reaction`, con valori piatti `meta.reactionType`, `meta.totalLikes`, e `meta.subscriberLikes`. La distinzione riguarda il significato dell'evento, non l'anonimato: `capturelikeevent` controlla solo i singoli `liked`/`like` eventi.
`follower_update`	`SNSVideo` i metadati websocket espongono i totali dei follower.	`meta` è il numero intero di follower, coerente con la convenzione condivisa degli eventi contatore.
`guest_update`	`SNSVideoGuestBroadcast` arrivano frame di creazione/aggiornamento.	Evento con soli metadati per lo stato ospite/cohost della diretta. I campi piatti `meta` chiavi includono `status`, `position`, `totalGuests`, `isMuted`, `guestBroadcastId`, `videoViewerId`, e `broadcastId`.
`viewer_update`	Il badge spettatori visibile nell'intestazione cambia, oppure `SNSVideo` i metadati websocket espongono i totali degli spettatori quando il badge non è disponibile; i totali invariati vengono ripetuti circa ogni 30 secondi quando abilitati.	`meta` numero intero di spettatori; emesso solo quando è abilitata l'acquisizione del numero di spettatori o la modalità hype.

Velora

Implementazione: sources/velora.js e sources/websocket/velora.js

La modalità standard legge il DOM della chat visibile; la modalità WebSocket usa la Velora Events API con OAuth.
Gli URL supportati in modalità standard includono https://velora.tv/*, https://velora.tv/dashboard/stream/popout?panels=chat%2Cactivity&channel=CHANNEL&layout=vertical, e https://velora.tv/dashboard/stream/popout/CHANNEL/obs-chat.
Le schede Volts e quelle dei punti canale vengono emesse come payload evento quando sono esposte dal DOM o dall'API Events.

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe chat Velora o arrivano messaggi chat dall'API Events.	Payload chat standard con badge, colore dell'autore, link ed emoticon mantenuti quando non è attiva la modalità solo testo.
`volts`	Schede Volts di Velora o `channel.volts` Arrivano payload dall'API Events.	`hasDonation` contiene l'importo Volts visualizzato; le acquisizioni DOM includono `meta.source = "dom"`.
`channel_points`	Schede di punti canale/riscatto di Velora o `channel.channel_points_redemption` Arrivano payload dall'API Events.	`chatmessage` contiene il messaggio del riscatto o il titolo della ricompensa; `meta.rewardTitle` identifica la ricompensa quando disponibile.
`subscription`	Una riga attività Velora visibile indica che un utente è diventato membro/abbonato del canale.	`membership` contiene l'etichetta visibile dell'abbonamento.
`viewer_update`	Il numero di spettatori visibile cambia mentre è abilitata l'acquisizione del numero di spettatori o la modalità hype.	`meta` numero intero di spettatori.

Parti - Acquisizione chat del profilo / finestra separata

Implementazione: sources/parti.js

Supporta URL dei profili come https://parti.com/USERNAME e URL di finestre separate come https://parti.com/popout-chat?id=USER_ID.
Il conteggio degli spettatori usa l'endpoint heartbeat delle dirette Parti quando è abilitata l'acquisizione del numero di spettatori o la modalità hype.

Evento	Quando si attiva	Note sul payload
`message`	Le righe chat Parti visibili compaiono nel flusso chat del profilo o della finestra separata.	Payload chat standard; `nameColor` mantiene il colore dell'autore renderizzato da Parti e `chatmessage` mantiene il contenuto in linea a meno che la modalità solo testo sia abilitata.
`donation`	Le righe visibili delle mance Parti indicano che un utente ha lasciato una mancia di un certo importo.	`hasDonation` contiene l'importo visualizzato, `meta.amount`/`meta.currency` vengono compilati quando interpretabili, `meta.amountText` mantiene il testo grezzo dell'importo, e `donoValue` viene impostato per le mance in USD.
`viewer_update`	L'heartbeat di Parti restituisce il numero di spettatori dal vivo.	`meta` è il numero intero di spettatori; la pagina riutilizza un solo token heartbeat per ogni finestra sorgente, per evitare di gonfiare i conteggi.

CHZZK - Acquisizione chat in finestra separata

Implementazione: sources/chzzk.js

Supporta https://chzzk.naver.com/live/*/chat e https://chzzk.naver.com/iframe/live/*/chat.
Il conteggio degli spettatori usa l'endpoint di polling dello stato live di CHZZK quando è abilitata l'acquisizione del numero di spettatori o la modalità hype.

Evento	Quando si attiva	Note sul payload
`message`	Le righe chat CHZZK visibili compaiono nel flusso della chat in finestra separata.	Payload chat standard con `type: "chzzk"`, `nameColor`, URL delle immagini dei badge in `chatbadges`, e le emoticon renderizzate in `chatmessage` a meno che la modalità solo testo sia abilitata.
chat con `hasDonation`	Le righe visibili delle donazioni cheese di CHZZK compaiono in chat.	`hasDonation` contiene l'importo cheese visualizzato. Queste righe non impostano `data.event`.
`viewer_update`	Il polling dello stato della diretta restituisce un numero di spettatori.	`meta` è il numero intero di spettatori.

Rumble - Acquisizione DOM standard

Implementazione: sources/rumble.js

Richiede cookie di sessione autenticati affinché il service.php l'API spettatori risponde.
Le righe Rant renderizzate forniscono hasDonation; le schede dei raid in arrivo forniscono event: "raid". Questa sorgente DOM non emette il flusso di eventi abbonati/follower del bridge API.

Evento	Quando si attiva	Note sul payload
`message`	Le righe chat Rumble visibili compaiono nella chat della pagina o del popup.	Payload chat standard; `chatmessage` mantiene l'HTML delle immagini delle emoticon Rumble dopo il rendering della pagina, a meno che la modalità solo testo sia abilitata.
`viewer_update`	Chiama l'endpoint di Rumble `video.watching-now` servizio ogni 30 s.	`meta` numero intero di spettatori; usa `credentials: 'include'` per riutilizzare i cookie di sessione.
chat con `hasDonation`	Una riga Rant visibile contiene un prezzo.	`hasDonation` mantiene il prezzo renderizzato; non viene aggiunto alcun indicatore di evento donazione.
`raid`	Una scheda di raid in arrivo compare in chat.	Usa il messaggio di raid visibile e l'immagine facoltativa della scheda in `contentimg`.

Rumble - Websocket/URL API

Implementazione: sources/websocket/rumble.js

Richiede l'URL Live Stream API di proprietà del creator da https://rumble.com/account/livestream-api. La documentazione Rumble indica che questo URL include la chiave della diretta, non richiede un'autenticazione separata e deve essere condiviso solo con terze parti fidate.
Trasporto di sola lettura. La documentazione pubblica della Rumble Live Stream API non descrive un endpoint ufficiale per l'invio di messaggi chat, quindi questa sorgente inoltra messaggi/eventi a Social Stream ma non invia messaggi a Rumble.
livestreams[].chat viene compilato solo mentre la diretta selezionata è live. Usa ?streamId=... per fissare una diretta specifica quando l'API ne espone più di una; gli ID non validi ora causano un errore anziché ripiegare silenziosamente su un'altra diretta.
La pagina recupera anche https://rumble.com/chat/popup/<livestreams[].id> affinché tu possa aprire direttamente la normale chat popup iniettata senza caricare prima la pagina del broadcaster /live pagina.

Evento	Quando si attiva	Note sul payload
`message`	Arrivano nuove voci dal flusso chat SSE di Rumble dopo che l'API ufficiale risolve `livestreams[].id`; ripiega su `livestreams[].chat.recent_messages`.	Payload chat standard. `meta.source` è `rumble_sse` quando il flusso chat SSE è disponibile e include gli URL degli avatar da `users[].image.1`; altrimenti ripiega su `live_stream_api` senza avatar. Quando il catalogo emoticon del popup è disponibile, `chatmessage` renderizza gli shortcode delle emoticon Rumble come HTML di immagini e `meta.plainText` mantiene il testo originale dello shortcode.
`donation`	Compaiono nuove voci Rant in `livestreams[].chat.recent_rants`.	`hasDonation` contiene l'importo formattato in USD; `meta` include `amount_cents`, `amount_dollars`, e `expiresOn`.
`new_follower`	Compaiono nuove voci in `followers.recent_followers`.	Evento di sistema con `chatname` impostato sul nome utente del follower e timestamp sotto `meta.followedOn`.
`new_subscriber`	Compaiono nuove voci in `subscribers.recent_subscribers`.	`membership` viene impostato su `SUBSCRIBER`; `subtitle` rispecchia l'importo in USD documentato quando Rumble lo fornisce.
`subscription_gift`	Compaiono nuove voci in `gifted_subs.recent_gifted_subs`.	`chatname` è chi regala, `hasDonation` diventa `N Gifted`, e `meta` include `totalGifted`, `remainingGifts`, `giftType`, e `videoId`.
`follower_update`	Ogni volta che cambia il contatore follower selezionato.	`meta` numero intero di follower. Il valore predefinito è `followers.num_followers`; con `?followerMode=total`, usa `followers.num_followers_total` quando Rumble lo fornisce.
`subscriber_update`	Ogni volta che `subscribers.num_subscribers` cambia.	`meta` numero intero di abbonati.
`stream_online` / `stream_offline`	Quando la diretta selezionata passa dallo stato live a offline o viceversa.	`meta` include un sottoinsieme sanificato dei campi della diretta (`id`, `title`, `createdOn`, etichette delle categorie, Mi piace/Non mi piace e totali degli spettatori). I valori sensibili come `stream_key` non vengono inoltrati intenzionalmente.
`viewer_update`	Ogni volta che `livestreams[].watching_now` cambia per la diretta selezionata.	`meta` numero intero di spettatori simultanei; emette `0` quando la diretta selezionata va offline, per azzerare i contatori obsoleti.

Questo trasporto è destinato ai canali che possiedi o gestisci. Poiché l'URL API contiene una chiave della diretta, non esporlo in overlay, log, screenshot o profili browser condivisi. Gli avatar della chat provengono dal flusso chat SSE di Rumble dopo che l'API ufficiale risolve l'ID della diretta; questo trasporto non esegue lo scraping delle pagine Rumble per gli avatar.

YouNow - Acquisizione DOM

Implementazione: sources/younow.js

Legge il DOM della chat dal vivo renderizzata ed emette payload chat standard con type: "younow".
Righe di attività del pubblico come is watching, I became a fan!, e invited N fans to this broadcast. sono contrassegnati con event: true affinché i filtri eventi possano instradarli.

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe nella chat dal vivo del pubblico.	Payload chat standard; le righe delle attività dei fan/del pubblico impostano `event: true`.
`viewer_update`	Il conteggio nel pannello visibile del pubblico cambia mentre `showviewercount`/`hypemode` è abilitato.	`meta` numero intero di spettatori; emette `0` quando il contatore scompare.

Favorited Studio - Acquisizione DOM

Implementazione: sources/favorited.js

Legge il DOM della chat dal vivo renderizzata ed emette payload chat standard con type: "favorited".

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe chat.	Payload chat standard.
`viewer_update`	Il conteggio nella scheda degli spettatori dal vivo cambia mentre `showviewercount`/`hypemode` è abilitato.	`meta` numero intero di spettatori letto dal `content-live-viewers` scheda.

BEAM - Acquisizione DOM

Implementazione: sources/beamstream.js

Legge il DOM della chat dal vivo renderizzata ed emette payload chat standard con type: "beamstream".

Evento	Quando si attiva	Note sul payload
`message`	Compaiono nuove righe chat.	Payload chat standard con testo semplice in `chatname`, URL dell'avatar in `chatimg`, e URL delle immagini o oggetti badge SVG in `chatbadges`. I campi nascosti nella pagina di acquisizione Beam restano vuoti. I link nativi ai profili Beam non sono considerati sorgenti relay esterne. `contentimg` può contenere allegati video/webm in linea quando esposti.
`viewer_update`	Un elemento contatore spettatori cambia mentre `showviewercount`/`hypemode` è abilitato.	`meta` numero intero di spettatori; emesso solo quando la pagina chat espone un contatore spettatori.

Castyr - Acquisizione DOM

Implementazione: sources/castyr.js

Legge le nuove righe chat renderizzate da https://castyr.live/homebeta/popout-chat/* ed emette payload chat standard con type: "castyr".
La cronologia chat esistente viene saltata quando la sorgente si collega.

Evento	Quando si attiva	Note sul payload
`message`	Un nuovo `.chat-message` compare una riga.	Payload chat standard con nome del mittente, contenuto del messaggio renderizzato e colore del nome, quando esposto.
`viewer_update`	Il conteggio visibile delle chat attive cambia mentre `showviewercount`/`hypemode` è abilitato.	`meta` è il conteggio intero letto dall'elemento delle chat attive di Castyr dotato di titolo.

SOOP - Acquisizione DOM del lettore

Implementazione: sources/sooplive.js. Supporta il formato unificato play.sooplive.com lettore e il precedente play.sooplive.co.kr URL. Il precedente layout della chat globale continua a essere riconosciuto quando viene servito.

La chat pubblica emette type/platform: "sooplive", testo semplice chatname/userid, nameColor, e il contenuto sanificato chatmessage. Sono escluse le righe esistenti, gli ID messaggio duplicati, le copie tradotte e i messaggi privati. Le emoticon diventano immagini sicure o testo alternativo in modalità solo testo.

Con showviewercount oppure hypemode abilitato, viewer_update contiene un intero meta dal campo del lettore #nAllViewer. Le finestre separate con la sola chat potrebbero non mostrare questo conteggio. SSApp usa il lettore completo quando apre una finestra separata, poiché gli attuali popout SOOP dipendono dalla finestra che li ha aperti.

Gosh - Acquisizione chat del canale

Implementazione: sources/gosh.js. Apri https://gosh.com/USERNAME con la chat visibile, oppure incolla quell'URL in Add other source di SSApp. Non è richiesta una chat in finestra separata.

Le nuove righe chat emettono type/platform: "gosh", testo semplice chatname, nameColor, e il contenuto sanificato chatmessage. Le immagini e le GIF in linea mantengono URL HTTP(S) sicuri. Con textonlymode, le immagini diventano testo alternativo o [image] quando non è disponibile testo alternativo. Avatar, badge, donazioni e abbonamenti restano vuoti quando assenti dalla riga acquisita.

Mantieni la chat virtualizzata sui messaggi più recenti. La cronologia esistente, le righe renderizzate di nuovo e gli avvisi di sistema senza autore sono esclusi. Gli indici di rendering restano interni e non vengono emessi come ID nativi dei messaggi. Non vengono dedotti eventi di follow, donazione, conteggio spettatori o moderazione.

Livacha - Acquisizione della stanza chat

Implementazione: sources/livacha.js. Apri https://livacha.com/chat/ROOM con la chat visibile, oppure incolla l'URL della stanza in Add other source di SSApp.

Le nuove righe chat emettono type/platform: "livacha", testo semplice chatname, chatimg, nameColor, e il contenuto sanificato chatmessage. Gli URL relativi degli avatar e delle immagini in linea diventano URL HTTP(S) assoluti. Paragrafi, interruzioni di riga ed elenchi vengono appiattiti in un solo messaggio chat. Con textonlymode, le immagini diventano testo alternativo o [image].

Gli ID dei messaggi vengono usati internamente per evitare di riacquisire modifiche e righe rimontate. La cronologia iniziale e i messaggi precedenti inseriti in cima vengono saltati; timestamp e menu delle reazioni restano fuori dal corpo acquisito. Non vengono dedotti eventi di donazione, abbonamento, moderazione o conteggio spettatori.

Stream.space - Acquisizione DOM sperimentale

Implementazione: sources/streamspace.js. Corrisponde solo a https://beta.stream.space/chat-popup.php?channel=USERNAME e l'equivalente https://stream.space popup.

Le nuove righe chat renderizzate emettono type: "streamspace", platform: "streamspace", testo semplice chatname/userid, chatmessage, avatar chatimg, livello rappresentato da immagini chatbadges, e nameColor. Le emoticon in linea vengono ricostruite come immagini sicure, oppure come testo alternativo quando textonlymode è abilitato. Cronologia esistente, avvisi di benvenuto, anteprime delle risposte e duplicati fissati sono esclusi.

viewer_update contiene un intero meta letto da #popupViewersNum quando showviewercount oppure hypemode è abilitato. Non vengono dedotti eventi di donazione, abbonamento o moderazione.

Sperimentale: durante la verifica il popup beta è rimasto su Loading. SSApp ha caricato il popup e acquisito gli aggiornamenti degli spettatori, ma la consegna della chat dal vivo e il popup di produzione restano non verificati. SSN non può acquisire messaggi che il sito non renderizza.

w.tv e Prime - Acquisizione DOM

Implementazioni: sources/wtv.js su https://w.tv/USERNAME/chat e sources/prime.js su https://prime.gs/USERNAME?chat_popout=1.

Le nuove righe chat usano type/platform di wtv oppure prime, testo semplice chatname, nameColor, e il contenuto sanificato chatmessage. Le emoticon in linea diventano immagini sicure o testo alternativo in modalità solo testo. Prime include anche il campo della riga userid e supporta sia i link ai profili con accesso effettuato sia le etichette dei nomi utente senza accesso. Avatar e badge restano vuoti quando non sono disponibili nella struttura verificata della riga.

La cronologia iniziale, le schede fissate e le anteprime delle risposte sono escluse. w.tv virtualizza la chat: per l'acquisizione, mantienila sui messaggi più recenti. Gli ID di test del DOM sono indici di rendering, non ID nativi dei messaggi. Prime salta la cronologia più vecchia caricata sopra i messaggi iniziali e i segnaposto degli utenti ignorati.

Nessuno dei popup espone un numero di spettatori della diretta verificato, quindi questi adattatori non emettono aggiornamenti degli spettatori e non deducono eventi di donazione, abbonamento o moderazione.

Coerenza degli eventi tra piattaforme

Usa questa tabella per capire come i concetti simili corrispondono tra le piattaforme. Quando possibile, le nuove sorgenti devono uniformarsi ai nomi evento comuni della prima colonna.

Concetto	YouTube WS	Twitch WS	Kick WS
Nuovo membro/abbonato	`sponsorship`	`new_subscriber`	`new_subscriber`
Rinnovo/riabbonamento	`resub`	`resub`	`resub`
Abbonamenti regalo	`giftpurchase`	`subscription_gift`	`subscription_gift`
Regalo ricevuto	`giftredemption`	-	-
Traguardo	`membermilestone`	-	-
Donazione/mancia	`superchat`, `supersticker`, `jeweldonation` con `hasDonation`	`cheer` (bit)	`donation`
Nuovo follower	`new_follower` (rilevati tramite polling)*	`new_follower`	`new_follower`
Numero di spettatori	`viewer_update`	`viewer_update`	`viewer_update`
Numero di follower	-	`follower_update`	`follower_update`
Numero di abbonati	`subscriber_update`	`subscriber_update`	-
Stato della diretta	`live_chat_ended`	`stream_online`/`stream_offline`	`stream_online`/`stream_offline`
Raid	-	`raid`	-
Riscatto ricompensa	-	`reward`	`reward`

Note sulla coerenza

YouTube usa sponsorship per i nuovi membri, mentre Twitch e Kick usano new_subscriber. Valuta di controllarli entrambi quando crei trigger per più piattaforme.
resub è coerente su tutte e tre le piattaforme per i rinnovi.
Gli eventi regalo differiscono: YouTube usa giftpurchase/giftredemption, mentre Twitch e Kick usano subscription_gift.
Le donazioni variano in base alla piattaforma: YouTube usa nomi specifici per gli eventi a pagamento, come superchat, supersticker, e jeweldonation con hasDonation; Twitch ha i bit (cheer); Kick ha le mance (donation).
new_follower è ora coerente su tutte e tre le piattaforme, ma YouTube interroga gli iscritti recenti e può restituire risultati ritardati o incompleti.
Mi piace e reazioni hanno contratti separati: singolo liked/like eventi raggiungono il Reactions Overlay salvo filtri globali, ed entrano nel flusso principale solo quando capturelikeevent è abilitato. Gli effetti visivi o nativi della piattaforma reaction eventi mantengono l'instradamento definito dal produttore. Gli aggregati likes_update contatori sono controllati separatamente da captureliketotals.

Copertura e limiti di compatibilità

Questo riferimento descrive i payload implementati, non garantisce che ogni piattaforma consegni ogni evento. I campi vuoti hasDonation assegnati in una sorgente non dimostrano il supporto alle donazioni. Visibilità del DOM, autorizzazioni dell'account, opzioni di acquisizione e disponibilità delle API determinano comunque ciò che viene ricevuto. L'inoltro delle eliminazioni dipende dalla sorgente; non presumere una sincronizzazione universale della moderazione.

Discrepanze e assenze rilevate

Coppia/Area	Discrepanza / assenza osservata	Effetto
Twitch: standard e websocket	Condivisi: `reward`, `subscription_gift`, `viewer_update`, `hype_train`, e il facoltativo `watch_streak`. Solo standard: `giftpurchase`, `knock`, `community_highlight`. Solo websocket: `new_subscriber`, `resub`, `cheer`, `powerup`, `raid`, `new_follower`, `follower_update`, `subscriber_update`.	`channel_points` è ora un alias precedente deprecato per i riscatti ricompensa Twitch; le nuove integrazioni devono basarsi su `reward`.
Kick: standard e websocket	La modalità standard emette indicatori leggeri (`gift`, `reward`, booleano `true`, `viewer_update`). Websocket aggiunge gli eventi ufficiali di follow, abbonamento, regalo, riscatto ricompensa, KICKs, moderazione e stato della diretta. Mantiene la compatibilità con un precedente `raid` payload, ma Kick attualmente non offre una sottoscrizione ufficiale raid/host.	La modalità websocket è più completa; le automazioni basate su nomi evento esclusivi della modalità standard devono essere riviste quando si cambia modalità. Non richiedere un evento raid Kick.
YouTube: standard e websocket	Condivisi: `superchat`, `supersticker`, `jeweldonation`, `sponsorship`, `resub`, `giftpurchase`, `giftredemption`, `viewer_update`. Solo standard: `thankyou`, `redirect`. Solo websocket: `membermilestone`, `new_follower`, `subscriber_update`, `view_update`, `likes_update` (su attivazione).	I nomi principali degli eventi e degli abbonamenti sono coerenti tra entrambi; Super Chat, Super Sticker e Jewels usano `hasDonation`, mentre gli acquisti/riscatti di abbonamenti regalati non lo fanno.
Tutte le interfacce	Molte sorgenti compilano `hasDonation` senza impostare `data.event`.	È corretto; il rendering delle donazioni deve basarsi su `hasDonation`, con `data.event` riservato alla semantica di sistema/evento.

Alias specifici delle sorgenti e nomi precedenti

Queste corrispondenze sono specifiche della sorgente/del contesto elencato, non sostituzioni globali. Il supporto degli alias da parte dei consumer varia in base alla pagina. Le attuali sorgenti DOM TikTok e TikFinity emettono ancora followed; Velora usa subscription e channel_points, e Streamlabs usa subscription. Accetta il contratto corrente della sorgente e i suoi alias precedenti pertinenti, anziché rinominare ogni evento corrispondente.

Alias / Nome precedente	Sostituzione canonica	Contesto
`subscription`	`new_subscriber`	Nuovo abbonamento Twitch/Kick
`subgift`	`subscription_gift`	Abbonamento regalato Twitch
`membership`	`sponsorship`	Nuovo membro YouTube (generico)
`new_member`	`sponsorship`	Nuovo membro YouTube
`new_membership`	`sponsorship`	Nuovo membro YouTube
`newmember`	`sponsorship`	Nuovo membro YouTube
`new-membership`	`sponsorship`	Scraper DOM YouTube (variante con trattino)
`upgraded_membership`	`resub`	Upgrade del livello YouTube
`upgraded-membership`	`resub`	Scraper DOM YouTube (variante con trattino)
`membership_upgrade`	`resub`	Upgrade del livello YouTube
`membership_milestone`	`membermilestone`	Messaggio chat di traguardo YouTube
`member_milestone`	`membermilestone`	Messaggio chat di traguardo YouTube (variante con underscore)
`gift_membership`	`giftpurchase`	Pacchetto regalo YouTube
`membership_gift`	`giftpurchase`	Pacchetto regalo YouTube
`giftmemberships`	`giftpurchase`	Pacchetto regalo YouTube (variante plurale)
`gifted_membership`	`giftredemption`	Regalo YouTube ricevuto
`gifted_memberships`	`giftpurchase`	Pacchetto regalo YouTube (variante plurale)
`community_gift`	`giftpurchase`	Pacchetto di regali alla community
`channel_points`	`reward`	Riscatto ricompensa Twitch websocket (alias precedente)
`followed`	`new_follower`	Output attuale DOM/TikFinity di TikTok; accetta entrambi i nomi quando combini le modalità di acquisizione TikTok.

Uso di questo riferimento

Quando aggiungi un nuovo evento, riutilizza il vocabolario esistente (subscription_gift, viewer_update, ecc.) quando possibile. Se una deviazione è inevitabile, documentala qui insieme alla motivazione.
Mantieni data.meta prevedibile: preferisci chiavi piatte, non sovraccaricare mai le stringhe con dati misti e includi sempre le unità (currency, bits, duration).
Aggiorna questa pagina insieme alle modifiche dei payload; aggiorna le istruzioni per gli agenti solo quando cambiano le regole di sviluppo condivise.
Verifica le modifiche ai payload sia nella sorgente che li emette sia nell'overlay o nel trigger Event Flow che li usa.
L'acquisizione dipende dal supporto e dalle impostazioni della sorgente. Per nascondere le righe contrassegnate come eventi negli overlay dock o in primo piano, aggiungi &hideevents oppure &hideallevents. Per nascondere eventi selezionati, usa &filterevents=subscription_gift,new_follower,gifted.
Per YouTube, Twitch e Kick, abilita Modalità WebSocket per il supporto più ampio agli eventi specifici della piattaforma. L'acquisizione di regali/donazioni per YouTube (inclusi regali e Super Chat) è disponibile sia in modalità Standard sia WebSocket; WebSocket aggiunge altri tipi di evento. Il supporto esatto varia comunque in base a piattaforma, ruolo dell'account e ambiti concessi.

Torna all'inizio

Overlay per la monetizzazione

Le mance NinjaBacker usano platform: "ninjabacker", type: "ninjabacker", chatname, testo semplice chatmessage, textonly: true, un identificatore con prefisso della sorgente id, formattato hasDonation, e il valore numerico donoValue. Sono normali righe in stile donazione prive di un event valore prioritario. meta.ninjabacker contiene il valore ISO currency e, nell'unità monetaria principale, amount. Le mance anonime usano il nome visualizzato Anonymous. La sorgente usa SSE dal vivo (senza riproduzione della cronologia) oppure il ricevitore webhook firmato, da attivare esplicitamente, sull'API SSN (fino a sette giorni di consegne in coda). Le consegne affidabili usano un identificatore stabile ninjabacker:delivery:DELIVERY_ID id. Nessuna modalità riceve storni per rimborsi/contestazioni. Le credenziali del ricevitore e i segreti di firma non entrano mai nei payload evento. I valori callbackId controllati dal chiamante non identificano il pagamento e non vengono inoltrati. Le mance di test della dashboard sono escluse dalle righe di donazione. Emettono event: "monetization_test" con meta.ninjabackerTest contenente id e at (millisecondi Unix), solo per l'avviso di anteprima dedicato.

event: "monetization_update" è un'istantanea con soli metadati da type/platform: "socialstream". meta.monetization.wishlist contiene enabled, qr, position, rank, total, url pubblico e l'articolo corrente (name, amount, currency, image, url pubblico) oppure null. meta.monetization.ninja contiene enabled, qr, position, username e l'url pubblico per le mance. I Tip ID privati non vengono mai inclusi. meta.monetization.ebay contiene enabled, qr, position, display (cycle/cheapest/first), seconds, impostazioni degli annunci da attivare esplicitamente e articoli pubblici. Ogni articolo ha id, name, amount, currency, image, url, auction, startingBid, endsAt, available, bought e updatedAt. I tempi sono in millisecondi Unix. Non include credenziali del venditore né identità dell'acquirente.

Un acquisto dalla lista desideri confermato dall'host include anche meta.wishlistPurchase con id, name, supporter facoltativo e at (millisecondi Unix). È una conferma dell'host, non una notifica di pagamento Amazon, e non conta come donazione monetaria. Gli overlay devono deduplicarne l'id e ignorare gli avvisi d'acquisto vecchi.

Ordini pagati Shopify

Il ricevitore Shopify firmato facoltativo emette platform/type: "shopify" e event: "purchase" solo per orders/paid con financial_status: "paid", un totale positivo, test: false, nessun annullamento e un timestamp aggiornato del corpo firmato. Le notifiche di test, non pagate, obsolete, annullate e di rimborso non emettono azioni d'acquisto. Non viene dedotto alcun intento di regalare.

chatname è Anonymous; campi del cliente, note private e URL degli ordini sono esclusi. chatmessage è testo semplice con textonly: true; subtitle contiene fino a tre titoli pubblici di prodotti. meta.commerce contiene orderTotal e currency nella valuta del negozio, più quantity quando è noto un conteggio completo valido. Destinatario e finalità fisica/digitale restano non impostati. Nessun hasDonation oppure donoValue è impostato. id è un hash opaco stabile limitato a negozio/ordine con un prefisso Shopify; non è un identificatore grezzo dell'ordine.

Gli acquisti usano i percorsi esistenti di attività, della categoria Purchase di multi-alerts e di Event Flow. La promozione dei prodotti usa l'esistente meta.monetization.commerce catalogo. Importare un prodotto o impostarne l'etichetta promozionale su Gift non genera un evento d'acquisto o di regalo. Configurazione Shopify e limiti di consegna.

Regali e commercio

Usa event: "gift" per un regalo, giftcontribution per un supporto a pagamento destinato a un regalo, giftfunded per il completamento del finanziamento, e purchase per una vendita di prodotto. Questi nomi sono indipendenti dal provider e dal fatto che un articolo sia fisico o digitale. Riserva il precedente giftpurchase evento per gli abbonamenti regalati; in precedenza Throne usava quel nome in modo errato e ora emette gift. I produttori di eventi di abbonamento esistenti restano invariati. I filtri personalizzati per i nomi degli eventi Throne devono passare a gift; i filtri delle donazioni non richiedono modifiche.

hasDonation rimane il segnale di compatibilità per il supporto a pagamento, con donoValue contenente il valore in USD fornito o stimato. Regali e contributi mantengono questi campi. Il completamento del finanziamento li omette entrambi per evitare di contare due volte i contributi. Le normali vendite di prodotti li omettono per impostazione predefinita, mantenendo il contratto eBay. Non dedurre l'intenzione di regalare da un negozio, dall'URL di una lista desideri o da un articolo fisico: un acquisto per l'acquirente o un altro destinatario rimane una vendita, a meno che la sorgente identifichi esplicitamente un regalo al creator.

Campo condiviso facoltativo meta.commerce campi sono recipient (creatore, acquirente, altro), itemType (fisico, digitale, servizio), quantity (numero positivo di articoli), currency (valuta ISO), goalAmount (obiettivo di raccolta nell'unità monetaria principale, mai un nuovo introito), e orderTotal (totale pagato dell'ordine noto, nell'unità monetaria principale; commercio, non proventi da donazioni). Ometti i dettagli sconosciuti. Mantieni i nomi degli articoli in subtitle, immagini in contentimg, e il testo del sostenitore in chatmessage. I metadati esistenti del provider restano disponibili. Throne fornisce destinatario e valuta, più goalAmount al completamento; eBay fornisce la quantità. Nessuno dei due deduce il tipo di articolo o espone informazioni private del destinatario.

Il feed attività visualizza questi eventi anche senza testo del sostenitore. Multi-alerts usa la presentazione delle donazioni per regali e contributi, inclusa una notifica distinta Gift Fully Funded senza valore monetario. Gli acquisti hanno una categoria Purchase separata, abilitata per impostazione predefinita, con purchasestyle, purchasesound, purchaseaccent, e disablepurchases controlli URL. Gli avvisi d'acquisto non modificano i totali delle donazioni.

Event Flow propone questi nomi evento nei trigger Event Type e Other Event. I trigger Donation continuano a esaminare hasDonation; i trigger Gift Sub mantengono la semantica degli abbonamenti. Compare Property accetta percorsi annidati come meta.commerce.recipient. I template delle azioni accettano {meta.commerce.quantity} e {meta.commerce.currency}, insieme agli esistenti {donation}, {subtitle}, e {meta}. I percorsi annidati distinguono tra maiuscole e minuscole, i valori mancanti vengono visualizzati vuoti e l'attraversamento del prototipo è vietato.

Webhook del commercio dei creator e overlay promozionali

I pagamenti pubblici Donation di Ko-fi mantengono hasDonation e ricevono USD donoValue. I pagamenti degli abbonamenti usano new_subscriber oppure resub, con il livello in membership. Shop Order e Commission usano purchase senza valori di donazione. Gli eventi privati Ko-fi restano esclusi. Il JSON codificato come modulo viene decodificato una volta; nomi e messaggi sono testo semplice.

Buy Me a Coffee donation.created mantiene il supporto monetario; extra_purchase.created e commission_order.created diventano purchase. wishlist_payment.created diventa giftcontribution usando solo quell'importo di pagamento; meta.commerce.completed registra l'indicatore di completamento del provider senza emettere un'altra riga monetaria. membership.started diventa new_subscriber con il livello in membership, senza più usare impropriamente hasDonation per il nome di un livello. Un importo all'avvio dell'abbonamento non viene trattato autonomamente come un addebito pagato. Gli eventi di test, rimborso, errore e quelli di aggiornamento/ciclo di vita non supportati non producono avvisi di pagamento. Le note nascoste dei sostenitori vengono omesse.

Fourthwall supporta ORDER_PLACED (purchase), GIFT_PURCHASE (gift, altro destinatario), DONATION (riga di donazione normale) e SUBSCRIPTION_PURCHASED (new_subscriber). I totali degli ordini esistenti mantengono hasDonation per compatibilità con le versioni precedenti, contrassegnato meta.commerce.legacyDonationValue: true; questa è un'eccezione esplicita alle impostazioni predefinite delle nuove vendite di prodotti. Gli ordini con buoni regalo applicati emettono un avviso d'acquisto senza valore di donazione: non è possibile dedurre in modo affidabile il nuovo addebito dal totale dell'ordine, e l'acquisto del regalo è già stato conteggiato. I nomi di fatturazione e gli indirizzi email non vengono usati come identità pubblica. Gli eventi di test della dashboard e gli aggiornamenti degli ordini non generano avvisi di pagamento.

Questi adattatori mantengono relay, azioni bot, Event Flow e instradamento verso le destinazioni esistenti, con meta.webhookId deduplicazione. Espongono nomi pubblici, messaggi in testo semplice, nomi degli articoli noti in subtitle, e ISO meta.commerce.currency insieme ai valori numerici delle donazioni quando applicabili. Non aggiungono la contabilizzazione dei rimborsi né una nuova autenticazione del ricevitore; usa il percorso webhook già configurato del provider.

meta.monetization.commerce in monetization_update contiene enabled, qr, position, display (first/cycle), seconds e un array pubblico items. Ogni articolo ha name, url, image, amount facoltativo (null se sconosciuto), currency e purpose (shop/gift/support/membership). Sono dettagli promozionali inseriti dall'host, non prove di pagamento. Aggiungere o modificare articoli non emette eventi di donazione o acquisto. L'overlay generico usa mode=commerce; view=both|showcase|card|alerts separa la promozione dall'attività. I parametri URL facoltativi style, scale, cardevery, cardfor e onlytype controllano la presentazione. Le modalità esistenti dei provider accettano anche controlli di vista e programmazione. Vedi la guida alla configurazione.

Eventi regalo Throne

L'integrazione Monetizzazione, da attivare esplicitamente, inoltra eventi Throne firmati con platform e type impostato su throne. Tutti e tre usano un identificatore di consegna stabile id, testo semplice chatname, chatmessage con textonly: true, nome dell'articolo in subtitle, e la miniatura HTTPS facoltativa in contentimg.

evento	Significato	Importo della donazione / rango
`gift`	Un regalo acquistato	`hasDonation` e USD `donoValue`; rango regali +1
`giftcontribution`	Un contributo per un regalo	Solo importo del contributo; nessun aumento del rango
`giftfunded`	Un regalo finanziato dalla community completato	No `hasDonation` oppure `donoValue`, evitando di contare due volte i contributi precedenti; rango regali +1

meta.throne contiene itemName, creator (nome utente pubblico), completed, currency e, nell'unità monetaria principale, amount. Per giftfunded, l'importo descrive l'obiettivo, non un nuovo introito. Chi regala in forma anonima rimane Anonymous; i regali completati della community usano Community. I campi privati di pagamento e spedizione non vengono mai inoltrati.

monetization_update istantanee contengono inoltre meta.monetization.throne: enabled, username, url, qr, position, rank, e gifts. Queste istantanee non contengono URL webhook né credenziali di ascolto.

Comandi vocali dell'host (anteprima desktop)

La funzionalità Event Flow Quando dico... riceve comandi attendibili dal microfono locale di SSApp. Il suo contesto interno delle azioni usa chatname: "Host", type: "hostvoice", la frase riconosciuta in chatmessage, e textonly: true. Non è un evento di piattaforma in arrivo né un nuovo trasporto chat. L'invio di questi campi tramite chat non può attivare un trigger vocale.

Richiede una build desktop aggiornata, l'avvio esplicito del microfono e l'abilitazione delle azioni dopo la modalità Test. Vedi la configurazione dell'anteprima e stato della convalida.

Controlli di visualizzazione dei prodotti

Esistenti monetization_update istantanee possono includere meta.monetization.commerce.live: null per la programmazione salvata, oppure {mode: "show" | "hide", url?: "https://...", until: 0 | epochMilliseconds}. Show cerca una corrispondenza esatta con l'URL del prodotto salvato; se manca il prodotto non appare alcuna scheda. Un valore until positivo, alla scadenza, ripristina la programmazione salvata; zero dura fino a una modifica o al riavvio di SSN. Hide nasconde le promozioni, non gli avvisi di attività a pagamento.

commerce.viewerURL è l'URL pubblicato del negozio in sola lettura, oppure una stringa vuota. Quando presente, i codici QR promozionali rimandano a quell'URL. Non contiene mai la sessione SSN o la chiave di pubblicazione. I prodotti restano in commerce.items. I controlli di visualizzazione, le importazioni e la pubblicazione non emettono eventi di donazione/acquisto. Vedi Controlli dei prodotti per Event Flow e l'uso dell'API remota.

La funzionalità Event Flow commerceControl attende la risposta diretta/Chrome (fino a otto secondi). Nei normali payload evento mantiene l'evento e aggiunge meta.commerceControlResult: {success: true, commerce: controlState} oppure {success: false, error: "..."}. Per un valore esistente numerico, array o comunque diverso da un oggetto in meta, i metadati restano invariati e la diagnostica viene restituita come commerceControlResult nel risultato dell'azione. I controlli non riusciti interrompono le azioni successive di quella catena senza sopprimere l'evento di pagamento originale. Un timeout non dimostra che il controllo non sia stato applicato; esamina lo stato prima di riprovare un comando relativo come Next. Il successo conferma lo stato locale di selezione/visibilità/programmazione, mai la visibilità in OBS o la sincronizzazione della pagina pubblica.

Flussi di lavoro Stream Deck / API con nome

Il trigger di flusso di lavoro con nome crea un messaggio Event Flow interno con type: "api", event: "workflow_trigger", chatname: "Stream Deck / API", vuoto chatmessage, e textonly: true. Il suo meta.workflow oggetto contiene il nome del trigger e un JSON fornito dal chiamante data oggetto. Leggi i valori tramite template come {meta.workflow.data.minutes}. Vengono valutati solo i flussi salvati e abilitati che corrispondono esplicitamente a quel trigger. Non è un evento spettatore/chat in arrivo e non viene trasmesso come chat; copiare questi campi nella chat non attiva il trigger con quel nome.

Progetto pilota per il pubblico NinjaChatter

Il connettore sperimentale dell'estensione abbinata invia righe destinate alla sola visualizzazione con type: socialstreamchat, platform: ninjachatter, e textonly: true. meta.ninjachatter contiene origin: audience, il valore descrittivo provider, e il pubblico room ID. Queste righe non passano attraverso risposte di piattaforma, bot, trigger Event Flow e punti. Un provider visualizzato non costituisce un'autorizzazione. Le acquisizioni precedenti della sorgente NinjaChatter includono meta.ninjachatter.room per la soppressione dei duplicati specifica della stanza.

Cheer usa un percorso autenticato separato per richieste e risultati, mai un comando chat speciale. Il preset fisso emette l'overlay Actions esistente show_text messaggio per tre secondi. La sua ricezione indica l'accettazione del trasporto, non la visualizzazione verificata in OBS. Nessun payload del pubblico può selezionare azioni arbitrarie. Il progetto pilota è disabilitato per impostazione predefinita su NinjaChatter; Electron mantiene il relay esistente finché non viene convalidato il nuovo confine di abbinamento privato.

Bacheche dei posti in vendita e vendite recenti

L'esistente monetization_update evento (type/platform: socialstream) include anche meta.monetization.boards. Il suo board contiene title, style (posti/squadre), columns (1–20), visible, e fino a 120 spots. Ogni posto ha una stringa id, testo semplice label, status (disponibile/riscattato/rivelato) e result (testo semplice, vuoto fino alla rivelazione). Riscatti e rivelazioni sono uno stato visualizzato inserito dall'host, non una prova d'acquisto né assegnazioni casuali.

boards.sales contiene fino a 100 registrazioni recenti: id, title, facoltativo amount (null se sconosciuto), currency, quantity, source, e at (millisecondi Unix al momento della registrazione). automatic attiva la raccolta, salesVisible controlla la visualizzazione e revision aumenta a ogni modifica. La raccolta automatica accetta solo purchase eventi da Shopify, venditore eBay, Fourthwall, Ko-fi e Buy Me a Coffee; gli eventi privati/di test sono esclusi. Non considera metadati d'asta, mance, regali o riscatti di posti come acquisti. Le registrazioni automatiche non sostituiscono il prezzo di un articolo con totali degli ordini, prezzi delle inserzioni o importi delle donazioni. Le registrazioni manuali usano source: "Host confirmed".

Lo stato persiste nell'archivio privato di monetizzazione di questa installazione; le istantanee pubbliche escludono gli ID di deduplicazione delle consegne, l'identità degli acquirenti e i segreti. Le vendite visualizzate esplicitamente mantengono i propri ID evento per la rimozione. I rimborsi richiedono la rimozione da parte dell'host. Gli ID degli acquisti duplicati vengono ricordati separatamente (fino a 2.000), anche dopo aver svuotato la cronologia visibile. L'esistente getCommerceState risposta include commerce.boards; commerceControl accetta i comandi di bacheca/vendite documentati nella guida alle bacheche. Le modifiche manuali trasmettono lo stato aggiornato, ma non creano mai eventi d'acquisto, totali di donazioni o ricompense a pagamento. Gli overlay si nascondono quando l'istantanea dell'host è assente da 35 secondi.

Aggiunte al flusso di lavoro del venditore: commerce.boards.board.id identifica una generazione della bacheca. Un intervento manuale saleAdd può fornire boardId e spotId per registrare la vendita e assegnare quel posto in modo atomico; le vendite collegate duplicate ancora nella cronologia recente vengono rifiutate. saleRemove con reopenSpot: true libera quel posto solo se la generazione della bacheca corrisponde ancora. Le voci pubbliche di vendita omettono questi campi di collegamento dell'operatore. Un campo facoltativo platform su una vendita manuale mantiene la sua sorgente per i filtri, mentre source: "Host confirmed" identifica il metodo di conferma. amount è il totale della voce, incluso il suo quantity. Il campo dell'adattatore degli ordini pagati eBay meta.ebayPurchase.quantity viene mantenuto.

salesSettings.auctionSource attiva l'assistente per gli articoli Whatnot o eBay Live. Il campo della risposta di controllo commerce.auction contiene solo source, title, priceText, status e at dell'ultimo evento acquisito auction_update, oppure null. Scade dopo cinque minuti e si svuota al cambio di sorgente, con un'istantanea inattiva o al riavvio. L'assistente è riservato all'operatore: non viene salvato né incluso nelle trasmissioni al pubblico; l'identità degli offerenti/vincitori viene scartata. Gli script delle sorgenti e i payload degli eventi d'asta restano invariati. Copiare una bozza non conferma il pagamento né crea una vendita.