Last updated 2026-04-26
OtiumWork_Admin section
The sidebar section labeled OTIUMWORK_ADMIN is the SaaS-owner control panel — distinct from per-tenant admin (/admin/*).
Architectural separation
| Surface | URL prefix | Audience | Purpose |
|---|---|---|---|
| Per-tenant admin | /admin/* |
Each company's admin role | Manages their company — employees, projects, billing, settings |
| OtiumWork_Admin | /ops/* |
SaaS owner only (allowlist) | Manages OtiumWork itself — Stripe keys, GA4, all tenants, platform metrics |
They live in separate sidebar sections and use separate access guards.
Items in the section
- Overview — every company on the platform, with seat count, primary admin, last activity, signup attribution
- Integrations — paste platform-wide secrets (Stripe, Anthropic, GA4, GSC) into a browser form
- Analytics — first-party traffic + signup funnel + SEO audit + GSC keywords. See Analytics
- Feature tracker — competitor feature board
- Competitor watch — RSS / changelog watcher
- LLM costs — Anthropic API spend per tenant / feature
- Blog — author public blog posts
Access gating
Two layers, both pointing at the same allowlist (env vars OPS_ACCESS_EMAILS or PRODUCT_OWNER_EMAIL):
- Sidebar section visibility in
base.html— the section only renders for owner emails - Route-level decorator in
app/routes/ops.py:require_owner— every/ops/*route returns 403 if the visitor isn't on the allowlist
So even if a non-owner hand-types https://otiumwork.com/ops they get 403 + see no menu items.
Adding more owner-only pages
- Create the route in
app/routes/ops.pyand decorate with@require_owner - Add the sidebar link inside the existing OTIUMWORK_ADMIN block in
base.html - Done — gating is automatic
See something wrong or outdated in this article? Report it →