TopoloOne
Public overview of the TopoloOne dashboard, worker-backed growth surfaces, and the public developer-acquisition funnel.
What It Is
TopoloOne is the unified operational dashboard for managing services, API keys, and platform-level workflows across Topolo applications, plus the public growth surface for pricing, demos, waitlists, launch content, and developer-program acquisition.
Architecture
TopoloOne is split between the dashboard web application and the routing worker that serves the production hostname and worker-backed APIs.
The marketing and signup payment surfaces in the repo now route outbound Stripe checkout and subscription retrieval through Topolo Nexus while keeping Stripe webhook signature verification and subscription-state persistence local to the worker boundary. The public pricing story uses a ratcheting early-supporter seat price: early supporters lock a lower rate, the next seat price rises after each signup, and metered services stay separate from the base seat subscription.
The marketing project also serves as the acquisition layer for changelog/content publishing, the curated /apps portfolio, developer-program overview content, and future SEO campaign or child-site surfaces, as long as those routes stay aligned to the canonical host and deployment contract. Public developer CTAs now continue into the separate TopoloDevelopers application at developers.topolo.app/signup.
Runtime Surfaces
TopoloOne currently ships two public runtime surfaces: the dashboard at https://one.topolo.app and the marketing/growth site at https://one.topolo.io. The authenticated developer portal at https://developers.topolo.app is a separate application.
API Reference
Use the per-app API page at /reference/apps/topolo-one for the current client contract and Auth-backed request paths.
Auth and Permissions
TopoloOne does not own service scope definitions or bindable resource catalogs. It reads both from Topolo Auth and submits key-management changes back to Auth.
Its dashboard browser session flow now uses the shared Topolo cookie-refresh auth client and the canonical svc_oneclick_dash service identifier.
Anonymous checkout and webhook-side payment flows use Nexus trusted service credentials rather than app-local Stripe API keys. These calls are attributed to the Auth organization with slug topolo.
Restricted admin views for subscriptions and demo bookings now use server-issued session cookies instead of any client-visible password gate.
Public developer CTAs hand users into developers.topolo.app/signup, where the shared Topolo browser auth client and Auth-owned developer-platform routes take over instead of a separate local account store.
Data Ownership
The dashboard owns its delivery and UI state, but the canonical API key scope and bindable-resource catalogs remain in Auth. Nexus owns the standardized outbound payment provider invocation used by the marketing site.
Deployments
TopoloOne deploys as a dashboard web surface plus a worker-backed delivery/routing layer. The public marketing Worker also owns the curated app-portfolio routes, developer-program routes, waitlist, demo-booking, checkout, and acquisition-content delivery for https://one.topolo.io. The authenticated developer continuation lives in the separate TopoloDevelopers application on https://developers.topolo.app.
Failure Modes
- stale or incorrect hostname/bundle serving the dashboard
- UI pointing at the wrong Auth route
- selected service IDs not matching the Auth registry
- missing Nexus service credentials or fixed org attribution on marketing checkout or payment routes
- webhook verification and outbound payment API calls being treated as the same integration boundary
- canonical host drift between
.appand older.ioURLs - broken marketing admin sessions due to missing worker-side admin secrets
Debugging
Start with /systems/topolo-one for the generated handbook and /reference/apps/topolo-one for the contract surface.
For payment issues, distinguish local webhook-signature failures from outbound Nexus payment failures before checking Stripe.
For public-site regressions, validate the canonical https://one.topolo.io URL, sitemap output, and worker /health route before assuming a content or design issue.
Change Log / Verification
- Restored the ratcheting early-supporter per-seat pricing model on 2026-04-10 so the public TopoloOne pricing surface again rewards early supporters with a permanently lower locked rate while keeping metered services separate from base subscription seats
- Repointed the public developer CTA handoff to
developers.topolo.app/signupon 2026-04-10 while keeping TopoloOne focused on overview and acquisition content rather than multiple public developer forms - Hardened the public marketing and pricing surface on 2026-04-10 so TopoloOne now serves worker-backed checkout, waitlist/demo flows, cookie-based admin sessions, and canonical marketing metadata from the same production delivery boundary
- Refreshed the TopoloOne marketing portfolio on 2026-04-10 so
/appsnow reflects the wider Topolo application set with curated product media, and/developers/*now acts as the public intake surface for developer applications and app submissions - Standardized the TopoloOne dashboard browser auth layer on the shared Topolo auth client on 2026-03-31
- Verified against the current TopoloOne API key flow and Nexus-backed marketing payment routes on 2026-03-30