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:

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

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

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

4. 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?

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

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

6. 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!

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

Hi brainCloud team,

Thank you for the detailed explanation.

Based on your answer, I understand that Redemption Code should not be treated as the source of truth for production reward fulfillment / recovery state, especially for shared or multi-use codes.

For our current implementation, we are handling it like this:

• Redemption Code is used for campaign validity, shared-code redemption, and reward metadata.
• The Redemption Code custom metadata contains only a rewardDataId / rewardId.
• The actual reward content is resolved on our server from our RewardData.
• Reward fulfillment is executed by our server reward pipeline.
• Separately, we store a per-user claim state in a BrainCloud User Entity / Custom Entity.
• That claim state records statuses such as Redeeming, Redeemed, Granting, Granted, RedeemFailed, and GrantFailed.
• If redemption succeeds but reward fulfillment fails, we keep the claim state as Redeemed or GrantFailed and allow our server to retry the fulfillment step without requiring the user to redeem the shared code again.
• If the claim state is Granted, we block duplicate reward grants.

So in our design:

• Redemption Code owns code validity and whether the user has consumed the shared code.
• Our separate claim entity owns fulfillment state, retry state, and audit/recovery information.
• Redemption Code redeemed records are not used as the production recovery source of truth.

Does this align with the pattern you recommended?

Also, as a follow-up, we are currently calling BrainCloud from our server for multiple steps: claim state update, redemption, reward grant, and final claim update. We may consolidate the BrainCloud-side claim/redemption operations into a CloudCode script to reduce API round trips, while still keeping reward fulfillment in our server pipeline.

Would that be a reasonable approach?

Thanks again.

Hi brainCloud team,

We are considering using shared / multi-use Redemption Codes for operational rewards.

The main issue is not code distribution itself, but recovery when reward fulfillment fails.

Our desired flow is:

User redeems shared Redemption Code
→ reward fulfillment is attempted
→ if reward fulfillment succeeds, user should not receive it again
→ if reward fulfillment fails, we need a way to retry or recover
We would like to know whether Redemption Code is intended to be used as the source of truth for this kind of reward claim / recovery state.

Questions:

For a shared / multi-use Redemption Code, if a specific user already redeemed the code, can that user’s redeemed state be reset or deleted through any supported API or operator flow?

If reward fulfillment fails after redemption, is there a BrainCloud-side retry or recovery mechanism that allows the same user to receive the reward later?

Can customRedemptionInfo or fulfillment status be updated and used as a persistent per-user record of reward fulfillment success / failure?

If the only reset method is marking a user as a tester and deleting the redeemed record manually in the portal, is that intended only for testing and not for production operations?

For production operational rewards, would BrainCloud recommend:

shared Redemption Code + Fulfillment Script retry,
single-use personal codes per user,
a Custom Entity / external claim ledger,
or another pattern?
Our concern is this case:

RedeemCode succeeds
→ reward fulfillment fails
→ the user cannot redeem the same shared code again
→ we need an auditable retry/recovery path
We want to understand whether Redemption Code can own this recovery state, or whether we should manage claim status separately outside of Redemption Code.

Thanks.

Hello brainCloud team,
The feature you deployed appears to be working well. Thank you sincerely for your response!

If any issues arise in the future, I will organize and report back.

Hello brainCloud team,

Thank you for the clarification. That explanation helps us understand the current behavior.

We would like to add more detail about our current situation, because the issue we are seeing is not limited to users who were already in the segment before the Automated Promotion was created.

We created a new Automated Promotion and attached it to a target segment. After that, we had a user who was not previously in that segment become eligible by updating the relevant user statistic. After calling RefreshMySegments, the user appears in the target segment under User Monitoring > Pricing.

However, the promotion still does not appear under Associated Automated Promotions for that user, and GetEligiblePromotions / RefreshPromotions do not return it.

The promotion only starts being associated and returned after we manually use Reset Segments / re-evaluate segments for that specific user from the portal.

So the issue appears to be:

• The user is newly entering the segment after the Automated Promotion has already been created and attached.
• RefreshMySegments updates the user’s current segment membership correctly.
• But the Automated Promotion is not associated with the user.
• A manual per-user Reset Segments / re-evaluation from the portal makes it work.

Could you advise if there is any supported workaround for this before the planned fix is released?

Specifically:

1. Is there any Cloud Code, client, or S2S API equivalent to the portal Reset Segments / per-user re-evaluation action?
2. Does RefreshMySegments trigger the same enteredIds logic that Automated Promotions use, or does it only update the user’s current segment membership?
3. If RefreshMySegments does not trigger Automated Promotion association, what is the recommended way to launch a new Automated Promotion and have it apply to users who become eligible after launch?
4. Is there any safe operational workaround that does not require manually resetting segments for each user?
5. Do you have an estimated timeline or release version for the planned fix?

Our current blocker is that even newly eligible users for a newly created Automated Promotion are not receiving the promotion unless we manually reset/re-evaluate segments per user, and we need a scalable way to handle this.

Thank you again for your help.

Hello brainCloud team,

We are investigating the behavior of Automated Promotions for users who already satisfy the target segment conditions.

During testing, we found the following behavior:

1. A user is already in the target segment before an Automated Promotion is created or attached to that segment.
2. In User Monitoring > Pricing, the user appears under User's Current Segments.
3. However, the segment does not show the promotion under Associated Automated Promotions.
4. Calling RefreshMySegments from Cloud Code, calling RefreshPromotions, and logging in again do not cause the promotion to become associated or returned by GetEligiblePromotions.
5. If we use Reset Segments for that user, or run Re-evaluate All Segments, the promotion is then associated and returned.

Questions:

1. Is this expected behavior for Automated Promotions?
2. Should RefreshMySegments or RefreshPromotions attach newly created Automated Promotions to users who are already in the target segment?
3. Is there a client-callable or Cloud Code API equivalent to Reset Segments or Re-evaluate All Segments for the current user?
4. Is there any API to manually trigger or re-trigger an Automated Promotion for the current user?

Our concern is that if Automated Promotions only trigger on a new segment entry, then attaching a new promotion to an existing shared segment will not work reliably for existing users unless we manually reset or re-evaluate segments.

Thank you for your guidance.