brainCloud personnel
Unfortunately, our notification templating system is very simple and currently only supports simple text notifications. It does not currently push a template id.
We do have plans to revamp the system on our "to-do" list - but it has not been scheduled yet.
We recommend folks use the "raw" template calls - they give devs the most control over what gets sent to the various notification systems.
Paul.
To answer your questions:
I'll get the devs looking into #2.
Paul.
Hi,
API calls triggered by the backend DO count towards API usage -- so using the API Explorer to make calls do get counted as API calls. So - if you use API explorer to trigger a user batch job that then runs scripts on all of your users - yes, yes that does get counted as API calls. 
Also - uploads of files to and from the portal do get counted in the file transfer costs.
Other normal portal operations - like viewing users, viewing logs, editing scripts, etc - do NOT get charged in API counts. So to clarify - using the API explorer to view a leaderboard is going to add an API count - but using the leaderboard viewer at App > Global > Leaderboards > Leaderboards does not!
To be honest - in general - usaging of the portal is negligible. You won't really notice the usage added by what you're doing in the API explorer or working through the portal. It's only if you use the API Explorer to kick off a large job that API counts would be noticable <-- as you'd expect!
I hope that helps!
Paul.
Hmm - we'll look into it. Definitely looks like it isn't hooked up to the S2S proxy properly.
Thanks for reporting this.
Hi @Omar-Alzayed When apps have millions of users, browsing all users can have poor performance.
If you have a smaller number of users, it can be useful.
There is a way to create a segment so you can browse all your users.
Go to App > Design > Segmentation > Segments
Create NEW SEGMENT
There's a couple different ways you can return ALL users. The one I like is to use the criteria A/B Testing ID 0-99 which will return all your users.
Looks something like this:
Segments are automatically run nightly at around 3am but you can press REFRESH SEGMENTS to run it immediately.
Note that the refresh will take time to complete according to your user count, you may wish to do this during low player traffic.
In the case of this particular segment, I believe the Refresh will need to run TWICE to capture all your users. (I think the AB code needs to be initialized in the first pass, and then it can be read in the second pass, capturing all of your users.)
Please take care not to launch the second Refresh before the first one completes. (If you have 10,000+ players then wait about 30 minutes or so)
Once you have players in the Segment, you can browse by Segments. Go to
User > User Browser
Choose BROWSE, then check the box to browse within a segment. Choose the segment.
Reminder, once you have millions of users, this can be very slow. But you can create more refined Segments to filter to just the interesting users, such as Has Bought Something, Is at Least Level 10, and so on.
Segments allow compound conditions so you can really filter to exactly who you want.
Segments can also be used to target Sales and Promotions to specific player groups. For example you could create a $0.99 one-time, loss leader promo that is available to only those players who have not bought anything in your game yet. It's a very powerful system.
Could you let me know if this helped you?
Thanks
John
Yes, your current design matches the recommended pattern: Redemption Code is a one-way gate for “has this user consumed this shared code?”, while your claim entity is the authoritative state machine for fulfillment, retries, and audit (Redeeming → Redeemed → Granting → Granted / GrantFailed), with Granted as the idempotency guard for duplicate grants. The main thing to watch is call ordering: it’s preferable to write the claim to Redeeming first as an intent record, then call redeemCode(), so any Redeeming with no further progress is detectable and recoverable by your server without depending on the Redemption Code record.
Consolidating the brainCloud-side claim init + redemption into a single CloudCode script is a good fit, provided the script is strictly idempotent and fulfillment stays in your server pipeline. The script should read the claim state, upsert to Redeeming if needed, call redeemCode() (skipping if already Redeemed or beyond), update the claim to Redeemed, and return rich state (claimState, claimId, rewardDataId) so your server can then perform fulfillment and issue a final Granted / GrantFailed update. This gives you a clean two-call pattern from the server to brainCloud on the happy path, while the script’s state checks make retries safe even though CloudCode itself is not transactional.
For a shared/multi-use Redemption Code, a specific user’s redeemed record can only be reset or deleted through the tester-only deleteRedemptionForTester() flow, so there is no supported production operator/API path for non-tester accounts, and the tester reset should be treated as a QA/dev tool rather than a live recovery mechanism.
If reward fulfillment fails after redemption, it does not provide an automatic recovery or re-execution path that restores the same user’s redemption state in production; synchronous failures record a failed attempt, async flows can end in Failed on timeout, and any retry is only possible if the code type’s maxRetries still allows another user-initiated redeemCode() attempt.
customRedemptionInfo can be used as a persistent per-user audit field if your fulfillment script writes it back, since it stores the script response on the user’s code record. However, it is not designed to be updated later through a direct external API after the fact.
The tester reset is explicitly intended for testing/cleanup only, not as a production recovery operation.
For production operational rewards, the safest pattern is a shared Redemption Code for claim detection, plus a separate Custom Entity for the fulfillment state, which provides auditable handling of pending/fulfilled/failed/retrying without relying on the Redemption Code record as the source of truth.
Hi @moondory77 ,
Yes, you observed correctly.
During the data migration portion of the deployment (which occurs after the system has done a bunch of validation and consistency checks), the system temporarily disables your app to do the actual data migration.
This is to protect the data integrity of your app - as your app's metadata, reference data and cloud code scripts are all changing underneath it. So we disable the app, make the changes, and re-enable the app.
All of this normally takes just a few seconds - though it does depend upon the number of changes being made.
I hope that helps to clarify things!
Paul.
