Simulator

The dashboard exposes simulator tools only in staging or local development.

Dashboard paths

Operator Dashboard → Simulator → Simulator

Operator Dashboard → Simulator → Simulator Users

Required read scope: simulator:read

Mutation scope: simulator:write

Launch action scope: launch:write

Current simulator model

Simulator is user-scoped, not operator-wide.

The operator should keep its real integration mode, normally rest_v1, even in staging. Dedicated simulator-user APIs manage the server-side simulator classification; ordinary launch metadata cannot set or clear it. Normal staging users continue through the real wallet adapter path.

Simulator page

The Simulator page launches an existing dedicated simulator user into the real Mini App session flow.

Operators can:

• pick a simulator user and inspect balance/locale;
• choose opinion or enabled polyflight;
• mint a single-use launch URL when the session has launch:write;
• open the actual launched tab for Opinion or Polyflight UI drills;
• open the selected product's full webhook delivery monitor when the session has webhooks:read (plus polyflight:read for Polyflight).

Simulator Users page

The Simulator Users page manages staging-only users.

Operators can:

• create simulator users with external ID, display name, email, locale, and starting balance
• update display name, email, status, and locale
• inspect recent sessions, trades, resolutions, balance operations, and simulator wallet operations
• apply debit, credit, debit reversal, or credit reversal adjustments

The dashboard user-detail activity list is not a dedicated Polyflight ticket/payment inspector. Use the launched user's full webhook monitor and the scope-gated Polyflight ticket/balance-operation pages to correlate purchase, ticket, obligation and wallet evidence.

The separate Operator Simulator Webhooks page receives signed callbacks, displays all subscribed Opinion and Polyflight event families, and labels native minor-unit snapshots separately from receiver delivery status. Its Ensure action synchronizes the receiver signing secret while preserving subscriptions and unrelated endpoint URLs; edit the saved endpoint to add missing events.

Integration UAT is separate

Integrations → Integration UAT (/integrations/uat) is available outside the staging-only simulator pages and labels the current environment. It can call the real saved wallet adapter and mint real launches. It does not turn an ordinary user into a simulator.

Safe checks mean a successful balance lookup plus coverage of all selected-product allowlisted events across active endpoints; they do not mutate a wallet, invoke a callback, or prove product success. Open Mini App confirms URL mint/navigation only. After an authorized product action, Inspect evidence reads up to five recent matching records per source for the selected external user; use full pages and exact IDs for deeper history. Changing the user or product clears old evidence rather than carrying a previous pass across selections.

Scopes are exact, not implied: wallet_adapter:write alone does not grant the settings GET. Although the UAT interface may show the action for a write-capable session, a setup refresh can fail without wallet_adapter:read. Grant both for the saved-config UAT workflow.

Safe usage rules

• use staging-only users and external IDs
• create and maintain simulator classification only through Simulator Users or its dedicated API; metadata.simulator sent to launch is ignored
• do not switch the operator-wide rest_v1 adapter to simulator mode
• exercise native Polyflight purchase, win/loss, full refund, compensation, and manual-review states through the launched client
• do not inject cookies or substitute API-only calls for the launched-client UI workflow
• do not treat simulator success as proof of real wallet readiness
• run real REST v1 adapter contract tests separately against dedicated non-production infrastructure

Source API

Simulator dashboard pages use the endpoints listed in /docs/operator-api/simulator.