Changelog

Notable changes to the AdQuest SDK and public API.

On this page

SDK 1.1.0

Quests that hold a place (video, banner, survey, visit) can be reserved on the server. The start response then carries reservation_id, expires_at, server_time and timing; questions are answered one at a time against server deadlines and the widget shows the time left.
A completed quest is accepted first and settled in the background. The widget shows a pending state and shows the reward only after the server confirms it; headless clients poll GET /platform/quests/{id}/completion.
A lost response or an expired delivery token never loses an accepted submission: the client asks the server where the attempt stands instead of submitting again.
Compatible with servers that do not use reservations: nothing changes for them. SDK 1.0.6 keeps working against a server with reservations on, with a 90 second wait before a failed attempt can be restarted.
Starting, answering and completing a quest need a participant token; the server takes the participant from it.

AdQuestWidget is lottery-first and requires participantToken.
Quest-only UI is exported as QuestWidget.
Callbacks: onEntry, onComplete, onClaim, onNavigate, onAuthRequired. The onNavigate payload is { view, canGoBack }.
Hosted embed with a versioned postMessage bridge.
Theme tokens for background, surface and CTA edge.

Provide participant tokens for balance, entry and claim flows.
Update callback names if you still listen to older event names.
Quest tokenReward and completion tokensAwarded now show the participant’s share.
Browsing quests without a participant token still works. Balance, lottery entries and claims need a signed participant token.