Skip to navigation
Agent Java SDK

Production & Simulated Trading

Production & Simulated Trading: Agent Java SDK v0.3.0 integration, examples, parameters and response semantics.

View as Markdown

This guide targets Agent Java SDK v0.3.0 and Java 8+.

Choose both the frontend mode and the funds environment

Configure the partner backend’s funds environment separately from the frontend trading mode. Binding and entry credentials are shared; issuing a ticket or token does not select a wallet or move funds.

ConfigurationProductionSimulated
Binding and authenticationShared user binding and one-time credentialsSame identity and authentication
New transfers and user balancesOmit environment or use PRODUCTIONExplicitly use SIMULATED
Funding original-order recoveryUse the saved original environmentUse the saved original environment
Widget trading modetradingMode=realtradingMode=demo
Frontend HTTP/WS targetProduction target supplied by 6MMSimulated target supplied by 6MM
Six perpetual-data queriesProduction dataNo environment selector; these methods do not query simulated data

For wallet-transfer-status, omitting environment uses the original order’s saved environment, including a simulated order. An explicitly conflicting environment is rejected. Prefer storing the environment and passing it explicitly when recovering an operation.

isSimulatedUser describes the account. It does not route new requests to a simulated wallet. Omitting environment on a new funds request still selects production, even when the account flag is true.

Supported Java request models

These requests support withEnvironment(ExecutionEnvironment.SIMULATED):

  • TransferRequest, TransferAllOutRequest, ReverseOrderRequest.
  • QueryOrderRequest, ListOrdersRequest.
  • QueryUserAssetsRequest.
  • WalletTransferRequest, WalletTransferQueryRequest.

bind, queryAccount, createEntryUrl, createEmbedToken, and the six perpetual query request models do not select a funds environment.

import com.sixmm.agent.model.ExecutionEnvironment;
import com.sixmm.agent.model.QueryUserAssetsRequest;
import com.sixmm.agent.model.QueryUserAssetsResponse;
QueryUserAssetsResponse assets = client.queryUserAssets(
        QueryUserAssetsRequest.of("1188041528")
                .withFunding()
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Initialize client using Quick Start and use the public user ID from your saved binding.

Preserve the original environment

Persist the interface type, agentOrderNo, user identity and environment before sending a funds request. Keep that environment during status queries, recovery, reconciliation and webhook processing. After a timeout, never retry by omitting the original environment or using a new order number.

Funding/Contract transfers stay within one environment. Simulated funds cannot become production funds. Use separate partner-side simulated accounting and recognizable order prefixes such as SIM-.

Simulated integration sequence

  1. Bind the user and save the public platform user ID.
  2. Query balances with explicit SIMULATED and include Funding when needed.
  3. Create a small simulated Funding transfer and persist its original business order.
  4. Confirm the final result with the dedicated Funding status query.
  5. Open or embed the target seconds page in demo mode.
  6. Query the same simulated wallets and reconcile the actual transferred amount.
  7. To test perpetual trading, transfer simulated Funding to simulated Contract and use the simulated futures frontend. The six partner perpetual queries cannot validate simulated trading history.

Acceptance checklist

ScenarioEvidence to verify
IdentityBound user mapping is saved; another partner’s users cannot be queried.
AuthenticationRedirect and embed flows use fresh credentials; signing does not create funds orders.
FundsBoth sides agree on the actual amount and final status.
Unknown resultRecovery uses the original order without creating a second transfer.
Environment isolationSimulated backend and frontend targets agree; production balances are unaffected.
QueriesRequired user/category filters, millisecond windows, empty pages and cursors are handled.
Rate limitsAll query callers share throttling and retry the original failed page.
StorageAmounts and IDs remain strings; entity records are saved idempotently.

Before switching to production, change both the backend funds target and frontend mode. Pending orders continue to recover in their original environment.