Time and number handling

• Every timestamp we return is UTC, as an RFC3339 string with a trailing Z and whole seconds — "2026-09-16T01:00:00Z". Today that means /exchanges' market.data_time, /global's data_time, and market.snapshot_time on /categories and /chains. Every timestamp we add follows the same format. Do not infer a local zone from anything.
• Money, prices and volumes arrive as JSON strings, not numbers, because they carry more precision than a double can hold. Parse them with a decimal type, not a float.
• The number of decimal places is not part of the contract. "1.5", "1.50" and "1.500000000000000000" are the same price, and which one you get may change without notice — it follows the column and the driver, neither of which we promise. So never compare these values as strings, and never use one as a cache key or a hash input. Parse first, compare numerically. The examples below show what the serializer actually emits — trailing zeros are trimmed, so a stored 9.000000000000 arrives as "9" and a decimal(36,18) price as "66079.916784987"; read them as illustrations of shape, not of width.
• id is a JSON number, unlike money. It is a small integer and it will stay one, so a language that loses precision above 2^53 is in no danger here. Send it back to ?id= as-is.