public active Last verified 2026-04-28

Topolo Quro

Public overview of the QR creation, redirect, analytics, and authenticated UI surface in the Topolo portfolio.

Owners
growth-platform
Source Repos
PlatformApplications/TopoloQuro, PlatformApplications/TopoloDocs
Systems
Topolo Auth, Topolo Quro
Tags
qr, redirects, analytics

What It Is

Topolo Quro is the QR creation, redirect, and scan-tracking application in the Topolo portfolio.

Architecture

The current repo shape includes an API worker, a redirect worker, a canonical modern UI, and a retained legacy UI used only for reference and parity checks.

Runtime Surfaces

Use /systems/topolo-quro for the current deployment inventory and service metadata.

API Reference

The active contract centers on QR creation, templates, analytics, redirect resolution, and org-scoped authenticated browser flows.

Auth and Permissions

The canonical current UI uses the first-party Topolo auth pattern with authenticated routes, branded embedded password login on quro.topolo.app, and callback flows. The legacy UI should not be treated as the active auth model. Protected Quro API bearer-token requests validate through Auth and do not accept locally decoded JWT claims from a Worker secret. Browser SSO callbacks delegate one-time sso_code redemption to the shared @topolo/auth-client package, so callback URLs carry short-lived codes rather than bearer tokens or /sso?token= bridge payloads. The canonical browser UI keeps a same-tab Auth token restore by default after sign-in and refresh, so a normal reload should reopen the authenticated dashboard rather than appearing signed out. Quro now also normalizes any missing Auth role claim to member in both the canonical browser UI and API worker bootstrap.

Data Ownership

Quro owns QR assets, redirect mappings, analytics, and related org-scoped settings and dashboards.

Deployments

Deploy Quro as a cluster of API, redirect, and authenticated UI surfaces. Treat the legacy UI as reference-only.

Failure Modes

  • legacy UI behavior is mistaken for the live product contract
  • redirect and analytics behavior drifts from the authenticated create/manage surface
  • auth flows are documented from the wrong UI generation

Debugging

Start with /systems/topolo-quro, then confirm whether the failing behavior belongs to the canonical UI, redirect worker, or API worker.

Change Log / Verification

  • Enabled same-tab browser session restore by default on 2026-04-23 so Quro reloads remain signed in after successful Auth handoff or refresh.
  • Corrected Quro role normalization on 2026-04-24 so missing Auth role claims resolve to member in both the canonical UI and API worker bootstrap.
  • Verified the canonical Quro branded password-login completion path on 2026-04-21 so first-party sign-in remains on the app origin after shared Auth persists the session.
  • Removed the Quro API worker’s residual local JWT_SECRET handoff on 2026-04-18 so protected bearer-token requests validate through Auth.
  • Removed the canonical Quro /sso?token= browser bridge on 2026-04-18 so /auth/callback now relies on the shared Topolo browser auth client for code redemption
  • Added canonical Topolo Quro coverage and retired repo-local Quro docs on 2026-03-30
  • Promoted canonical Quro browser SSO callbacks to Auth /sso/exchange on 2026-04-17 so callback URLs require a one-time sso_code instead of bearer tokens