We also strongly suggest using the ProductManagement service through a Cloud Code script to create and manage products programmatically, rather than entering them manually in the Portal. This can help automate catalog setup and make it easier to maintain product definitions in your own workflow. Please see the documentation here: https://docs.braincloudservers.com/api/capi/productmanagement/
brainCloudAdmin
Private
brainCloud personnel
Posts
-
Bulk import / API for registering in-app products -
Bulk import / API for registering in-app productsThanks for the suggestion. I’ll forward this feature request to our team for review. In the meantime, depending on your use case, you may be able to reduce the number of store product IDs you need to manage by using
CachePurchasePayloadContext(), introduced in brainCloud 5.8: https://updates.braincloudservers.com/?query=CachePurchasePayloadContext. It lets you cache additional purchase context before the transaction so brainCloud can combine it with the receipt during verification, potentially allowing product IDs to be reused across different items, offers, or price points. -
[Bug Report] Builder API deploy copies CustomEntities despite preservation being enabledHmm - I'll get the team to take a look at it.
-
SYS_UPDATE_CAMPAIGN_JSON (Campaign S2S) returns "Unrecognized request" even though our app is already running 6.0.1We've deployed the patch for this. Apologies for the delay!
-
SYS_UPDATE_CAMPAIGN_JSON (Campaign S2S) returns "Unrecognized request" even though our app is already running 6.0.1Okay - it looks like that script may be callable via cloud code script in S2S - but not via the S2S api directly... The devs are looking into it.
-
SYS_UPDATE_CAMPAIGN_JSON (Campaign S2S) returns "Unrecognized request" even though our app is already running 6.0.1Hi guys,
Can you still get this error? We can't repro it?
Paul.
-
Integration stream -
SYS_UPDATE_CAMPAIGN_JSON (Campaign S2S) returns "Unrecognized request" even though our app is already running 6.0.1 -
Integration streamHi Noah, thanks for the follow-up. Yes, for virtual item purchases, the stream event is triggered immediately in the same request flow, right after the purchase is finalized and verified. So the trigger point is immediate.
That said, the event delivery to downstream systems such as Kafka, Segment, or the Mongo log is asynchronous and queued, so it should not be treated as a synchronous low-latency real-time event.
We’ll also review your feature request for a Stream HTTP Webhook and will keep you posted.
