Hi BrainCloud Team,

Following up on our earlier Campaign discussion — we tested the new S2S operations
introduced in 6.0.1 (SysUpdateCampaignJson / SysUpdateScenarioJson) against our dev
app, and SysUpdateCampaignJson consistently fails with "Unrecognized request."

• Test campaign: CMP_TEST_01 (status: In Progress, no end date — never expires)

Confirmed server version (via client GetServerVersion, authenticationV2/GET_SERVER_VERSION):
"serverVersion": "R6.0.1-194"
So the app is already running 6.0.1, not an older build.

Request (via S2S Explorer, flat single-operation format):
{
"appId": "{Our_AppID}",
"serverName": "{Our_ServerName}",
"serverSecret": "***",
"service": "campaign",
"operation": "SYS_UPDATE_CAMPAIGN_JSON",
"data": {
"ccCall": false,
"campaignCode": "CMP_TEST_01",
"version": -1,
"campaignJson": { "theme": "winter", "bannerId": 7 }
}
}

Response:
{
"reason_code": 40001,
"status_message": "Processing exception: Unrecognized request: service=campaign, operation=SYS_UPDATE_CAMPAIGN_JSON.",
"status": 400
}

What we've already ruled out on our side:

• Campaign state/schedule — campaign is active and never expires.
• Plan/tier gating — LiveOps Campaigns menu is visible and campaign creation works
  in our portal, so this isn't an Enterprise-tier access issue.
• serverName — retried with the correct registered credential name
  ("{Our_ServerName}" instead of a placeholder "CloudCode"); identical error.
• Request format/casing — matches the same convention as other SYS_ operations we
  already call successfully (e.g. SYS_UPDATE_ENTITY, SYS_GET_SEGMENT_LIST).
• reason_code 40001 semantics — confirmed via the C# client SDK's ReasonCodes.cs
  that 40001 (INVALID_REQUEST) is a generic shared bucket code, not specific to
  "campaign ended" (that would need a distinct message string, which we did not
  receive — ours literally says "Unrecognized request").
• Version rollout timing — directly disproven; GetServerVersion confirms 6.0.1 is
  already live on this app.

We also tried a session-based (client-authenticated) call to the same operation,
which returned 403 Forbidden instead of 400 — a different error, but we don't think
it's a clean comparison since Sys* operations are S2S-only by design.

Given the operation is documented, listed in the 6.0.1 release notes as live, and
selectable in the portal's own S2S Explorer, but still fails with "Unrecognized
request" on a fully up-to-date app with valid credentials, we suspect either the
operation isn't fully wired into the S2S dispatcher yet, or there's some
app-level/credential-level permission gate we're not seeing. Could you confirm
whether SYS_UPDATE_CAMPAIGN_JSON should be callable for our app as-is, or if
there's an additional enablement step on your end?

Happy to provide additional repro details (packet IDs, timestamps, etc.) if useful.

Thanks.

The answer was very helpful. Thank you for the quick feedback!

Hi brainCloud team,

We're evaluating the LiveOps Campaign feature for a time-limited in-game event system, and based on the public documentation and our local SDK/CloudCode type definitions, we've drawn some conclusions we'd like to confirm before committing to a design around them. Could you help verify the following?

1. No write/update operation for Campaign definitions
   Per docs.braincloudservers.com/api/capi/campaign/ and .../api/s2s/campaign/, the only operations exposed are GetMyCampaigns, SysTriggerCampaignForUser, SysRemoveCampaignForUser, and SysRemoveAllCampaignsForUser — all of which manage a specific player's enrollment/participation, not the campaign definition itself. We see that GetMyCampaigns returns free-form campaignJson and scenarioJson fields, but we can't find any operation (Client API or S2S) that writes to campaignJson/scenarioJson/startAt/endAt/scenarios/overrides after the campaign is created.

Is this correct — is Campaign definition data (including campaignJson) only editable through the Design Portal UI, with no API path (including any Server-to-Server or "Sys"-prefixed operation) to create or update it programmatically?
Is there a separate Builder/Design API (e.g. using a personal team-member API key rather than app credentials) that does support programmatic campaign creation/updates? If so, could you point us to its documentation?

2. Trigger evaluation timing
   The docs state Trigger is "evaluated on LOGIN or REGISTRATION." For a player who is already in an active session when a campaign's startAt passes, will they be evaluated/enrolled into that campaign before their next login (e.g. on their next authenticated API call), or strictly only on an actual login/registration event? If the latter, is there any other mechanism (e.g. session refresh, heartbeat) that also triggers re-evaluation?

3. Feature maturity / plan tier
   LiveOps Campaigns is marked beta as of SDK 6.0 documentation.

Is this feature considered stable enough for production use in a live game (i.e. tied to real reward grants), or is it still recommended for experimentation only?
Our production app is on a Bulk+ 100M plan add-on over a Business Plus baseline. Does this tier fully support Campaign, or does it require a separate Enterprise-tier confirmation?

4. Cross-environment campaign management
   We maintain separate brainCloud apps for dev/staging/production and use our own internal tooling to diff and promote Custom Entity–based content between them via S2S. Since Campaign isn't a Custom Entity, is there any supported way (API-driven or otherwise) to keep a Campaign definition consistent across multiple apps, other than manually re-creating it in each app's Design Portal?

Thanks in advance — confirming these will directly decide whether we build our event schedule/targeting on Campaign or on an alternative (Custom Entity–based) mechanism.

Best regards

Hello brainCloud team,

We need to send localized Notification Template pushes to an ad-hoc list of profileIds, often thousands of users, provided by operations as a file.

This is not a pre-defined Segment or Group. We want to target only the profileIds in that file, while still using brainCloud Notification Templates for localization.

Is there currently a bulk API that sends a Rich/Template Push Notification to an arbitrary list of profileIds?

From the docs, we found single-user template push and group template push, plus raw/normalized batch push APIs, but we could not find a template/rich push batch API for arbitrary profileId lists.

If this is not currently supported:

• Is it planned?
• What is the recommended workaround?
• How is billing counted if we call SendRichPushNotificationWithParams once per profileId from Cloud Code?
• Would any planned bulk API support substitutions and custom metadata/custom data?

Thanks!

Hello brainCloud Support,

We are using brainCloud Push Notifications through the Portal Notification Templates feature.

Our current use case is:

We create notification templates in the brainCloud Portal.
We send or schedule notifications from the Portal.
On the client side, when the user opens a push notification, we need to identify which notification template was used.
Currently, the payload we can see appears to only include the APNs payload, like:

{
  "aps": {
    "alert": {
      "body": "Push message"
    }
  }
}

We would like to know:

Is there any way to add custom data or a custom top-level payload field when sending notifications from Portal Notification Templates?
For example:

{
  "aps": {
    "alert": {
      "body": "Push message"
    }
  },
  "notificationTemplateId": "daily_reward_push"
}

Does brainCloud automatically include the template id, template name, or any other template identifier in the push payload received by the client?

If Portal Notification Templates do not support custom payload data, what is the recommended approach for this use case?
Should we use Cloud Code, Normalized Push Notifications, or Raw Push Notifications instead?

Our goal is to continue managing notification text/localization/scheduling from the Portal if possible, while still allowing the client to distinguish which template triggered the push.

Thank you.

Hello brainCloud team,

We would like to better understand how billing/API Counts apply to operations triggered from the brainCloud Portal.

Our question is not limited to one specific feature. We are trying to clarify the general rule for Portal actions that execute backend operations, such as:

• Refreshing or re-evaluating segments
• Refreshing promotions/pricing for users
• Running operations from API Explorer or S2S Explorer
• Triggering batch/user-processing jobs
• Other Portal buttons that may cause server-side processing

Could you please clarify:

1. Are backend operations triggered from the Portal counted toward billable API Counts or other usage metrics?

2. If yes, is the billing rule the same as calling the equivalent Client API, S2S API, or Cloud Code operation directly?

3. Are there Portal actions that are considered admin/configuration operations and are not billed as API Counts?

4. For operations that process many users or records, how is usage calculated?

   • Once per Portal action?
   • Once per underlying API operation?
   • Once per user/record processed?
   • Or based on bulk-operation rules?

5. Where can we verify Portal-triggered usage in the brainCloud reports?

   • Is there a specific service/operation naming pattern we should look for?

6. Are scheduled/internal maintenance operations, such as automatic segment refreshes, billed differently from manually triggered Portal operations?

We are asking because we want to avoid unexpectedly increasing API usage or costs when using Portal features in production, especially for actions that may process many users.

Thank you!

Thank you for your detailed and courteous response. It fully answered my questions.

Hi brainCloud team,

Thank you for the detailed explanation.

Based on your answer, I understand that Redemption Code should not be treated as the source of truth for production reward fulfillment / recovery state, especially for shared or multi-use codes.

For our current implementation, we are handling it like this:

• Redemption Code is used for campaign validity, shared-code redemption, and reward metadata.
• The Redemption Code custom metadata contains only a rewardDataId / rewardId.
• The actual reward content is resolved on our server from our RewardData.
• Reward fulfillment is executed by our server reward pipeline.
• Separately, we store a per-user claim state in a BrainCloud User Entity / Custom Entity.
• That claim state records statuses such as Redeeming, Redeemed, Granting, Granted, RedeemFailed, and GrantFailed.
• If redemption succeeds but reward fulfillment fails, we keep the claim state as Redeemed or GrantFailed and allow our server to retry the fulfillment step without requiring the user to redeem the shared code again.
• If the claim state is Granted, we block duplicate reward grants.

So in our design:

• Redemption Code owns code validity and whether the user has consumed the shared code.
• Our separate claim entity owns fulfillment state, retry state, and audit/recovery information.
• Redemption Code redeemed records are not used as the production recovery source of truth.

Does this align with the pattern you recommended?

Also, as a follow-up, we are currently calling BrainCloud from our server for multiple steps: claim state update, redemption, reward grant, and final claim update. We may consolidate the BrainCloud-side claim/redemption operations into a CloudCode script to reduce API round trips, while still keeping reward fulfillment in our server pipeline.

Would that be a reasonable approach?

Thanks again.

Hi brainCloud team,

We are considering using shared / multi-use Redemption Codes for operational rewards.

The main issue is not code distribution itself, but recovery when reward fulfillment fails.

Our desired flow is:

User redeems shared Redemption Code
→ reward fulfillment is attempted
→ if reward fulfillment succeeds, user should not receive it again
→ if reward fulfillment fails, we need a way to retry or recover
We would like to know whether Redemption Code is intended to be used as the source of truth for this kind of reward claim / recovery state.

Questions:

For a shared / multi-use Redemption Code, if a specific user already redeemed the code, can that user’s redeemed state be reset or deleted through any supported API or operator flow?

If reward fulfillment fails after redemption, is there a BrainCloud-side retry or recovery mechanism that allows the same user to receive the reward later?

Can customRedemptionInfo or fulfillment status be updated and used as a persistent per-user record of reward fulfillment success / failure?

If the only reset method is marking a user as a tester and deleting the redeemed record manually in the portal, is that intended only for testing and not for production operations?

For production operational rewards, would BrainCloud recommend:

shared Redemption Code + Fulfillment Script retry,
single-use personal codes per user,
a Custom Entity / external claim ledger,
or another pattern?
Our concern is this case:

RedeemCode succeeds
→ reward fulfillment fails
→ the user cannot redeem the same shared code again
→ we need an auditable retry/recovery path
We want to understand whether Redemption Code can own this recovery state, or whether we should manage claim status separately outside of Redemption Code.

Thanks.

Hello brainCloud team,
The feature you deployed appears to be working well. Thank you sincerely for your response!

If any issues arise in the future, I will organize and report back.

Hello brainCloud team,

Thank you for the clarification. That explanation helps us understand the current behavior.

We would like to add more detail about our current situation, because the issue we are seeing is not limited to users who were already in the segment before the Automated Promotion was created.

We created a new Automated Promotion and attached it to a target segment. After that, we had a user who was not previously in that segment become eligible by updating the relevant user statistic. After calling RefreshMySegments, the user appears in the target segment under User Monitoring > Pricing.

However, the promotion still does not appear under Associated Automated Promotions for that user, and GetEligiblePromotions / RefreshPromotions do not return it.

The promotion only starts being associated and returned after we manually use Reset Segments / re-evaluate segments for that specific user from the portal.

So the issue appears to be:

• The user is newly entering the segment after the Automated Promotion has already been created and attached.
• RefreshMySegments updates the user’s current segment membership correctly.
• But the Automated Promotion is not associated with the user.
• A manual per-user Reset Segments / re-evaluation from the portal makes it work.

Could you advise if there is any supported workaround for this before the planned fix is released?

Specifically:

1. Is there any Cloud Code, client, or S2S API equivalent to the portal Reset Segments / per-user re-evaluation action?
2. Does RefreshMySegments trigger the same enteredIds logic that Automated Promotions use, or does it only update the user’s current segment membership?
3. If RefreshMySegments does not trigger Automated Promotion association, what is the recommended way to launch a new Automated Promotion and have it apply to users who become eligible after launch?
4. Is there any safe operational workaround that does not require manually resetting segments for each user?
5. Do you have an estimated timeline or release version for the planned fix?

Our current blocker is that even newly eligible users for a newly created Automated Promotion are not receiving the promotion unless we manually reset/re-evaluate segments per user, and we need a scalable way to handle this.

Thank you again for your help.

Hello brainCloud team,

We are investigating the behavior of Automated Promotions for users who already satisfy the target segment conditions.

During testing, we found the following behavior:

1. A user is already in the target segment before an Automated Promotion is created or attached to that segment.
2. In User Monitoring > Pricing, the user appears under User's Current Segments.
3. However, the segment does not show the promotion under Associated Automated Promotions.
4. Calling RefreshMySegments from Cloud Code, calling RefreshPromotions, and logging in again do not cause the promotion to become associated or returned by GetEligiblePromotions.
5. If we use Reset Segments for that user, or run Re-evaluate All Segments, the promotion is then associated and returned.

Questions:

1. Is this expected behavior for Automated Promotions?
2. Should RefreshMySegments or RefreshPromotions attach newly created Automated Promotions to users who are already in the target segment?
3. Is there a client-callable or Cloud Code API equivalent to Reset Segments or Re-evaluate All Segments for the current user?
4. Is there any API to manually trigger or re-trigger an Automated Promotion for the current user?

Our concern is that if Automated Promotions only trigger on a new segment entry, then attaching a new promotion to an existing shared segment will not work reliably for existing users unless we manually reset or re-evaluate segments.

Thank you for your guidance.