Further reading
Amounts and currencies
Every monetary amount is a decimal string with two decimals, such as "1234., never a floating-point number, with one exception: the prices in the priceConfig and defaultExpenses of a service and the customPrice of an accessory are JSON numbers. Each document carries its own currency, which can differ from the account's.
Amounts are serialized as decimal strings with exactly two decimals, rounded half up (ROUND_HALF_UP). The string avoids the precision loss that floating-point numbers cause. For example, an invoice returns subTotal as "1234.. The documented format allows a leading minus for negative values.
- Parse amounts with a decimal type:
Decimalin Python, a decimal library or integer cents in JavaScript. Do not useparseFloatorfloat. - Do not round or sum with floating-point arithmetic. Add in a decimal type and round half up at the end.
- Compare strings only after normalizing them to the same number of decimals.
| Direction | Format |
|---|---|
| Response | Always "1234.: two decimals. |
| Request | Send the amount as a decimal string too, with at most two decimals (except the service and accessory prices above, which are JSON numbers). For example, POST /api accepts "250. or "250", greater than zero. The exception is PUT /api, whose quantities, unit prices, tax rates and totals accept up to six decimals and a leading minus; responses still give two. |
Currencies
Link to this section: CurrenciesA currency is an ISO 4217 code such as EUR. The account has a default currency, which you can read in the currency field of GET /api, but the spec states that "documents may carry their own". An invoice therefore returns its own currency, and you should use that field, not the account's, when you total documents.
Send the currency when you record a payment
POST /api accepts a currency and defaults to EUR when you omit it. Send the currency of the document the payment belongs to explicitly instead of relying on the default.
Never add amounts of different currencies. There is no conversion in the API. For the rest of the formats, see data types.
Related pages
Link to this section: Related pagesGuides
Data types
Money is a decimal string, dates are ISO 8601, a property can be present and null, and custom fields are maps. Parse each type once, at the edge of your integration.
Further reading
Dates and times
Responses give dates in UTC. When you write, send an ISO 8601 instant with an offset. A bare day such as
2026-10-17is read in the business time zone of the account when it is in a filter; a write takes one only in a field that is a plain date.
Was this page helpful?