Numeric Types in Futures Responses

Futures endpoints return price, quantity, avg_execution_price, realised_pnl, execution_fee, and similar fields as JSON strings (not numbers):

{
  "data": {
    "order_id": "01936474-a76f-767e-a056-ca1d41915778",
    "price": "0.28",
    "quantity": "650",
    "exec_quantity": "0",
    "avg_execution_price": "0",
    "execution_fee": "0.0041",
    "realised_pnl": "0"
  }
}

Why strings

Futures values are computed with fixed-precision decimals and serialised to strings so you receive them losslessly. This avoids the floating-point rounding issues JSON numbers can introduce, which matters more on derivatives than on spot because P&L compounds over many fills.

Recommendations

Parse these strings into a decimal type before doing any arithmetic. Do not coerce to float.

Language	Parse strategy
Python	decimal.Decimal(s)
Java	new BigDecimal(s)
JavaScript / Node	Use decimal.js or bignumber.js; native Number(s) is unsafe.
Go	decimal.NewFromString(s) (shopspring/decimal)
Rust	rust_decimal::Decimal::from_str

Common pitfalls

• Don't subtract two strings naively ("60000.5" - "60000.4" is invalid in most languages).
• Don't rely on JSON.parse (Node) — it'll silently coerce strings that look numeric, costing you precision.
• Do normalise everything to a single decimal library at parse time so downstream code doesn't need to think about it.

Comparison with Spot

Spot returns the same kinds of fields as JSON numbers. If you write a single client that handles both surfaces, parse both into your preferred decimal type so the rest of your code is uniform.