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.
  • Track which apps are live and which are waiting for publish approval.
  • 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 workspace name at the bottom left of the screen.
  3. Click Settings.
  4. Copy the workspace ID from the Settings URL: "https://app.base44.com/workspace/<workspace_id>/settings/...".

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

​
App publish status

Each app in List app metrics and Get app analytics reports whether it’s currently live:
  • is_published: true when the app has been deployed and hasn’t been unpublished since, and false when it was never deployed or was unpublished.
  • last_published: The date of the app’s most recent deploy. The date is kept after the app is unpublished, so check is_published for the current status.
The is_published=true filter on List app metrics and List user apps returns only live apps, and summary.published_apps in Get analytics counts only live apps.
Before version 2.1.0, an app that was unpublished after deploying still reported is_published: true and was counted in published_apps. Now these apps report false, so your published_apps count can drop for apps that were taken offline. The lower count reflects which apps are actually live.

​
Pending publish requests

When a workspace member’s publishing permissions don’t allow them to publish, they can send a publish approval request instead. The Monitoring API shows pending requests until the app is published:
  • pending_publish_request: On each app in List app metrics and Get app analytics. Returns the most recent pending request, with requested_at, requested_by_user_id, and requested_by_email, or null when the app has no pending request.
  • summary.pending_publish_requests: In Get analytics. The number of apps with a pending request. An app with several pending requests counts once.

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

​
Find apps waiting for publish approval

1

Check for pending requests

Call Get analytics and check summary.pending_publish_requests to see how many apps have a publish request waiting for approval.
2

Find the apps and who requested them

Call List app metrics and look for apps where pending_publish_request isn’t null. Each request includes when it was made and the email of the member who made it.

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