Admin
Operator console for the marketing site's own backend (coriqo-marketing-api): the tenant workspace pool self-serve signup hands out from, and the "Break the Seal" challenge. Everything here talks to that API directly; this page holds nothing of its own.
Sign in
The API checks these on every request. They are kept for this tab only and forgotten when you close it — not saved to the browser, so a shared machine does not keep them. Use this over HTTPS; HTTP basic credentials are readable in transit otherwise.
Works for any email added under "Admins" below (once you're signed in). We'll email a one-time link — it expires in 15 minutes and works once. Same anti-enumeration posture as the visitor sign-in: you'll see this message whether or not that email actually has access, so this can't be used to probe who the admins are.
Pool status
The pre-provisioned tenants a Free/Pro signup on pricing.html gets handed automatically (POST /v1/accounts/claim). Each one is a real tenant you already created in the core coriqo API — this table only tracks which are still spare.
Loading…
Loading…
Register a slot
Leave Tenant ID blank to create a brand-new tenant on the core API at this URL and file it into the spare pool — a random slug and throwaway placeholder admin credentials are generated automatically; POST /v1/accounts/claim overwrites them for real once a visitor claims this slot. Fill in Tenant ID instead for a tenant an operator already created directly on the core API (flagged pool=True there) — this only confirms it exists and files it into the pool, much faster since nothing gets created. Base URL must be one this service already trusts (CORPUS_CORE_API_ALLOWED_BASE_URLS) — this calls that API with a real operator credential, so an arbitrary URL here is rejected rather than sent one.
Tenants & users
Every account and every workspace slot, merged into one row per relationship — an account with no workspace yet, a claimed workspace next to the account that holds it, or a still-available slot with no account. Loaded in full (not paginated) so the filters below search and narrow it locally rather than round-tripping the API per keystroke.
Loading…
Subscription lookup
Pulls plan, status, seats and dunning state straight from the core coriqo API's own operator endpoint (GET /api/v1/tenants/{id}/admin-detail) for a single tenant at a time — not stored here, not cached, gone on refresh. Needs a PlatformOperator login, a different credential from the admin sign-in above (see api/domains/tenants/router.py's POST /operator/login). Kept for this tab only and forgotten when you close it, same as the admin credentials above — use this over HTTPS.
Signed in as on the core API.
Edit what a plan includes by default, or turn a feature on or off for specific tenants regardless of their plan. A change here reaches the product on its very next request — no deploy, no propagation delay.
Loading…
Per-tenant override
Turn a feature on or off for specific tenants, on top of their plan default. Only features registered as overridable on the core API can be set here — the catalog list above may include features that aren't (yet).
Sign in above loads this list.
Current overrides
Who currently has the selected feature explicitly on or off, and who set it — the audit trail for the toggle above.
Select a feature above.
Admins
Everyone who can sign in to this page by email, alongside the shared username/password. Adding someone here emails them a sign-in link immediately — no password to hand over or remember. Deactivating removes access right away, not at the next sign-in.
Loading…
Billing & subscription status
Which plan a tenant is on, payment/dunning state, and capacity headroom live entirely in the core coriqo API's own tenant records — Pro checkout posts straight there, never through this service — and already have a real console with its own operator login. This page doesn't duplicate it.
Open the operator console →Leads
Submissions from the "Get the gap analysis" form on obligations.html. Not the same as accounts above — a lead is not asked for a password or sent a sign-in link.
Loading…
The published bundle
What the download link on the challenge page serves right now. The checksum is computed from the stored bytes when you upload, so it always describes the file people actually get.
Loading…
Publish a new bundle
Uploading makes this file the download immediately. Previous bundles stay stored, so a challenger who downloaded an earlier one can still show what they worked from. Build the file with tools/build_bounty_bundle.py, which verifies it before it writes the zip.
Registrations
People who asked to be told when the bundle is published and when submissions open.
Loading…