Console roles and pages
The OwlEye console is scoped to one app at a time. Pick an app in the header; OwlEye shows its app ID, primary domain, and your role. A read-only app still appears in the picker—it simply does not grow dangerous buttons when nobody is looking.
Roles in plain English
Section titled “Roles in plain English”| Role | Analytics and Events | Own Pro View | Rules | Users | Settings |
|---|---|---|---|---|---|
| Owner | Read | Create/edit | Write | Write | Write |
| Admin | Read | Create/edit | Write | Write | No |
| Read only | Read | Create/edit | No | No | No |
Every authenticated request resolves the app named in the URL and checks membership again on the server. Hiding a sidebar item is useful interface hygiene; it is not the security boundary.
AI access is a separate permission. An owner can allocate it to an admin or read-only member, so an analytics role does not silently imply an AI allowance. See AI mode and prompt allocation.
What each page does
Section titled “What each page does”- Overview shows the selected range’s page views, unique visitors, events, pages, geography, browser, operating-system, device, referrer, and opted-in UTM summaries. Overview trends accept up to 90 days in the current API.
- Pro View stores creator-owned custom chart and funnel definitions. Any app member can create their own view and invite app teammates to preview it. A recipient can accept or dismiss the invitation; an accepted view stays read-only and can be removed without affecting the creator or other recipients. Creators can revoke one recipient, revoke every shared copy, or delete the canonical dashboard for everyone. See Pro View sharing and funnels.
- Rules lets owners and admins create server-defined browser interaction rules.
- Events is a read-only explorer. It can search, filter, group, and sort up to one year of event data; it has no delete or mutation operation.
- Users lets owners and admins add existing OwlEye accounts as admins or read-only members, change non-owner roles, and remove eligible members. Owner membership is protected.
- Settings is owner-only. It covers the app name, ingestion pause state, AI enablement, read-only developer access, control-plane backup, and app deletion. Hosted subscription and support placeholders are cloud-only surfaces; public beta signup is Free and paid checkout is not implemented. See developer access and managed cloud beta.
The desktop sidebar can collapse to icons. At narrower widths it becomes a keyboard-accessible drawer, leaving the dashboard usable at the supported 370-pixel minimum width.
IDs: similar names, different jobs
Section titled “IDs: similar names, different jobs”- The app ID is the internal control-plane identifier used by authenticated management routes.
- The tracking ID is the public identifier configured in the browser SDK and stored with analytics facts.
Authenticated endpoints resolve either identifier for compatibility, but integrations should keep
the distinction clear. Put the tracking ID in useAnalytics; use the app ID returned by /v1/sites
when automating console management.
Site and access endpoints
Section titled “Site and access endpoints”All routes below require an authenticated console session.
GET /v1/sitesGET /v1/sites/{siteId}GET /v1/sites/{siteId}/eventsGET /v1/sites/{siteId}/membersPOST /v1/sites/{siteId}/membersPUT /v1/sites/{siteId}/members/{userId}DELETE /v1/sites/{siteId}/members/{userId}GET /v1/sites/{siteId}/settingsPUT /v1/sites/{siteId}/settingsGET /v1/sites includes an effective role and explicit permission flags for the signed-in user.
Consumers should use those flags to explain the interface, then rely on the API to enforce them.
The public demo uses the same response shapes with synthetic data. Demo mutation endpoints refuse writes; nothing from the demo is inserted into SQLite or ClickHouse.