Service methods are ordinary Go functions on *Client services. Learn the conventions once; they
apply across orders, triggers, balances, and market data.
Call shape
result, err := client.Orders.Create(ctx, req, accountScope)- First argument is almost always
context.Context(cancel / deadline). - Account-scoped methods take an
AccountScope(oftennilfor defaults). - Results are typed
modelsstructs; wire protos do not leak through.
There is no TypeScript stepUpToken options bag on these mutations. Creating API keys is a
JWT/session product flow, not available on this API-key SDK.
Stable mutation identifiers
| Mutation | Key |
|---|---|
Orders.Create / batch items | ClientOrderID (duplicate guard, no replay) |
Orders.Modify, CancelAll, batch helpers | requestID |
Triggers.Create | clientTriggerID (SDK generates one when nil) |
InternalTransfers.Create | idempotency key (required) |
Withdraw.CreateTo* | idempotency key and nonce (required) |
Withdrawal and internal-transfer identities are required for every call, including one-shot attempts. Do not treat them as "only for retries."
For API-key withdrawals, persist PreparedTradingWithdraw.RequestBytes() before first submission.
After an unknown outcome, restore those bytes and call SubmitPrepared; do not rebuild a new
deadline, nonce, or signature.
If you omit ClientOrderID on create, the call is accepted but you cannot safely reconcile by
client ID. The SDK does not generate one. A retained ClientOrderID cannot be reused: even an
identical create returns CONFLICT_DUPLICATE_CLIENT_ORDER_ID instead of replaying the earlier
result. Keep the original value after an ambiguous response, look up the order by that ID, and
handle a duplicate conflict as a signal to continue reconciliation.
If you omit requestID on Modify, CancelAll, CancelAllAfter, or batch
create/cancel/modify, or clientTriggerID on Triggers.Create, the SDK generates one for that
single call. Fine for one-shot mutations. To retry safely after an ambiguous failure, supply and
reuse your own value: a blind retry that omits it mints a new ID and is not an idempotent replay.
clientOrderID := "strategy-run-20260725-0001" // create and persist once
req := models.CreateOrderRequest{
// ...
ClientOrderID: &clientOrderID,
}
// After an ambiguous error, reconcile by ClientOrderID before deciding to resubmit.
// Reuse of a retained ClientOrderID returns CONFLICT_DUPLICATE_CLIENT_ORDER_ID.
requestID := "mod-strategy-run-20260725-0001" // choose once per logical modify
// Pass &requestID into Modify / CancelAll / batch helpers and reuse on retry.Client order IDs accept 1 to 36 ASCII letters, digits, ., _, :, /, and -. Request IDs
use the same character set and accept 1 to 64 characters. The SDK validates both locally and
returns *errors.ValidationError before the request is sent.
ClientOrderID while the first create is unresolved can place a
second order. Persist the original value for reconciliation. For replayable request IDs, create the
key once outside the loop and reuse it for the same logical action.Retrying safely
Retry failures that sdkerrors.IsRetryable reports with capped exponential backoff and jitter;
honor RateLimitError.RetryAfter when present. An order error code ending in _OUTCOME_UNKNOWN means the change may still apply and is not retryable: read the order or trigger back first. A timeout is ambiguous: the server may have applied the
mutation. For a single-order create, reconcile by ClientOrderID before resubmitting and expect a
duplicate conflict if the ID was retained. For mutations with replayable request IDs, keep the key
stable. Do not blindly retry *ValidationError or most *APIError responses; fix input, auth, or state.
See Error handling and Errors.
Pagination cursors
Most list APIs return opaque tokens (NextPageToken) or similar cursors. Replay them exactly as
returned, including trigger list/event pages.