To clarify, the API call returns 200. The error comes from our Cloud Code validation because score is undefined. During MCP execution, getGlobalLeaderboardPageByVersion() returns entries containing bestScore and otherData, while score, data, and rank are missing. The same script works in Portal Run and Debug—the issue is the differing response structure.

opened Case 15301

The production app most likely has "Show Game Design Features" switched off. It's a per-app setting under Advanced Settings

We are developing our service using BrainCloud's S2S capabilities. The client-side application does not include the BrainCloud SDK. This is because we already have our own authentication system. When creating users via S2S, we use the "External Auth Create" method and subsequently handle operations based on the profileId. Therefore, to maintain a structure where existing user information is updated through the client's login process, the server must directly call the client authentication dispatcher API. In the S2S setup, there is an issue where authentication calls can only be used to issue sessions via the s2sdispatcher. Consequently, the server is manually invoking authentication using the client-side API. I consider this flow to be abnormal. After all, even though the integration is S2S-based, the client login API still needs to be called once. However, the issue is that without calling the client authentication, there is no way within the S2S setup to update the last login time and certain other information you mentioned. I believe this is a common issue that can arise when adopting and using Brain Cloud within an existing system, much like in our case. In summary, the user has created an external account in BrainCloud via the server using sysCreateUserExternalAuth. We issue a token to the user based on our internal authentication system, signing it using the BrainCloudProfileId. Consequently, authentication via the BrainCloud client is no longer required. However, without client-side authentication, there is no mechanism to update information. We need to find a solution to address this gap.

We've deployed the patch for this. Apologies for the delay!

Thanks for letting us know and your own solutions! We'll see if we can patch this into the JsonFx library we're using for future versions of brainCloud to avoid these edge cases.

Hi @moondory77 , We hear you - and are looking to see what options we can provide. The thing to understand is that there are a lot of dependencies between metadata in the brainCloud system - and our deployment mechanisms work hard to ensure the integrity of the data that gets pushed. Even more importantly - it works to prevent user data from being corrupted by a mis-match of data during deployments - which is why apps are very temporarily disabled during a deployment. These deployments normally take well under a minute and aren't much more troublesome than a common wifi interruption for clients [depends upon the client implementation though]... (note - the deployment may seem like it takes longer on the web - as there is a lot of data dependency checking to do - but all of that is done BEFORE we disable the app... which happens just for the actually data migration activity itself). If you contact us via the support chat with your appId and the time you last did a deployment - we can take a look to see if your deployment times are above normal. Also - we are working to provide a separate custom entity deployment mechanism - similar to what has been done for item management. Paul.

Thanks Paul, that makes sense. For now, we’ll keep using a dedicated internal/service profile with getSessionForProfile() + callAPIForSession() as a temporary workaround for our monthly transaction reporting job. Could you please confirm whether this workaround is safe to use temporarily in production, as long as we do not include a profileId in the search criteria and only use the session to authorize the request? Also, we’d appreciate it if you could let us know once the S2S proxy hookup for SYS_GET_TRANSACTIONS_PAGE has been reviewed or fixed. Thanks again for checking into this.

hi. @Paul-Winterhalder yes, permissions to call specific scripts and access control for Services and Operations regarding the generally provided functions are required. For example, there may be management tools that call specific scripts and use certain functions (CloudData...), and there may be administrators who only manage items. If possible, each API Key should be a function with permissions tailored to the situation. Let me give you an example. A company utilizes a mix of office and remote work. While the internal network can be protected to some extent by IP ranges, it is difficult to identify specific IPs because multiple operators work from home. Therefore, it is currently somewhat difficult to handle this situation using only IPs.

The SDK is just a plain C# source library you can drop into any .NET project (not Unity-only). You can find usage examples and the source in our GitHub repositories at https://github.com/getbraincloud.

@JasonL At the time I reported this, that field was locked too, so it couldn't be edited — but I've now confirmed that it's editable.

Is there no solution for this issue? Sending PDFs via email is very inconvenient. I would appreciate it if you could raise its priority.

Case 13633 - [implementing]

@Paul-Winterhalder , could you please respond to @noah 's inquiry?

It's been resolved. Thank you for your response!

Hey, thanks for reaching out. To answer your main question directly: yes, brainCloud's lobby and matchmaking system can trigger an Edgegap server deployment automatically. You do not need to build a custom C++ room server to make this work. https://github.com/getbraincloud/examples-cpp/tree/develop/relaytestapp The relaytestapp example on the develop branch of examples-cpp is a working client example that does exactly what you are describing. It uses brainCloud lobbies and matchmaking to find a match, and once the lobby is ready to launch, brainCloud handles spinning up the Edgegap server and passes the connection details back to all players through RTT. The server configuration you see in the screenshot is what ties everything together on the brainCloud side. That entry defines which Edgegap application to deploy, which regions to consider based on the selected beacons, and the credentials needed to make the deployment call. Once that server is linked to a lobby type, the entire launch sequence is handled for you. The relaytestapp is a solid starting point to see this end to end. [image: 1778170400682-screenshot-2026-05-07-at-12.13.17-pm.png]

@Paul-Winterhalder Hello! Here is my app Id "15675

Thanks @Brad-Hester !