Skip to main content

​
String Numerics

All price, quantity, balance, and monetary values in the API are returned as strings, not floats or integers. 
{
  "price": "0.65",
  "quantity": "10",
  "balance": "993.50",
  "notional": "6.50"
}

​
Why Strings?

IEEE 754 floating-point arithmetic causes precision errors that are unacceptable in financial applications: 
# Float math is broken for money
>>> 0.1 + 0.2
0.30000000000000004

>>> 1000.00 - 6.50
993.4999999999999   # Wrong!

# String → Decimal is safe
>>> from decimal import Decimal
>>> Decimal("1000.00") - Decimal("6.50")
Decimal('993.50')   # Correct!
The backend uses Python’s Decimal type internally. By returning strings, we ensure zero precision loss from server to client.

​
How to Handle

from decimal import Decimal

# Parse API response
price = Decimal(order["price"])     # Decimal("0.65")
qty = Decimal(order["quantity"])    # Decimal("10")
notional = price * qty              # Decimal("6.50") — exact

# Send in requests
payload = {
    "quantity": str(qty),           # "10"
    "price": str(price),            # "0.65"
}

​
Fields That Are Strings

Every numeric field in the API uses string encoding:
CategoryFields
Pricesbuy, sell, price, best_bid, best_ask, mid_price, spread, last_trade
Orderquantity, notional, fee, limit_price, fill_price
Accountbalance, starting_balance, pnl, pnl_percent, unrealized_pnl
Positionavg_entry_price, current_price, market_value, unrealized_pnl
Order Booksize (bid/ask levels)
Candlesopen, high, low, close
Volumevolume
Request bodies also expect strings for quantity and price fields. Sending a raw float (e.g., 10.5 instead of "10.5") may work but is not recommended — the API will coerce it, but you lose client-side precision.

​
Next Steps