Manage quests

Use Console to run the quests in your app day to day: add a quiz or a photo quest, put quests in the order members see them, change a setting, and pause a quest when a campaign ends. Your edits wait as unpublished changes until you publish them.

A quest is one activity, such as "Answer three questions about our launch", with what it takes to complete it and what it rewards. A collection is an ordered list of quests your app shows in one place.

Create a quest

In Console you create quests from the kinds your app already supports, such as a quiz, a photo or a one-tap claim. New kinds of quests and new collections come from your project's code: ask your developer for them.

Arrange collections

The ⋯ menu beside a collection title holds the collection's own actions:

Detail changes and quest reordering share the same draft, so review and publish to show them in your app. Deploying again does not change whether a collection is archived.

Dragging is paused while you filter the list.

Quests under Not in a collection are still visible in Console. How they appear in your app depends on its code. Removing a quest from a collection does not pause it; see Pause or archive.

Review and publish

Console saves your changes as you work. Nothing reaches your app until you publish.

Drop changes instead

If another person edits the same unpublished changes, Console asks you to load their version before you continue.

Change a setting

A value you customize in Console takes precedence over the default from your code or the quest type. Console marks the setting Customized and shows the default under it. To follow the default again, choose Reset beside the setting's name, then review and publish.

A quest synced from code keeps its rules there, but you can adjust its settings in Console:

Secret settings

Some code quests have a secret setting, such as a scan code members must not see. Console shows it as Set or Not set, never its value.

• Replace it. Enter a new value in the field. The comparison at the bottom says Replaced, not the value.
• Clear it. Choose Clear beside its name.

Then publish the settings as above. Deploy output and quest listings never show the value either.

Presentation edits on a synced quest publish the same way, with Publish presentation. Reset to code restores the steps, image and account hints from your code.

Choose a point ledger

How IDs are assigned

New quests and drafts also receive IDs from Domino. Duplicating a quest creates a separate identity and completion history. Existing quest and ledger IDs remain valid.

Pause or archive

Neither removes earned progress or rewards.

• A quest you created in Console. Open it and under Participation choose Pause, Resume, Archive quest or Unarchive quest, then review and publish. Console asks you to confirm before archiving.
• A quest synced from code. Open it and choose Archive quest or Unarchive quest under Participation, then give a reason. This publishes right away, separately from your other unpublished changes, and the audit log records it. Deploying the quest's code again keeps it archived.
• Unarchiving needs app support. It fails if your app no longer supports the quest's interaction. See Archive a quest.

These controls change the quest's definition, so they are read-only in live. To stop new participation in a live quest, open it and choose Pause quest beside its status, or under Quest availability in Activity & details, with a reason. Resume it the same way. Quest availability reads Available or Paused for the selected environment, with the reason for a pause.

Recover automatic quest outcomes

Some quests run on their own: Domino checks a member as soon as they meet the quest's prerequisites, such as reaching 100 points. While such a quest is paused, members who qualify are skipped. When its budget runs out, their attempts are rejected. You can review those members and let them through.

For a quest that runs on prerequisites alone, not on a tracker, open its detail in Quests, then Automatic outcomes. You need read permission to inspect decisions and review permission to recover paused outcomes, attempts rejected by budget exhaustion, or attempts that failed because an integration wasn't ready, in either test or live.

1. For paused outcomes, resume the quest through its operation controls. Resume alone does not admit the paused backlog. For an attempt rejected because its budget ran out (status rejected, code budget-exhausted), wait until its budget can cover the completion, such as in the next budget period. For an attempt that failed because an integration wasn't ready (status failed, code integration-required), connect or repair the integration first. That admits these attempts again on its own, so recover only the ones it left, such as on a quest that was paused.
2. Select up to 50 paused, budget-exhausted or integration-required outcomes. Each admitted outcome shows its linked attempt status and code.
3. Choose Preview recovery. Review each member, how many outcomes are ready to run, declared rewards, budget capacity and costs. Several selected events may reuse one occurrence's attempt.
4. Enter a Recovery reason, then choose Confirm recovery. A changed release, eligibility result, existing attempt or budget view requires another preview.
5. Open the admitted attempt to follow evaluation and rewards. Skips that remain ineligible retain their reason.

A preview doesn't reserve rewards or budget: the current budget is checked again when each evaluation settles.

Balance checks shows project-wide point-entry checks that have not finished. Checks retry after failures; exhausted work remains visible. An operator with review permission can choose Retry after the cause is resolved. Retrying keeps the original point-entry identity and cannot duplicate an admitted occurrence.

Try quests with test members

A test member is a pretend member that you control in Test. Use one to try a quest the way a member would before your community sees it: claim it, send an answer, move to tomorrow to try a streak, or skip a check to reach the quests behind it. Live refuses test members.

You need publish permission in Test, which the editor role includes. Audit history → Test members lists who did what as each test member.

Try a quest in Console

In Test, open Project map, then select a published quest in the Builder view. Its Try tab acts as a test member:

1. Choose Test member to create one, or pick one you created before. To try a wallet or balance quest, choose Wallet, pick Solana, EVM or Cosmos, enter an address (and the chain ID for Cosmos, such as cosmos:cosmoshub-4), and choose Save. Change and Remove sit beside each address.
2. The tab shows the quest's state for that member: available, locked with the quests it needs first, blocked with the reason, its streak or count so far, and how often it has been completed.
3. Act as the member: Enroll in the campaign when the quest requires enrollment, Claim, submit text, a link or quiz answers, or Confirm as staff for staff-confirmed quests. For a custom tracker whose source declares identities: ["member"], fill in the record's fields and choose Send record. For an X or Discord tracker, fill in the post, message or reaction and choose Send post, Send message or Send reaction; for a reaction, Member is picks The reactor or The message's author. Fields start at the values the quest's filter asks for, so the first record matches it. After each record, the tab says how many of the tracker's quests admitted, skipped or filtered it out.
4. The latest attempts and the member's balances update as evaluation finishes. Choose Reset to delete the member and start over with another.

The Try tab can't submit a photo. Live shows no Try controls.

Open Scenario at the bottom of the Builder view to see every test member side by side: a row per member with their balances, and a column per day in the project calendar with a mark for each attempt (completed, progress, needs review, rejected or waiting). Hover or focus a day to list its attempts with their quests and outcomes. Select a member's row to act as them in the Try tab. Activity sits on the day the ledger credits it, and tracker records a quest skipped are marked too. If the history can't be read, the dock falls back to each member's latest 25 attempts, placed on the day they were admitted.

To try tomorrow, choose Next day for the selected member. That member moves one project-calendar day forward, and the dock shows their simulated date and how many days they've advanced. To try a three-day streak, act today, choose Next day, act again, then repeat once more: two advances rather than two real days. Other test members keep their own clocks, and real members and live stay on real time. The dock shows up to two weeks around the selected member's day; a member whose day falls outside it shows that day under their name. To start over, reset the member.

Try quests on your staging site

Your staging site shows a test toolbar to anyone who opened it through Console and holds publish permission in Test. Your coding agent can open it with a staging link and use the toolbar as you, or as an automation key (staging links for agents). It runs on top of your real app, so you can try a quest in the interface members will use. Visitors who entered the staging password don't get the toolbar.

The collapsed bar in the bottom corner shows who the site is acting as and that member's simulated date. Select it to open the toolbar. Its header stays in place: the project, the member the site acts as, their simulated date, and Next day. Below it, tabs hold the rest. The toolbar remembers the open tab, whether it is open, and whether you hid it, until you close the browser tab. Escape closes the menu or the open form first, then the toolbar.

The toolbar follows your app without a reload. Right after the app makes a request to its own site, such as a sign-in, a sign-out or a submission, and every few seconds otherwise, it reads who the site is signed in as and, while it is open, the member's activity and the open tab. When your app signs in with a real account instead of a test member, the toolbar shows Not a test member: it acts only on test members, and picking one signs that account out.

Accounts and wallets you connect in your app while acting as a test member are linked to that member, as they would be for a real one. Reset… unlinks them, so you can connect the same accounts to the next member.

The toolbar runs in its own isolated layer, so your app's styles don't change it, and it never gives the page a Console credential. On a phone, the collapsed bar can cover the right end of your app's bottom tab bar; your developer can lift the tab bar above it. To see the screen as members will on live, choose Hide toolbar.

Script a test with code

This section is for your developer or coding agent: the same test members, driven from code or the CLI so a whole scenario can run as a script.

Use management.testMembers from @domino-sdk/relay/server in the selected project with environment: "test", or the domino test-members commands. A Console session, a personal API key, or a domino login CLI session can call them. The caller needs publish permission, which the editor role includes. Hosted app keys and service keys can't use test members, and live refuses them. Console's Builder view uses these methods.

Audit records name the person behind the credential: in Test, Audit history → Test members lists who created, submitted a quest, accepted a referral or redeemed an offer as, passed a quest or accepted an attempt anyway for, moved the clock of, gave or removed a wallet for, linked or unlinked an X or Discord account for, sent a synthetic X or Discord record as, signed a staging app in or out as, and reset or purged each test member (management.audit.list({ category: "test-members" })). Reset and purge delete those records except the staging sign-ins and sign-outs and the reset or purge record itself, which then name the member by ID.

acceptReferral accepts a referral invitation as the member, as a signed-in member accepting it would: the program's qualification and rewards apply, and so do its refusals (self-referral, inviter-already-accepted, invitation-closed after the member completed a quest that isn't a referral program's qualifying quest, referral-cycle, invitation-not-found). inviter uses that test member's invitation code, allocating one if it has none. A member in a referral relationship can't be reset.

redeem redeems an offer, named by key or ID, as the member, as a signed-in member redeeming it would, and answers the redemption. The price, stock, per-member limit and requirements apply, and so do the refusals: offer-not-found, offer-paused for a paused or archived offer, collection-paused while redemptions are paused, prerequisites-incomplete, offer-limit-reached, insufficient-points and offer-out-of-stock. A refusal changes nothing. The redemption and its entitlement are the ones a member's own redeem writes, so management.redemptions.list lists it and staff hand the entitlement over as they would a member's (management.handover.begin, then confirm). The action ID replays it. A member with a redemption can't be reset; purge it instead.

The commands always address the test environment. Writes are saved operations, so an uncertain answer resumes with domino operations resume. Pass --input as JSON: {"kind":"text","value":"…"}, {"kind":"url","value":"…"}, or quiz answers with their release. Omit it for a claim.

createManagementClient and hostedManagementClient return a ManagementClient, which always includes testMembers. Type a function's parameter as ManagementClient when it needs the complete client, as in the examples below.

The routes are POST /management/v1/test-members, GET /management/v1/test-members, POST /management/v1/test-members/:member/actions, POST /management/v1/test-members/:member/evidence, POST /management/v1/test-members/:member/passes, POST /management/v1/test-members/:member/accept-anyway, POST /management/v1/test-members/:member/clock, POST /management/v1/test-members/:member/referrals/accept, POST /management/v1/test-members/:member/redemptions, POST /management/v1/test-members/:member/wallets, POST /management/v1/test-members/:member/wallets/unlink, POST /management/v1/test-members/:member/accounts, POST /management/v1/test-members/:member/accounts/unlink, POST /management/v1/test-members/:member/records, POST /management/v1/test-members/:member/reset, and POST /management/v1/test-members/purge. Reuse an action ID only to retry the same write. Keep that ID when a response is lost.

Read management.testMembers.history(member, { since }) through GET /management/v1/test-members/:member/history?since=<ms>. Without since, the inclusive window runs from 14 days before the member’s current clock through that clock’s current time. An explicit since keeps an inclusive lower bound with no upper bound. Attempts and skipped outcomes name their quest by ID as quest and by authoring key as questKey, which is absent for a quest created without a key. Attempts include eligibleAt: the pinned tracker observation's occurredAt, or createdAt for manual attempts. An attempt an operator decided in place of its check also has operatorDecision: { kind, actor, at }, where kind is "pass" or "accept-anyway" and actor is the operator. Skipped tracker outcomes include quest, tracker, record, the reason code, and the beneficiary's occurrence time pinned at the decision. Both lists filter and sort by these activity times, newest first, with at most 500 entries each; complete: false means older entries were omitted. Use eligibleAt and occurredAt with the project calendar to group activity by day.

import type { ManagementClient } from "@domino-sdk/relay/server"

async function tryQuest(management: ManagementClient, quest: string) {
  const member = await management.testMembers.create({
    actionId: crypto.randomUUID(),
    name: "Test Alice",
  })
  const attempt = await management.testMembers.act(member.id, {
    operation: "attempts.submit",
    actionId: crypto.randomUUID(),
    quest,
  })
  return { member, attempt }
}

import type { ManagementClient } from "@domino-sdk/relay/server"

async function giveWallet(management: ManagementClient, member: string) {
  return management.testMembers.linkWallet(member, {
    actionId: crypto.randomUUID(),
    chain: "solana",
    address: "9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM",
  })
}

import type { ManagementClient } from "@domino-sdk/relay/server"

async function linkX(management: ManagementClient, member: string) {
  return management.testMembers.linkAccount(member, {
    actionId: crypto.randomUUID(),
    provider: "x",
    username: "XDevelopers",
  })
}

import type { ManagementClient } from "@domino-sdk/relay/server"

async function react(management: ManagementClient, member: string) {
  return management.testMembers.record(member, {
    actionId: crypto.randomUUID(),
    tracker: "discord-reactions",
    data: { channelId: "1300000000000000001", emoji: { name: "⭐" } },
  })
}

import { createManagementClient } from "@domino-sdk/relay/server"

async function nextDay(
  management: ReturnType<typeof createManagementClient>,
  member: string,
) {
  const updated = await management.testMembers.advance(member, {
    actionId: crypto.randomUUID(),
    days: 1,
  })
  const detail = await management.members.get(member)
  return { updated, detail }
}

Pass a quest or accept an attempt anyway

To reach the quests behind one whose check you can't or don't want to satisfy, such as a follow on X, an on-chain balance or a quiz, pass it: Domino admits an attempt as a submission would, then accepts it as you without running the quest's check. Pass in the staging toolbar does the same. In code, call management.testMembers.pass(member.id, { actionId, quest }); the answer is the decided attempt.

import type { ManagementClient } from "@domino-sdk/relay/server"

async function skipCheck(
  management: ManagementClient,
  member: string,
  quest: string,
) {
  return management.testMembers.pass(member, {
    actionId: crypto.randomUUID(),
    quest,
  })
}

A pass skips only the check:

• The other rules still apply. Enrollment, availability, prerequisites, a waiting attempt and the retry cooldown refuse it as they refuse a submission, with the same codes. A pass needs no input, so a quiz, text or URL quest passes without answers, and a staff-confirmed quest without a confirmation.
• Completion, budgets and rewards apply. They apply as for an accepted check. You decide in place of a reviewer too: a quest with human review on is accepted at once, with no review to wait for. A pass is one accepted action: a counter quest counts one action and a streak quest today's action, so combine passes with Next day or advance. A budget that can't cover the completion leaves the attempt rejected with code: "budget-exhausted".
• Keys are optional. A keyed quest takes completionKey, and a counter quest takes it as the action's distinct key. Without one, the pass uses a fresh key, so every pass is a new completion or counted action. Other quests refuse a key with HTTP 422 validation-failed.
• Automatic quests can't be passed (HTTP 422 validation-failed). For a tracker-triggered quest, send the record that starts its attempt, with record or a custom tracker ingest. If the check rejects it, accept it anyway.

Accept anyway in the toolbar, or management.testMembers.acceptAnyway(member.id, { actionId, attempt }), accepts a rejected attempt as you, in place of the check's or a reviewer's rejection. It is the same attempt, decided again: its history keeps the rejection, and the completion policy, budgets and rewards apply as for a pass. When it is the member's latest attempt on the quest, the quest's retry cooldown ends too. Like a staff review, it decides the attempt under its pinned release without checking enrollment, the availability window or whether the quest was archived since. An attempt that isn't rejected is refused with HTTP 409 attempt-not-rejected: a failed attempt is retried, and one that needs review is reviewed. Attempts of a quest that completes per content item can't be accepted this way (HTTP 422 validation-failed).

These rules differ from live, where staff accept a rejected attempt anyway with a reason, and live refuses an archived quest, an attempt the member has since followed with a newer one, a completion still in its cooldown and an acceptance that would pay nothing. The test default lets you get a test member unstuck, so it proves nothing about what live allows.

Both are your decision, not the check's. The attempt's history records a test-member-decision with you as the actor, history returns its operatorDecision, and Audit history → Test members lists it. Reset removes the attempts as it removes any.

Pace a live rehearsal

To rehearse with many test members acting in real time, so leaderboards and screens move every few seconds while people watch, run the scenario from a driver process outside your hosted app: a terminal, a CI job or any long-running process.

• Drive members with your own credential. The driver calls management.testMembers or domino test-members with a personal API key, an organization automation key or a domino login session that holds publish in Test. A hosted app key can't act as test members.
• Don't pace it with a schedule or a browser tab. Scheduled jobs run at most every 5 minutes, get one try per run, and must finish within 30 seconds without starting work that outlives the response, such as waitUntil. They suit coarse steps, not seconds. A loop in an open page stops when the tab closes.
• Name each step. Derive each write's actionId from the scenario, such as rehearsal-3-member-17-step-4, instead of a random one. From the CLI, pass the same ID as --action-id. A restarted driver sends the same steps with the same IDs and input, and each answers what it already did instead of acting twice.
• Keep a fixed number of calls in flight. The management client sends a write with an action ID again after no answer, HTTP 500, 502, 503 or 504, or a 429 with Retry-After, waiting as asked, within the call's deadline. See rate limits for the few calls with limits of their own.
• Move clocks instead of waiting. For streaks, daily quests and availability windows, advance the member's clock. Pace in real time only what people watch.

Coding agents follow the same steps in campaign testing.

Attach badge rewards

Create a badge in Rewards with its key, name, description and image URL. Open a quest created from a Console quest type, choose Add badge, and pick the achievement by name. Review and publish the quest changes as usual.

The member drawer lists a member's badges. With review permission, enter a reason and choose Award badge or Revoke. Awards and revokes are recorded in audit history. In Rewards, definition edits, archiving and restoration require publish permission. See badge lifecycle before correcting an award.

Where next