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.