Use API blocking in the cloud code category to block all apis from client that write your user entities. Then clients can only write their entities using cloud-code and there you have the total control

Delete call update and everything is working now. Thanks!

These points above are indeed good examples regarding "forcing bad practices":

If I have 3 free API calls after the API call, after the 3rd freebie, I can return it and call again for 1 core + 3 more that can branch off again. This is inefficient for BC, yet beneficial for end-users (thus, forcing bad practices since it costs and gives more if we avoid the pre and post hooks).

If a workaround to save API costs would be more work for the user, and costs more for BC, that's a lose-lose. If such a "hole" exists, shouldn't it be repriced for that consideration to make it the win-win you folks want it to be?

Hi Chris,

User entities are primarily indexed by profileId + entityType - so the singleton API will scale well no matter how many players you have.

That said, if your use case gets more complicated, with say hundreds of entities of a particular type per user (say maybe you are modelling user created towns, that sort of thing) - you could consider using Owned Custom Entities instead. You can define addition, custom indexes for those... keeps those lookups fast and efficient.

In addition, if you end up having >1000 Global Entities, you should definitely look at switching to Unowned Custom Entities. Same deal - you can define your own custom indexes...

Hope that helps!

Paul.

Hi @Alexandru ,

We've just officially added the Segment call you're looking for to brainCloud 4.55 - which is targeted for release in the next ~30 days...

Updated Roadmap here - https://portal.productboard.com/braincloud/1-braincloud-baas-roadmap

Paul.

Sounds good Ali - thanks for the confirmation!

Paul.

Thank you very much 🙂

Just noticed this was never replied to!

To clarify - our new Users API was delivered in 4.3 late last year.

Cheers!

Paul.