Skip to main content
The Activity page reports on usage inside a single portal. When you want that same data in your own warehouse, BI tool, or reporting process, read it through the Curator API instead. Everything below uses the Data Manager read endpoints, documented in full at Data Manager.

​
Before you start

Each portal stores its own data. There is no combined endpoint across portals, so a multi-portal deployment calls each portal in turn and combines the results downstream. The set of readable tables is assembled from the plugins installed on a portal, so it varies by Curator version. Ask a portal what it supports rather than assuming:
Treat an API key like a password. Store it outside your scripts, and never paste a URL containing a real key into a support ticket, a shared document, or a source repository.

​
Content views

interworks_usermgmt_content_view is the table behind the Activity page. One row is written each time a user opens a piece of content.
Example Response:
The columns that matter for reporting: viewable_content_type and viewable_content_id together identify the content. Read the matching content table, such as interworks_tableauviz_dashboards or interworks_content_pages, to turn that pair into a title.

​
Summary table

interworks_usermgmt_content_view_summary holds one row per user and content item, with a last_visited timestamp instead of individual views. Use it when you want current totals rather than a full event history, since it is much smaller than the view table.

​
Favorites

interworks_usermgmt_favorite records which content users have marked as a favorite. It pairs well with content views when you are measuring engagement rather than traffic.

​
Users

Content view rows identify a user by ID and username. Pull the rest from the User API:
Each user comes back with their groups and their analytics_id. That analytics_id is the same non-personal identifier Curator sends to your analytics platform, so it is the key that lets you combine API exports with the analytics approach described below. See User API for the full endpoint.
listUsers covers frontend users and their groups. Backend administrator accounts are not exposed by any API endpoint. If you need an inventory of backend administrators, read it from Backend Administrators in the portal backend.

​
Administrator activity

Content views cover what your frontend users opened. To see what administrators did in the backend, read the usage log:
Filter to is_frontend = 0 for actions taken in the portal backend. Each row records the action type, the username behind it, and a details payload describing what changed.
Secrets are masked before they reach this table. An API key appears only as its last four characters, which is enough to tell two keys apart, and passwords are removed entirely. Older portals stored some of these values in full, and the upgrade that introduced the masking also rewrites those earlier rows.
Because the usage log records administrator actions, treat an export of it as sensitive and restrict who can read it, the same way you would the backend itself.

​
Paging

The default page size is 1000 rows, and requests carrying an apikey are rate limited. Page through a busy portal rather than requesting everything at once, and sort on created_at so paging stays stable while new rows arrive:
Increase offset by limit on each call until a request returns fewer rows than the limit.

​
Reporting across several portals

Curator has no cross-portal roll-up. Two approaches work, and they combine well:
  1. Call each portal and union the results. Add a portal identifier as you load each response, since IDs are only unique within a portal. This gives you the same detail the Activity page shows.
  2. Point every portal at one analytics property. Configure the same Google Analytics 4, Google Tag Manager, or Matomo property on each portal so page views and Dashboard events land in a single place already combined. See Analytics Tracking.
Because Curator sends the user’s analytics_id with each analytics event, and listUsers returns that same ID, you can map analytics activity back to a named Curator user when you need to.