Skip to main content
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 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.
  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.

​
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 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 reports an individual member’s limit and usage.
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.
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.

​
Example workflows

Here are some common ways to use the Monitoring API.

​
Compare monthly usage

1

Get current month analytics

Call Get analytics with this month’s date range to get current credit consumption and member activity.
2

Get previous month analytics

Call Get analytics again with last month’s date range to compare trends.

​
Find members over their credit limit

1

List users over their limit

Call 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.
2

Get member allocation detail

Call Get user for a specific member to see their member_allocation, including the limit, the source of the limit, and the credits remaining.

​
Audit an app

1

List users

Call List users to find users in your workspace.
2

List user apps

Call List user apps to get app IDs for a specific user.
3

Get app analytics

Call Get app analytics to get detailed metrics and governance flags for the app.

​
Paginate results

The Monitoring APIs use cursor-based pagination.
1

Send the first request

Call a list endpoint such as List users with supported filter and sort parameters. Omit cursor. Each response returns up to 50 items.
2

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

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.
Cursors expire after 24 hours. To refresh, repeat step 1. Changing filters, sort, or limit parameters between page requests returns a 400 error.