Component Events
Base components emit normalized events so flows can branch, data can be captured, and analytics stay consistent. The lists below describe the internal component event catalog used by Studio wiring and campaign runtime configuration.
For the public host-page integration contract, use the JavaScript API document. The public JavaScript API intentionally exposes a smaller, more stable set of events for embedded campaigns.
Overview
This page documents runtime-facing event names used by built-in components. The source of truth for event availability is the component event registry in campaign-spec/src/componentEvents.ts.
The catalog below reflects current canonical event names:
page_viewedstartedfinishedansweredsubmittedevent_button_clickedevent_text_input_changedevent_checkbox_toggledevent_code_input_submitevent_code_input_resendevent_auth_panel_submitevent_tasklist_requestedevent_timer_startevent_timer_completedevent_reward_requestedevent_reward_sectors_requestedevent_last_reward_requestedevent_shuffle_startedevent_daily_picks:checkevent_daily_picks:completedevent_match_forecast:voteevent_match_forecast:cta
Game events
| Event | Fired by | Payload highlights |
|---|---|---|
started | Game components such as trivia_quiz, fortune_wheel, scratch_card, crossword, memory_game, snake_game, goal, and others. | { componentId, game_type, session_id, started_at, timer } |
finished | Same game components when a play session ends. | { componentId, game_type, session_id, outcome, end_reason, timer, metrics, error } |
answered | trivia_quiz. | { componentId, game_type, metrics: { question_id, answer_id, correct? } } |
event_shuffle_started | cards_pack before the card shuffle / reveal sequence starts. | Component-specific payload. |
event_daily_picks:check | daily_picks when the player confirms selected cards. | Component-specific payload. |
event_daily_picks:completed | daily_picks when the check flow completes. | Component-specific payload. |
event_match_forecast:vote | match_forecast when the user votes. | { id, name, side, votes1, votes2, odds1, odds2 } |
event_match_forecast:cta | match_forecast CTA click after voting. | { id, name, side, odds, votes1, votes2 } |
Notes:
finished.metricsis game-specific. For example, Trivia may include score-oriented values, while other games may include progress or completion metrics.- Reward-based components may also emit reward request events in addition to
startedandfinished.
Form and input events
| Event | Fired by | Payload highlights |
|---|---|---|
event_text_input_changed | TextInput, TextareaInput, and other text-like field components. | { id, name, value } |
event_checkbox_toggled | Checkbox, typically bound to consent fields. | { id, name, checked } |
event_code_input_submit | CodeInput when the current code is submitted. | { id, name, code } |
event_code_input_resend | CodeInput when the resend action is triggered. | { id, name } |
submitted | Form when submission succeeds. | { id, name, data } |
event_auth_panel_submit | AuthPanel when credentials or provider selection is submitted. | { id, name, email, auth_provider_id, authProviderId } |
These events feed node logic (branch, compute) to continue the flow only after successful submissions.
Action and reward events
| Event | Fired by | Payload highlights |
|---|---|---|
event_button_clicked | button, cover. | { componentId } |
event_reward_requested | Reward-aware components such as reward_button, cards_pack, fortune_wheel, scratch_card, reward. | Request payload used to fetch reward allocation. |
event_reward_sectors_requested | Reward-aware components that need sector or prize availability metadata before interaction. | Request payload used to resolve sectors / prizes. |
event_last_reward_requested | prize_banner when it requests the latest reward projection. | { appId, pageId, poolId, componentId, requestId } |
event_tasklist_requested | task_list when it asks runtime for current task state. | { id, name, taskListId, taskId, taskIndex, taskText, done } |
Notes:
event_reward_requested,event_reward_sectors_requested, andevent_last_reward_requestedare runtime-facing events used by reward mechanics.- These reward request events are distinct from the public host-page
reward_receivedevent documented in the JavaScript API.
Timer and page events
| Event | Fired by | Payload highlights |
|---|---|---|
event_timer_start | timer when countdown or count-up begins. | { id, name, mode, elapsed, remaining, duration } |
event_timer_completed | timer when countdown completes. | { id, name, mode, elapsed, remaining, duration } |
page_viewed | Runtime page activation. | Fired whenever a page node becomes active. |
Component coverage
The following component groups currently participate in the catalog:
- auth and code entry:
auth_panel,code_input - input and forms:
text_input,textarea_input,checkbox,form - simple actions:
button,cover - questions:
trivia_quiz - reward mechanics:
reward_button,cards_pack,fortune_wheel,scratch_card,reward,prize_banner,daily_picks - timers and task state:
timer,task_list - game components:
crossword,puzzle_game,puzzle_jigsaw,memory_game,hidden_objects,matching_game,triple_memory,snake_game,tank_battle_game,falling_objects,endless_runner,car_race,geometry_dash,goal - specialized interactions:
match_forecast
Using the catalog
- Node transitions can listen for these events directly.
- The catalog reflects runtime-facing event names used by components and campaign wiring.
- Host website integrations should use the public JavaScript API instead of consuming this internal catalog directly.