The fifth of six Dashboard Guide pages — and the one with nothing else in this docs site to lean on or correct against, since neither tool has been documented anywhere before now. Two separate, real tools: the Authentication Playground, a fast single-method tester, and the Advanced Playground, which runs the actual @threshold1/auth SDK to exercise a full fallback configuration. Everything either one does is a real backend call — there is no simulated path in either feature.
Six method tiles are always shown — Passkey, Email OTP, Magic Link, TOTP, Backup Codes, and Automatic Fallback — but only four are real and clickable: OTP, Magic Link, TOTP, and Backup Codes. Passkey and Automatic Fallback are permanently disabled with a "Coming soon" tag, regardless of any toggle or configuration — they aren't functional here at all yet (see why, below).
The grid is config-aware. By default it's filtered down to whatever your project's real Auth Methods configuration actually allows — the same setting the Authentication page reads and writes. A "Show all methods" toggle reveals every real method regardless of that configuration. Worth knowing precisely: this is a display filter only. The Playground's backend routes deliberately don't enforce your project's live method allowlist at all, so a method your real end users can't use yet is still fully testable here — the toggle only controls what's shown, not what's callable.
The Test User panel starts with an auto-generated disposable address (playground+<random-hex>@playground.threshold1.test — the same fallback address format the backend routes themselves generate when no email is given). "New" swaps in a fresh disposable address and forgets the resolved test user; "Reset" only becomes available once a method has actually resolved a real user, and wipes that user's sessions, TOTP enrollment, backup codes, and any pending codes — a clean slate without creating a new user identity.
The Result Card, shown after running a method, has a fixed shape: Method, User, Risk Score (only for methods that actually compute one — TOTP verify doesn't, so it's simply absent there, not zero), Session (Created / Not created), and Webhook. The Webhook line is one of four real states — not applicable (this action never dispatches one), checking delivery, no delivery found, or found — and only in the "found" state do View Payload and Replay actually appear, showing the real event type and delivery status rather than a placeholder. Every single result carries a permanent REAL badge — this feature has no simulated code path to distinguish it from. One small real convenience: OTP's send step shows the actual generated code directly in the result, test-environment only, so you're never stuck checking an inbox to test the flow end to end.
Where the v1 Playground tests one method at a time, this one runs a real, unmodified @threshold1/auth SDK instance — the actual published package, not a mock of it — configured the way your own integration would be, against this project's test environment. The "API key" the SDK is handed here is actually your dashboard session token; these routes authenticate you as a signed-in dashboard user, never as a real API key holder.
The Config Panel's fallback-mode selector is the real centerpiece, with substantive, accurate explanatory copy for each option:
The method-override checkboxes (Magic Link, Email OTP — Passkey is shown but permanently disabled here too) are honestly disclosed as inert outside Manual mode: in Smart or Automatic, the SDK's own cascade order is fixed internally and can't be restricted per test, so the checkboxes only take real effect once you switch to Manual — there, they control which individual trigger buttons even appear. redirectUrl and External user ID are both fully real: the first genuinely changes where a magic-link flow redirects to for this test, and the second threads into the actual external_user_id bridging, visible afterward on the Users page.
Running a test: in Smart or Automatic mode you get three buttons — Run Register(), Run login(email), and (Smart mode only) Run login() with no identifier at all, which exercises the discoverable-login entry point with nothing pre-filled. In Manual mode, that whole area is replaced by direct per-method trigger buttons instead — no SDK cascade instance is even created in this mode, matching the real SDK's own fallback: "manual" behavior of never chaining methods on its own.
The Cascade Result is worth understanding for how honestly it's built, not just what it shows. The SDK's public API only ever reports a final method and outcome — it has no built-in "here's everything that happened" result — so the dashboard reconstructs the step sequence from three separate real signals: an onFallback callback (which fires once per method that failed before an eventual success, but never fires at all if every method fails), an intercepted console warning specific to a failed passkey step, and — only for the no-identifier discoverable-login path, which has no other observable signal — a static, empirically-confirmed explanation rather than a guess. When every method genuinely fails, the result never invents a step or a reason that wasn't actually observed.
Two things the result surfaces honestly rather than glossing over: a cascade that "succeeds" via Magic Link only means the email was queued — no session or user exists yet until the real link is opened, and the SDK has no code path to complete that for you, so the result says exactly that instead of implying a completed login. And the confirm_required/identifier_required outcomes describe exactly what a real integration's UI would need to show next (a masked-identifier one-tap confirm, or a bare identifier prompt) — never an actual send.
Hard-locked to test data, and worth being precise about how. Neither tool ever touches an API key at all — every route behind both Playgrounds authenticates with your dashboard session, and the environment is a literal hardcoded "test" inside each route itself. There's no key to select and no configuration path by which either tool could reach live data, even by accident.
Passkey — and by extension Automatic Fallback, whose cascade includes it — stays "Coming soon" in both tools for the same real, structural reason. WebAuthn requires the page's actual serving origin to match a project's registered domain, and every Playground page is served from the dashboard's own domain, never a developer's configured one. A passkey ceremony started here fails immediately — an RP-ID mismatch, or a missing test-domain configuration — before a real credential could ever be produced. This is blocked on a "Quick Test" subdomain mechanism that doesn't exist yet, which would let a Playground session run under a domain that actually matches a project's own configuration. Until that ships, the limitation is identical in both tools — it isn't a gap in one that the other has solved.