Thank you for your detailed and courteous response. It fully answered my questions.

Hello brainCloud team,

We would like to better understand how billing/API Counts apply to operations triggered from the brainCloud Portal.

Our question is not limited to one specific feature. We are trying to clarify the general rule for Portal actions that execute backend operations, such as:

Refreshing or re-evaluating segments Refreshing promotions/pricing for users Running operations from API Explorer or S2S Explorer Triggering batch/user-processing jobs Other Portal buttons that may cause server-side processing

Could you please clarify:

Are backend operations triggered from the Portal counted toward billable API Counts or other usage metrics?

If yes, is the billing rule the same as calling the equivalent Client API, S2S API, or Cloud Code operation directly?

Are there Portal actions that are considered admin/configuration operations and are not billed as API Counts?

For operations that process many users or records, how is usage calculated?

Once per Portal action? Once per underlying API operation? Once per user/record processed? Or based on bulk-operation rules?

Where can we verify Portal-triggered usage in the brainCloud reports?

Is there a specific service/operation naming pattern we should look for?

Are scheduled/internal maintenance operations, such as automatic segment refreshes, billed differently from manually triggered Portal operations?

We are asking because we want to avoid unexpectedly increasing API usage or costs when using Portal features in production, especially for actions that may process many users.

Thank you!

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.