> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrieving Usage Data

> Export Curator usage and activity data programmatically using the Curator API.

The [Activity](/site_administration/activity/activity_overview) 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](/curator_api/api_docs/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:

```
[your_domain]/api/v1/datamanager/getDataTables?apikey=[your_api_key_here]
```

<Warning>
  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.
</Warning>

## 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.

```
[your_domain]/api/v1/datamanager/getData?apikey=[your_api_key_here]&table=interworks_usermgmt_content_view
```

**Example Response:**

```JSON theme={null}
    {
        "result": "Success",
        "data": [
            {
                "id": 4821,
                "frontend_user_id": 112,
                "username": "jane.smith",
                "viewable_content_type": "InterWorks\\TableauViz\\Models\\Dashboard",
                "viewable_content_id": 37,
                "request_root": "https://curator.example.com",
                "request_path": "/dashboard/sales-overview",
                "request_query": null,
                "created_at": "2025-02-19 16:11:10",
                "updated_at": "2025-02-19 16:11:10"
            }
        ]
    }
```

The columns that matter for reporting:

| Column                  | What it holds                                                                             |
| ----------------------- | ----------------------------------------------------------------------------------------- |
| `frontend_user_id`      | The Curator user who viewed the content. Join this to `listUsers` below.                  |
| `username`              | The username captured at view time, kept even if the user is later removed.               |
| `viewable_content_type` | The model class of the content, for example `InterWorks\TableauViz\Models\Dashboard`.     |
| `viewable_content_id`   | The ID of the content within that type.                                                   |
| `request_path`          | The path the user requested, useful when the same content is reachable more than one way. |
| `created_at`            | When the view happened. Sort and page on this column.                                     |

`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:

```
[your_domain]/api/v1/user/listUsers?apikey=[your_api_key_here]&num=100&pg=1
```

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](/curator_api/api_docs/user_api) for the full endpoint.

<Note>
  `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](/site_administration/backend_administrators/overview) in the portal
  backend.
</Note>

## Administrator activity

Content views cover what your frontend users opened. To see what administrators did in the backend, read
the usage log:

```
[your_domain]/api/v1/datamanager/getData?apikey=[your_api_key_here]&table=interworks_portal_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.

| Column        | What it holds                                                                                                 |
| ------------- | ------------------------------------------------------------------------------------------------------------- |
| `type`        | The action, such as `interworks.portal.api_key.create` or `interworks.portal.upgrade`.                        |
| `username`    | Who acted: a backend login, `system` for scheduled and console work, or `API (...key owner)` for an API call. |
| `is_frontend` | `0` for backend, console, and API activity, `1` for frontend activity.                                        |
| `details`     | Action-specific data, including a `_changes` set on edits.                                                    |
| `created_at`  | When the action happened. Sort and page on this column.                                                       |

<Note>
  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.
</Note>

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:

```
[your_domain]/api/v1/datamanager/getData?apikey=[your_api_key_here]&table=interworks_usermgmt_content_view&sort_column=created_at&limit=1000&offset=0
```

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](/site_administration/analytics_tracking/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.