Question about CloudCode API Hook and Global Property read costs / usage count

[gyutaelee]

Hello,

We are planning to use a CloudCode script.RUN API Pre-hook to enforce a client app version gate.

The flow is as follows:

1. The client calls ScriptService.RunScript once.
2. A script.RUN Pre-hook runs our Pre_VersionGate CloudCode script.
3. Inside Pre_VersionGate, we call bridge.getGlobalProperty("VERSION_POLICY") once.
4. If the policy allows the request, the original CloudCode script runs.
5. If the policy blocks the request, the Pre-hook returns 403 and the original script does not run.

We would like to confirm how this affects usage and billing.

Questions:

1. Does the script.RUN Pre-hook execution count as a separate CloudCode execution or API count in addition to the original RunScript call?
2. Does bridge.getGlobalProperty("VERSION_POLICY") inside the Pre-hook count as an API call / usage count?
3. The CloudCode documentation mentions that the first 3 API calls are free and each call after that counts as 1/2. Does this rule apply to API Hook CloudCode scripts as well?
4. In the normal pass-through case, how is the usage count calculated?
   • 1 client RunScript call
   • 1 Pre-hook execution
   • 1 getGlobalProperty call inside the Pre-hook
   • 1 original CloudCode script execution
5. In the blocked case, the original CloudCode script does not run. How is the usage count calculated in that case?
6. Could reading a Global Property on every script.RUN call become a performance or cost concern?
7. For a version policy that is read frequently but changed rarely, is there a recommended caching approach in BrainCloud?
8. Are there any Portal or usage report metrics where we can separately check the following?
   • API Hook execution count
   • CloudCode script execution count
   • CloudCode internal API call count
   • Global Property read count

We do not have an exact traffic estimate yet, so for now we would like to understand how usage count is calculated for this structure.

Thank you.

[JasonL]

Hi @gyutaelee ,

Based on the current brainCloud's implementation, here are the answers to your questions:

Q1: Does the Pre-hook count as a separate CloudCode execution / API count?**

Yes. The Pre-hook counts as both a separate API call and a separate CloudCode script invocation. After running, the server publishes its own analytics event with operation "RUN_HOOK-Pre_VersionGate" that increments both counts.

Q2: Does bridge.getGlobalProperty() count as an API call?**

No. bridge.getGlobalProperty() is completely free. It reads directly from the cached Game object in memory and bypasses the API call tracking pipeline entirely.

Q3: Does the "first 3 free, then 0.5 each" rule apply to hook CloudCode scripts?**

Yes, the discount applies to internal calls from any script or hook within the session.

Q4: Pass-through case: usage count breakdown

• Client calls script.RUN: +1 API call
• Pre-hook executes: +1 API call
• bridge.getGlobalProperty() inside hook: free
• Original CloudCode script: +0 (covered by the original script.RUN request)

Total external API count: 2

Q5: Blocked case: usage count breakdown

• Client calls script.RUN: +1 API call
• Pre-hook executes: +1 API call
• bridge.getGlobalProperty() inside hook: 0 (free)
• Original script: +0 (does not run, server throws before invoking it when hook returns non-200)

Total external API count: 2

The blocked case costs the same as pass-through from an API-count perspective. The only savings is that the original script's internal bridge.callAPI() calls are avoided.

Q6: Could reading a Global Property on every script.RUN become a performance or cost concern?

Performance: No. getGlobalProperty() reads from an in-memory cached Game object (ConcurrentHashMap per node) with no DB query or network call.

Cost: The hook itself adds +1 API count to every script.RUN call that has the hook attached.

Q7: Recommended caching approach for frequently-read, rarely-changed property?

The cache is already in place, no additional caching needed. brainCloud stores the Game object (including all global properties) in an in-memory cache for each server node. Cross-node invalidation is handled automatically when a global property is updated in the portal. Using bridge.getGlobalProperty() is already the optimal pattern.

Q8: Portal metrics: what can be broken down separately?

• API Hook execution count: Partially available. Hooks appear within the CC script invocation counter; no hook-only counter exists.
• CloudCode script execution count: Available as CC Script Invocations, but includes hooks in the same counter.
• CloudCode internal API call count: Available as CC API Calls in the Monitoring dashboard.
• Global Property read count: Not tracked. No metric exists for this.