Developers
Account commands
Submit, follow, and cancel commands using a stable operation identity.
- Use UUIDs for
account_idand suppliedcommand_id. Generate one command ID per operation and reuse it for submission retries, including registrations. Omitting it creates a new identity and risks duplicate work. - Submit
command_specwith exactly one supported variant below. - Follow with
GetCommandorStreamAccountEvents; useGetRegistrationCommandfor registrations. - To cancel account work, call
CancelAccountCommandand follow the terminal result.
See Action costs for what this uses.
wait_budget limits the submission call's wait; expiry doesn't cancel the command.Command variants
| Variant | Fields |
|---|---|
refresh, claim_reward_inbox | Empty object |
open_booster | pack_id, product_id, use_powers, use_hourglasses, count |
run_battles | tasks: battle_kind, nonempty battle_id, optional rental_deck_id, use_event_hourglass |
complete_tutorials | payload_json bytes: optional tutorial_ids, tutorial_step, include_all_battle_tutorials, continue_on_error |
complete_missions | payload_json bytes: optional mission_ids, mission_group_reward_step_ids, claim_all |
For boosters, keep amount: 0, do_share: false, and action_sync unset; non-default values are rejected. An omitted or non-positive count is billed as one pack. One command opens at most 1,000 packs. use_powers selects pack stamina and accepts up to 16 entries (power_id, amount); pack, product, and power identifiers allow 128 bytes.
Battles need 1-100 tasks with battle_kind solo_stepup, solo_event, or solo_random; kind, battle ID, and rental deck ID allow 128 bytes each.
Pack power IDs come from summary_json.booster_vitality_by_id. No pack, product, or battle catalog RPC exists; GetPackDetail needs a known pack ID.
See permissions, budget, and errors.