Account-scoped data
Canonica documents use product, account, and workspace scope so support knowledge, tickets, widget settings, and summaries stay tied to the correct workspace.
Security
Built for support knowledge that must stay controlled
Canonica focuses on bounded context, tenant isolation, owner-approved answers, and clear workspace controls.
Security at a glance
The same shared infrastructure discipline used by MenuList is applied here, but Canonica keeps its own product boundary, widget runtime, and support-knowledge controls.
Product data boundary
Canonica workspace scope
Runtime database
Canonica Firebase project
Widget key storage
Hashed key, shown once
Widget placement
Allowed origins + blocked routes
Hosted help
Registry-scoped domains
Ticket context
Capped and sanitized
Answer authority
Owner-reviewed canonical answers
Expensive requests
Rate-limited endpoints
Scheduler output
Compact summary docs
MenuList relationship
Separate product boundary
Safe widget context
Widget context is designed for page, route, feature, workflow, role, and plan hints. It is bounded and should not include secrets, tokens, passwords, payment card data, or unrelated personal information.
Origin and route controls
Workspace owners can configure allowed origins and blocked routes so the widget appears only where the product owner wants it.
Hosted help domain registry
Hosted help domains resolve through Canonica-owned registry documents so anonymous docs, FAQ, changelog, robots, and sitemap pages never depend on client-supplied tenant IDs.
Ticket debugging context
Tickets can include a capped, sanitized snapshot of recent browser context at creation time so owners can debug broken screens without asking customers for technical details.
Owner-approved authority
Generated drafts, entity candidates, and mutation proposals require human review before they become active canonical answers.
Bounded logging
Operational logs are meant for reliability, failure analysis, and abuse protection. Production flows should avoid storing raw sensitive payloads.
Separate product infrastructure
Canonica is maintained as a separate product from MenuList, with Canonica-owned dashboard routes, constants, schedulers, widget configuration, and Firebase data.
Trust controls
What Canonica protects by design
These controls map to the implemented Canonica runtime: dashboard APIs, widget config, widget search, feedback, tenant-scoped rules, summaries, and owner review queues.
Workspace isolation
Canonica management routes resolve a Canonica product account and workspace before reading or writing workspace data.
- Canonica documents use product, account, and workspace scope.
- Dashboard APIs check Canonica scope before mutations.
- Canonica Firebase rules default to deny and allow tenant-scoped access explicitly.
Widget runtime control
The widget is designed to be installed on selected product pages, not sprayed across every route by default.
- Widget keys are stored as hashes after creation.
- Allowed origins restrict where runtime config can be used.
- Blocked routes let owners hide the launcher on sensitive screens.
- Malformed cn_* keys are rejected before expensive lookup work.
Hosted public help
Canonica can publish reviewed support content on support domains without exposing authenticated support operations.
- Domain registry docs resolve workspace scope server-side.
- Anonymous pages render published docs, FAQ, changelog, robots, and sitemap only.
- Tickets, chat history, feedback writes, and account data stay out of hosted help.
Ticket debugging context
Canonica keeps ticket debugging context useful by tying it to the reported issue instead of broad background collection.
- Recent browser context is captured only when a ticket is created.
- The payload is capped and intended for debugging the reported issue.
- Support teams see context in the ticket instead of asking users to describe browser-level details.
Bounded page context
Canonica treats page context as a hint for support relevance, not as trusted identity or tenant authority.
- Context should describe page, route, feature, workflow, role, or plan.
- Secrets, tokens, passwords, payment card data, and unrelated personal data should not be sent.
- Server-side validation keeps tenant scope separate from client-provided context.
Governed answers
Support correctness comes from approved knowledge, not automatic rewriting.
- Canonical answers are served before fallback.
- Drafts and mutation proposals remain review work until approved.
- Drift and signal checks surface stale or missing knowledge.
Cost and abuse controls
Canonica keeps high-cost and public runtime paths bounded so one noisy widget cannot become an uncontrolled backend workload.
- Public widget config, search, and feedback endpoints are rate limited.
- Repeated canonical hits can use cache with freshness checks.
- Dashboards prefer summary documents over broad collection scans.
- Hosted help content uses cached public payloads and compact display fields.
Operational separation
Canonica shares a codebase with MenuList, but its product data and support runtime are maintained as a separate product.
- Canonica has product-owned routes, constants, schedulers, and dashboard sections.
- Canonica Firebase config can run separately from MenuList Firebase.
- MenuList is a client/use case, not a hardcoded Canonica dependency.
Security and responsible disclosure
Report security, privacy, or data-handling concerns to the Canonica team. Do not include secrets, production credentials, or full customer data in the first message.
hello@canonica.app