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

# Enterprise Monitoring API Overview

> Get started with the Base44 Enterprise Monitoring API

The Monitoring API provides visibility into your Base44 workspace, including member activity, resource consumption, and app configurations.

Use the Monitoring API to:

* Monitor usage and activity for apps and Superagents in your workspace.
* Track credit usage across your workspace and by individual users.
* Monitor your workspace credit pool and per-member credit limits.
* Monitor user activity and identify inactive accounts.
* Audit app security settings.
* Analyze engagement with views, active users, and usage trends.

## Workspaces

A [workspace](/documentation/account-and-billing/about-workspaces) is a shared environment where teams collaborate on apps and Superagents. The Monitoring API provides workspace owners and admins with aggregate data across the members, apps, and Superagents in a specific workspace.

### Workspace ID

Most endpoints require a `workspace_id` in the URL path, and you must have admin or owner role in that workspace to access them.

**To get your workspace ID:**

1. Go to [app.base44.com](https://app.base44.com/).
2. Click your profile icon at the bottom left of the screen.
3. Click **Account settings**.
4. Copy the workspace ID from the Account settings URL: `"https://app.base44.com/workspace/<workspace_id>/settings/account"`.

## Workspace members

Workspace members are people you invite to your workspace with a specific role. In the Monitoring API, members are sometimes referred to as users in endpoint names, path parameters, and response fields such as `user_id`. Learn more about [managing your workspace members](/Account-and-billing/Managing-your-workspaces#managing-your-members).

## Credit pools and member limits

Your workspace shares a single credit pool for each credit reset period. The pool tracks message and integration credits separately, and each reports its limit, the amount used, and the amount remaining. The reset period matches the one shown in your billing page. For yearly subscriptions that reset monthly, this is the monthly window.

The [`Get analytics`](/api-reference/analytics/get-analytics) response returns this data in the `credit_pool` object, including your tier, daily message limits, bonus credits, gift card balance, and over-limit flags.

Workspaces can also set per-member credit limits on how many message credits each member draws from the shared pool. A member's limit comes from either an individual override or a workspace default. The `member_allocations` object in the analytics response summarizes these limits across your workspace, and the `member_allocation` object on each user in [`Get user`](/api-reference/users/get-user) reports an individual member's limit and usage.

<Note>
  Per-member credit limits depend on your workspace tier. When your tier doesn't support them, members draw from the pool without an individual limit, and the per-member fields return `null`.
</Note>

<Warning>
  The `seats` and `user_distribution.by_seat_type` fields, the `seat_type` query parameter, and the per-user `seat_type` field reflect a legacy seats model and are deprecated. Workspaces on the current billing model share a credit pool and report zeros for these fields. Use `credit_pool`, `member_allocations`, and the `tier` query parameter instead.
</Warning>

## Example workflows

Here are some common ways to use the Monitoring API.

### Compare monthly usage

<Steps>
  <Step title="Get current month analytics">
    Call [`Get analytics`](/api-reference/analytics/get-analytics) with this month's date range to get current credit consumption and member activity.
  </Step>

  <Step title="Get previous month analytics">
    Call [`Get analytics`](/api-reference/analytics/get-analytics) again with last month's date range to compare trends.
  </Step>
</Steps>

### Find members over their credit limit

<Steps>
  <Step title="List users over their limit">
    Call [`List users`](/api-reference/users/list-users) with
    `over_member_limit=true` to return only members who have exceeded their
    per-member credit limit in the current credit reset period.
  </Step>

  <Step title="Get member allocation detail">
    Call [`Get user`](/api-reference/users/get-user) for a specific member to
    see their `member_allocation`, including the limit, the source of the limit,
    and the credits remaining.
  </Step>
</Steps>

### Audit an app

<Steps>
  <Step title="List users">
    Call [`List users`](/api-reference/users/list-users) to find users in your
    workspace.
  </Step>

  <Step title="List user apps">
    Call [`List user apps`](/api-reference/users/list-user-apps) to get app IDs
    for a specific user.
  </Step>

  <Step title="Get app analytics">
    Call [`Get app analytics`](/api-reference/apps/get-app-analytics) to get
    detailed metrics and governance flags for the app.
  </Step>
</Steps>

### Paginate results

The Monitoring APIs use cursor-based pagination.

<Steps>
  <Step title="Send the first request">
    Call a list endpoint such as [`List users`](/api-reference/users/list-users) with supported filter and sort parameters. Omit `cursor`. Each response returns up to 50 items.
  </Step>

  <Step title="Process the response">
    Each response includes a top-level array of items and a top-level `pagination` object. If `pagination.has_more` is `true` there are more pages to fetch.
  </Step>

  <Step title="Fetch remaining pages">
    While `pagination.has_more` is `true`, repeat the same request with the same filters and sort parameters. Set `cursor` to `pagination.next_cursor` from the previous response.

    <Note>
      Cursors expire after 24 hours. To refresh, repeat step 1.
      Changing filters, sort, or limit parameters between page requests returns a 400 error.
    </Note>
  </Step>
</Steps>