直播事件参考
查找源的事件名称、负载字段和捕获要求。有关支持的警报的快速概述,请参阅 事件和提醒兼容性.
捕获设置、过滤器和负载约定
重要: 事件是否可用取决于来源、权限和捕获设置。要在停靠面板或精选叠加层中隐藏带事件标记的行,请添加 &hideevents 或 &hideallevents。要隐藏所选事件,请使用 &filterevents=subscription_gift,new_follower,gifted。这些筛选器也可以隐藏带有以下标记的付费行: event;没有事件标记的普通打赏行不会被事件筛选器匹配。其他消息筛选器仍然适用。
选择捕获方法: 对于 YouTube、Twitch 和 Kick, WebSocket 模式 通常提供更广泛的事件覆盖。标准 DOM 捕获读取页面上实际渲染的行和卡片。YouTube Super Chats、Super Stickers 和 Jewel 礼物在两种模式中都有捕获路径;其他礼物、打赏和会员事件因来源而异。受支持的路径和必要设置请参阅平台表格。
载荷结构: 打赏样式的聊天行应使用 hasDonation 和可选的 donoValue。不要设置 event: "donation" 仅仅因为普通聊天/打赏行有金额;仅对真实平台操作或付费商品类型使用具体事件名称,例如 superchat, supersticker, gift,或 jeweldonation。使用 meta 仅用于使用方确实需要、且现有字段尚未涵盖的额外结构化数据。
功能可用性速览
使用此表查看每种捕获方式目前提供哪些提醒类型。详细载荷说明见下文。
专用的 Multi-Stream Alert Box 将直播事件分为六个核心提醒类别: Follow, Subscription/Member, Donation, Bits/Cheers, Raid/Host,以及 Purchase,以及两个需主动启用的类别(Auction 和 Hype Train)通过 URL 参数启用。这些类别根据现有的 event, membership, subtitle, hasDonation,以及 meta 此处记录的字段;无需单独的载荷格式。
*YouTube 订阅者提醒通过轮询获取,可能延迟或不完整。API 参考并未承诺固定的四小时交付窗口。请参阅 官方订阅 API 限制.
字段概览
data 此处指消息对象,不是需要添加的额外包装层。聊天行和仅元数据事件具有不同结构:计数器和状态快照可能省略 chatname/chatmessage。在平台表格中, 消息 描述普通聊天行,而非字面上的 event: "message".
SOOP — 播放器 DOM 捕获
实现: sources/sooplive.js。支持统一的 play.sooplive.com 播放器和旧版 play.sooplive.co.kr URL。提供旧版全局聊天布局时,仍会识别它。
公开聊天发出 type/platform: "sooplive",纯文本的 chatname/userid, nameColor,以及经过清理的 chatmessage。排除现有行、重复消息 ID、翻译副本和私人私信。表情会转换为安全图片,或在纯文本模式下转换为替代文本。
带有 showviewercount 或 hypemode 启用时, viewer_update 携带整数 meta 来自播放器的 #nAllViewer。仅聊天的弹出窗口可能不提供此计数。SSApp 打开独立弹出窗口时会使用完整播放器,因为当前 SOOP 弹出窗口依赖其打开者。
Gosh - 频道聊天捕获
实现: sources/gosh.js。打开 https://gosh.com/USERNAME 并让聊天可见,或将该 URL 粘贴到 SSApp 的 Add other source(添加其他来源)。无需弹出聊天窗口。
新的聊天行发出 type/platform: "gosh",纯文本的 chatname, nameColor,以及经过清理的 chatmessage。内联图片和 GIF 保留安全的 HTTP(S) URL。使用 textonlymode,图片转换为替代文本或 [image] 当没有替代文本时。头像、徽章、打赏和会员在捕获行中缺失时保持为空。
让虚拟化聊天列表保持滚动到最新消息。排除现有历史记录、重新渲染的行和无作者的系统通知。渲染索引仅供内部使用,不会作为原生消息 ID 发出。不会推断关注、打赏、观众数量或管理事件。
Livacha — 聊天室捕获
实现: sources/livacha.js。打开 https://livacha.com/chat/ROOM 并让聊天可见,或将聊天室 URL 粘贴到 SSApp 的 Add other source(添加其他来源)。
新的聊天行发出 type/platform: "livacha",纯文本的 chatname, chatimg, nameColor,以及经过清理的 chatmessage。相对头像和内联图片 URL 会转换为绝对 HTTP(S) URL。段落、换行和列表会展平成一条聊天消息。使用 textonlymode,图片转换为替代文本或 [image].
消息 ID 在内部用于避免重复捕获编辑内容和重新挂载的行。会跳过初始历史记录和前置加载的旧消息;时间戳和回应菜单不属于捕获正文。不会推断打赏、会员、管理或观众数量事件。
Chatango - 群聊
打开 https://ROOM.chatango.com/,或嵌入 Chatango 房间的页面。新行发出标准聊天 type/platform: "chatango",纯文本的 chatname, nameColor, chatmessage,以及 chatimg 当可用时。内嵌图像使用 HTTP(S) URL;纯文本模式使用其替代文本或 [image]。捕获附加时已显示的行以及向后滚动时预先添加的旧消息将被跳过。
Vaughn Live - 频道聊天捕获
实现: sources/vaughn.js。打开 https://vaughn.live/USERNAME 聊天可见,或将频道 URL 粘贴到桌面应用程序的添加其他源中。
每个新消息正文都会发出标准聊天 type/platform: "vaughn",纯文本的 chatname, chatmessage,以及团体头像 chatimg, nameColor和图像/SVG chatbadges 当存在时。紧凑聊天会读取消息前面的名称。表情使用其显示的图像 URL,或其触发/替代文本 textonlymode.
内部跟踪消息 ID 和元素,以避免在分组消息到达、确认后 ID 更改或再次呈现行时出现重复。当初始加载覆盖可见时呈现的现有消息和历史记录将被跳过。时间戳、消息工具和链接预览卡不包含在消息内容中。
Stream.space — 实验性 DOM 捕获
实现: sources/streamspace.js。仅匹配 https://beta.stream.space/chat-popup.php?channel=USERNAME 和等效的 https://stream.space 弹出窗口。
新渲染的聊天行发出 type: "streamspace", platform: "streamspace",纯文本的 chatname/userid, chatmessage,头像 chatimg,以图片呈现的等级 chatbadges,以及 nameColor。内联表情会重建为安全图片,或在以下情况下使用其替代文本: textonlymode 已启用。排除现有历史记录、欢迎通知、回复预览和置顶重复项。
viewer_update 携带整数 meta 读取自 #popupViewersNum 当 showviewercount 或 hypemode 已启用。不会推断打赏、会员或管理事件。
实验性:检查期间 beta 弹出窗口一直停留在 Loading。SSApp 加载了弹出窗口并捕获到观众更新,但实时聊天交付和生产版弹出窗口仍未验证。SSN 无法捕获网站未渲染的消息。
w.tv 和 Prime — DOM 捕获
实现: sources/wtv.js 在 https://w.tv/USERNAME/chat 和 sources/prime.js 在 https://prime.gs/USERNAME?chat_popout=1.
新的聊天行使用 type/platform 的 wtv 或 prime,纯文本的 chatname, nameColor,以及经过清理的 chatmessage。内联表情会转换为安全图片,或在纯文本模式下转换为替代文本。Prime 还包括该行的 userid 并支持已登录的个人资料链接及未登录的用户名标签。当已验证的行结构中不存在头像和徽章时,这些字段保持为空。
不包含初始历史记录、置顶卡片和回复预览。w.tv 使用虚拟化聊天列表:请保持滚动到最新消息,以便捕获。其 DOM 测试 ID 是渲染索引,并非原生消息 ID。Prime 会跳过在初始消息上方加载的旧历史记录和被忽略用户的占位内容。
这两种弹出窗口都不提供经过验证的直播观众数量,因此这些适配器不会发出观众更新,也不会推断打赏、订阅或管理事件。
Goodgame、Pilled、Owncast、Picarto 和 Piczel 观看者计数
启用 显示观众数量 或 跟踪活跃聊天用户 (showviewercount 或 hypemode) 收集观看者计数。打开显示查看者的“查看者计数和聊天活动”叠加层也会请求它们。每个源发出 event: "viewer_update" 具有非负整数 meta,在启用捕获时每 30 秒刷新一次。这些是流媒体观看者数量;活跃聊天者单独计数。报告的零有效;失败的请求不会产生零计数。
正常聊天使用源的 type, chatname, chatmessage,以及 textonly 没有查看器事件标记的字段。查看器更新包含 type, event,和整数 meta;背景将它们组合成 viewer_updates 用于叠加。
覆盖范围和兼容性限制
本参考描述已实现的载荷,并不保证每个平台都会提供每种事件。空的 hasDonation 在来源中的赋值并不能证明支持打赏。DOM 可见性、账号权限、捕获开关和 API 可用性仍决定收到哪些内容。删除转发因来源而异;不要假定所有来源都支持管理同步。
已跟踪的不一致和空缺
来源专属别名和旧版名称
这些映射专用于列出的来源/上下文,不是全局替换。使用方对别名的支持因页面而异。当前 TikTok DOM 和 TikFinity 来源仍然发出 followed;Velora 使用 subscription 和 channel_points,Streamlabs 则使用 subscription。接受当前来源约定及其相关旧版别名,而不是重命名每个匹配的事件。
使用本参考
- 添加新事件时,复用现有词汇(
subscription_gift, viewer_update等)。如确实无法避免差异,请在此记录并说明原因。
- 保持
data.meta 保持可预测:优先使用扁平键,绝不将混合数据塞入字符串,并始终包含单位(currency, bits, duration).
- 更改载荷时同步更新本页;仅在共享开发规则变化时更新代理说明。
- 验证载荷更改时,同时检查发出载荷的来源和使用载荷的叠加层或 Event Flow 触发器。
- 是否捕获取决于来源支持和设置。要在停靠面板或精选叠加层中隐藏带事件标记的行,请添加
&hideevents 或 &hideallevents。要隐藏所选事件,请使用 &filterevents=subscription_gift,new_follower,gifted.
- 对于 YouTube、Twitch 和 Kick,启用 WebSocket 模式 以获得最广泛的平台专属事件支持。YouTube 的礼物/打赏捕获(包括礼物和 Super Chat)在标准和 WebSocket 模式下均可用;WebSocket 还增加了额外的事件类型。具体支持仍因平台、账号角色和已授予的权限范围而异。
返回顶部
事件叠加显示控件
发送 {"action":"eventOverlayControl","surface":"alerts","board":"default","command":"pause"} 通过现有的目标覆盖控制通道。使用目标 alerts 用于多流警报框或目标 dock 有表面 events 用于活动源/事件。该板必须与覆盖层匹配 board URL 选项(默认值: default).
堆栈和提要接受 pause, resume, pin, unpin, remove 和 clear。警报还接受 skip, mute, unmute 和 replay。 Pin 切换最新的可见行;删除将其删除。这些是显示控件,而不是传入流事件,并且不得作为捐赠或事件操作提交。发送的命令并不表明 OBS 正在显示覆盖。
请参阅 事件叠加指南 用于历史记录、过滤器和受众设置。
变现叠加层
NinjaBacker 打赏使用 platform: "ninjabacker", type: "ninjabacker", chatname,纯文本的 chatmessage, textonly: true、带有来源前缀的 id,格式化后的 hasDonation,以及数字形式的 donoValue。它们是普通打赏样式行,没有 event 覆盖值。 meta.ninjabacker 包含 ISO currency 和主货币单位的 amount。匿名打赏使用显示名称 Anonymous。来源使用实时 SSE(不重放),或 SSN API 上需主动启用的已签名 webhook 接收器(队列交付最长七天)。可靠交付使用稳定的 ninjabacker:delivery:DELIVERY_ID ID。两种模式都不会接收退款/争议冲正。接收端凭据和签名密钥绝不会进入事件载荷。由调用方控制的 callbackId 值不是付款身份,也不会被转发。仪表板测试打赏排除在打赏行之外。它们发出 event: "monetization_test" 带有 meta.ninjabackerTest 包含 id 和 at(Unix 毫秒),仅用于专用预览提醒。
event: "monetization_update" 是来自以下位置的仅元数据快照: type/platform: "socialstream". meta.monetization.wishlist 包含 enabled、qr、position、rank、total、公开的 url,以及当前项目(name、amount、currency、image、公开的 url)或 null。 meta.monetization.ninja 包含 enabled、qr、position、username 和公开的打赏 url。绝不包含私有 Tip ID。 meta.monetization.ebay 包含 enabled、qr、position、display(cycle/cheapest/first)、seconds、可选启用的公告设置和公开项目。每个项目有 id、name、amount、currency、image、url、auction、startingBid、endsAt、available、bought 和 updatedAt。时间为 Unix 毫秒。不包含卖家凭据或买家身份。
主播确认的心愿单购买还包括 meta.wishlistPurchase 带有 id、name、可选的 supporter 和 at(Unix 毫秒)。这是主持人确认,并非 Amazon 付款通知,也不计为货币打赏。叠加层应对其 id 去重,并忽略旧的购买通知。
Shopify 已付款订单
可选的带签名 Shopify 接收端发出 platform/type: "shopify" 和 event: "purchase" 仅用于 orders/paid 带有 financial_status: "paid"、正数总额, test: false、未取消,且带有当前的已签名请求体更新时间戳。测试、未付款、过期、取消和退款通知不会发出购买操作。不会推断赠礼意图。
chatname 为 Anonymous;排除客户字段、私有备注和订单 URL。 chatmessage 是纯文本,带有 textonly: true; subtitle 保存最多三个公开商品标题。 meta.commerce 包含 orderTotal 和 currency 以商店货币计,另加 quantity 当已知完整有效的数量时。接收者和实物/数字用途保持未设置。没有 hasDonation 或 donoValue 已设置。 id 是具有 Shopify 前缀、以商店/订单为范围的稳定不透明哈希;它不是原始订单标识符。
购买使用现有的活动、multi-alerts Purchase 类别和 Event Flow 路径。商品推广使用现有的 meta.monetization.commerce 目录。导入商品或将其推广标签设为 Gift 不会生成购买或礼物事件。 Shopify 设置和交付限制.
礼物和商业交易
使用 event: "gift" 用于礼物, giftcontribution 用于为礼物提供付费支持, giftfunded 用于筹款完成,以及 purchase 用于商品销售。这些名称独立于提供商,也不取决于商品是实物还是数字商品。将旧版的 giftpurchase 用于赠送会员的事件;Throne 以前错误地使用该名称,现在发出 gift。现有的会员事件生成方保持不变。自定义 Throne 事件名称筛选器应改用 gift;打赏筛选器无需更改。
hasDonation 仍为付费支持的兼容信号,带有 donoValue 保存所提供或估算的美元值。礼物和贡献保留这些字段。筹款完成会省略两者,避免重复计算贡献。普通商品销售默认省略它们,保持 eBay 的数据约定。不要根据商店、心愿单 URL 或实物商品推断赠礼意图:为买家或其他收件人购买仍然属于销售,除非来源明确标识为向创作者赠礼。
可选的共享 meta.commerce 字段为 recipient (creator、buyer、other), itemType (physical、digital、service), quantity (正数商品数量), currency (ISO 货币), goalAmount (以主要货币单位表示的筹款目标,绝不是新增收入),以及 orderTotal (已知的主要货币单位已付款订单总额;属于商业交易,而非打赏收入)。省略未知详情。商品名称保留在 subtitle,图片位于 contentimg,以及位于以下字段中的支持者文本: chatmessage。现有提供商元数据仍然可用。Throne 提供接收者和货币,并在完成时提供 goalAmount;eBay 提供数量。两者都不会猜测商品类型,也不会公开接收者的私人信息。
即使没有支持者文本,活动信息流也会显示这些事件。Multi-alerts 对礼物和贡献使用打赏展示方式,包括一个不含货币价值的独立 Gift Fully Funded 通知。购买有单独的 Purchase 类别,默认启用,带有 purchasestyle, purchasesound, purchaseaccent,以及 disablepurchases URL 控件。购买提醒不会改变打赏总额。
Event Flow 在 Event Type 和 Other Event 触发器中提供这些事件名称。打赏触发器仍检查 hasDonation;Gift Sub 触发器保留会员语义。Compare Property 接受嵌套路径,例如 meta.commerce.recipient。操作模板接受 {meta.commerce.quantity} 和 {meta.commerce.currency},以及现有的 {donation}, {subtitle},以及 {meta}。嵌套路径区分大小写,缺失值显示为空,并禁止遍历原型。
创作者商业 webhook 和促销叠加层
Ko-fi 公开 Donation 付款保留 hasDonation 并获得美元 donoValue。订阅付款使用 new_subscriber 或 resub,等级位于 membership。Shop Order 和 Commission 使用 purchase 不带打赏值。私有 Ko-fi 事件仍被排除。表单编码的 JSON 只解码一次;姓名和消息为纯文本。
Buy Me a Coffee donation.created 保留货币支持; extra_purchase.created 和 commission_order.created 变为 purchase. wishlist_payment.created 变为 giftcontribution 仅使用该付款金额; meta.commerce.completed 记录提供商的完成标志,不会再发出一条货币金额行。 membership.started 变为 new_subscriber 等级位于 membership,不再误用 hasDonation 用于等级名称。订阅开始金额不会单独被视为一次付费扣款。测试、已退款、失败和不受支持的更新/生命周期事件不会生成付费提醒。隐藏的支持者备注会被省略。
Fourthwall 支持 ORDER_PLACED(purchase)、GIFT_PURCHASE(gift,接收者为其他人)、DONATION(普通打赏行)和 SUBSCRIPTION_PURCHASED(new_subscriber)。现有订单总额保留 hasDonation 以保持向后兼容,标记为 meta.commerce.legacyDonationValue: true;这是对新商品销售默认规则的明确例外。使用礼品卡的订单会发出没有打赏值的购买提醒:无法可靠地从订单总额推断新的扣款,且礼品卡购买已计入。账单姓名和电子邮件地址不用于公开身份。仪表板测试事件和订单更新不会生成付费提醒。
这些适配器保留现有的转发、机器人操作、Event Flow 和目标路由,并带有 meta.webhookId 去重。它们提供公开姓名、纯文本消息,以及以下字段中的已知商品名称: subtitle,以及 ISO meta.commerce.currency 在适用时与数值型打赏值一起提供。它们不会添加退款记账或新的接收端身份验证;请使用提供商现有配置的 webhook 路由。
meta.monetization.commerce 在 monetization_update 包含 enabled、qr、position、display(first/cycle)、seconds 和公开的 items 数组。每个项目有 name、url、image、可选的 amount(未知时为 null)、currency 和 purpose(shop/gift/support/membership)。这些是主持人输入的推广详情,并非付款凭证。添加或编辑项目不会发出打赏或购买事件。通用叠加层使用 mode=commerce; view=both|showcase|card|alerts 将推广与活动分开。可选的 style、scale、cardevery、cardfor 和 onlytype URL 参数控制展示方式。现有提供商模式还接受 view 和计划控件。请参阅 设置指南.
Throne 礼物事件
可选启用的变现集成转发带签名的 Throne 事件,带有 platform 和 type 设为 throne。三者都使用稳定的交付 id,纯文本的 chatname, chatmessage 带有 textonly: true,商品名称位于 subtitle,以及位于以下字段中的可选 HTTPS 缩略图: contentimg.
meta.throne 包含 itemName, creator (公开用户名), completed, currency 和主货币单位的 amount。对于 giftfunded,金额描述的是目标,而非新增收入。匿名赠礼者仍保持为 Anonymous;已完成的社区赠礼使用 Community。私人支付和配送字段绝不会被转发。
monetization_update 快照还包含 meta.monetization.throne: enabled, username, url, qr, position, rank,以及 gifts。这些快照不包含 webhook URL 或监听凭据。
主播语音命令(桌面预览)
Event Flow 的 当我说…… 触发器接收来自 SSApp 的可信本地麦克风命令。其内部操作上下文使用 chatname: "Host", type: "hostvoice",识别到的短语位于 chatmessage,以及 textonly: true。这不是平台入站事件,也不是新的聊天传输。通过聊天发送这些字段无法激活语音触发器。
需要更新后的桌面版本、明确启动麦克风,并在测试模式后启用操作。请参阅 预览设置和验证状态.
商品展示控件
现有的 monetization_update 快照可能包含 meta.monetization.commerce.live:null 表示已保存的计划,或 {mode: "show" | "hide", url?: "https://...", until: 0 | epochMilliseconds}。Show 匹配已保存的准确商品 URL;找不到商品则不显示卡片。正数 until 到期后恢复已保存的计划;零表示持续到状态更改或 SSN 重启。Hide 抑制促销展示,不抑制付费活动提醒。
commerce.viewerURL 是已发布的只读商店 URL,或空字符串。存在时,推广二维码会链接到该地址。它绝不包含 SSN 会话或发布密钥。商品保留在 commerce.items。显示控制、导入或发布不会发出打赏/购买事件。请参阅 商品控件 用于 Event Flow 和远程 API。
Event Flow 的 commerceControl 操作等待直接/Chrome 回复(最多八秒)。对于普通事件载荷,它保留事件并添加 meta.commerceControlResult: {success: true, commerce: controlState} 或 {success: false, error: "..."}。对于已有的数字、数组或其他非对象 meta,元数据保持不变,诊断信息返回为 commerceControlResult 改为用于操作结果。失败的控制会停止该链中的后续操作,但不会抑制原始付款事件。超时并不能证明控制未应用;重试 Next 等相对命令之前,请检查状态。成功确认的是本地选择/隐藏/计划状态,绝不表示 OBS 可见或公开页面已同步。
命名的 Stream Deck / API 工作流
此 命名工作流触发器 创建内部 Event Flow 消息,带有 type: "api", event: "workflow_trigger", chatname: "Stream Deck / API",空的 chatmessage,以及 textonly: true。其 meta.workflow 对象包含触发器名称和调用方提供的 JSON data 对象。通过如下模板读取值: {meta.workflow.data.minutes}。只会评估明确匹配该触发器的已保存且已启用流程。这不是来自观众/聊天的入站事件,也不会作为聊天广播;将这些字段复制到聊天中不会激活命名触发器。
NinjaChatter 观众试点
实验性的配对扩展连接器发送仅供显示的行,带有 type: socialstreamchat, platform: ninjachatter,以及 textonly: true. meta.ninjachatter 携带 origin: audience,描述性的 provider,以及公开的 room ID。这些行会跳过平台回复、机器人、Event Flow 触发器和积分处理。显示某个提供商并不代表获得授权。旧版 NinjaChatter 来源捕获包括 meta.ninjachatter.room 用于聊天室专属的重复抑制。
Cheer 使用独立且经过认证的领取与结果路径,绝不使用特殊聊天命令。固定预设发出现有的 Actions 叠加层 show_text 消息,持续三秒。收到它表示传输已接受,并不表示已验证 OBS 显示。任何观众载荷都不能选择任意操作。NinjaChatter 默认禁用此试点;在新的私有配对边界通过验证之前,Electron 保留现有转发方式。
商业名额看板和最近销售
现有的 monetization_update 事件(type/platform: socialstream)还包括 meta.monetization.boards。其 board 包含 title, style (名额/队伍), columns (1–20), visible,以及最多 120 个 spots。每个名额都有一个字符串 id,纯文本的 label, status (available/claimed/revealed)以及 result (纯文本,揭晓前为空)。领取和揭晓是由主播输入的显示状态,并非购买证据或随机分配。
boards.sales 保存最多 100 条最近记录: id, title,可选的 amount (未知时为 null), currency, quantity, source,以及 at (记录时的 Unix 毫秒时间戳)。 automatic 启用收集, salesVisible 控制显示和 revision 在变化时递增。自动收集仅接受 purchase 来自 Shopify、eBay 卖家、Fourthwall、Ko-fi 和 Buy Me a Coffee 的事件;排除私有/测试事件。它不会将拍卖元数据、打赏、礼物或名额认领视为购买。自动记录不会用订单总额、商品刊登价格或打赏金额代替商品单价。手动记录使用 source: "Host confirmed".
状态会持久保存在此安装实例的私有变现存储中;公开快照不包含交付去重 ID、买家身份和密钥。明确显示的销售记录保留其事件 ID,以供移除。退款需要主持人手动移除。重复购买 ID 会单独记忆(最多 2,000 个),包括清除可见历史记录之后。现有的 getCommerceState 响应包含 commerce.boards; commerceControl 接受以下文档中记录的面板/销售命令: 面板指南。手动编辑会广播更新后的状态,但绝不会创建购买事件、打赏总额或付费奖励。主播快照缺失 35 秒后,叠加层会隐藏。
卖家工作流新增内容: commerce.boards.board.id 标识一代面板。手动 saleAdd 可能提供 boardId 和 spotId 以原子方式记录销售并认领该名额;仍在最近历史记录中的重复关联销售会被拒绝。 saleRemove 带有 reopenSpot: true 仅当面板代次仍匹配时释放该名额。公开销售条目省略这些操作员关联字段。可选的 platform 在手动销售记录上保留其来源以供筛选,而 source: "Host confirmed" 标识确认方式。 amount 是该条目的总数,包括其 quantity。eBay 已付款订单适配器的 meta.ebayPurchase.quantity 会保留。
salesSettings.auctionSource 启用 Whatnot 或 eBay Live 商品助手。控制响应中的 commerce.auction 仅包含最近捕获内容中的 source、title、priceText、status 和 at: auction_update,或 null。五分钟后过期,并在来源更改、空闲快照或重启时清除。该辅助工具仅供操作员使用:既不持久保存,也不纳入面向观众的广播;出价者/获胜者身份会被丢弃。来源脚本和拍卖事件载荷保持不变。复制草稿不会确认付款,也不会创建销售。