Tracking user counts

To monitor how many users have access to your Experience, subscribe to the user provisioning events and maintain a record of unique users per account. Seed the record from the list-users endpoint, then keep it current from the event stream.

Setup

1. Subscribe to the provisioning events. When creating your event subscription, ask for:

Event Fires when
provisioning.user.created A new user is provisioned in an account that has access to your Experience.
provisioning.user.deleted A user is deleted and no longer has access to your Experience.

2. Assign your Experience at the account level. When your Experience is assigned to an account, all current and future users in that account have access to it — which is what makes the running count meaningful.

  • Store the accountId, both for your own reference and to correlate incoming webhook events.
  • Seed your initial count from GET /users, filtered to that account.

Page through the account's users and add each id to the account's set as you go:

GET {baseUrl}/users?accountId=<account-id>&pageSize=200
Authorization: Bearer <access_token>

Repeat the request with the cursor value from the previous response until cursor comes back null — that is the last page. pageSize accepts 1 to 200 and defaults to 100. Do not change accountId, sortBy or sortOrder while replaying a cursor; that returns 400 and you have to restart the traversal without one.

The envelope's count field gives the total number of users matching the request across all pages, so you can check the set you have built against it once the traversal finishes.

One caveat: the list is served from a read model updated shortly after a write, so a user provisioned or deleted moments earlier may not be reflected yet. GET /users/{userId} is always up to date if you need to confirm an individual user, and re-reading the list is the way to settle a count that has to be exact.

Processing events

Each time a user is created or deleted in an account where your Experience is assigned, a webhook event is delivered to your endpoint. The data payload carries both userId and accountId, so you can attribute the change to the right account in real time:

{
  "type": "provisioning.user.created",
  "timestamp": "2026-07-10T14:32:18Z",
  "subscriptionId": "d9792eb7-56fb-4cfa-b303-8ce1b1f0b4b7",
  "scope": {
    "experienceId": "65d86040-2d31-4a77-a841-4ba783122c8b"
  },
  "data": {
    "userId": "bfbdc8ce-1be8-4bd5-96f4-4dc6351d643f",
    "accountId": "f90f4ada-6699-4697-a2da-216f92e61984",
    "updatedAt": "2026-08-06T20:59:08.959211386Z"
  }
}

Maintaining user records

Keep a set of unique userId values per accountId:

  • On provisioning.user.created — add the userId to the active-user set for that account.
  • On provisioning.user.deleted — remove the userId from that account's set.

Use a set rather than a counter. Events may be delivered more than once, so incrementing and decrementing a running total will drift on retries, whereas adding and removing a known userId is naturally idempotent.

Determining the active user count

The number of users with access to your Experience for a given account is the count of unique userId values currently tracked for that account. The count updates in real time as webhook events are processed.

To get a total across your whole Experience, sum the per-account sets — keeping them separate means you can still report per-account seat counts, which is typically what Service Providers and end customers ask for.