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-17 is 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.
Rental work is organized in days, and a day depends on where the business is. The API therefore separates three things: the instant (exact, UTC), the offset you send with it, and the business time zone of the account, which decides what a bare day means.
In responses
Link to this section: In responsesDates are ISO 8601 strings in UTC (date-time), for example 2026-10-17T08:00:00Z. Convert them to local time in your own code.
When you write
Link to this section: When you writeSend every date and time as an ISO 8601 instant with an offset, for example 2026-10-17T10:00:00+02:00. An instant with an offset names the same moment whatever the zone; responses give it back in UTC. The REST contract and the MCP tools require the offset on every date and time you write.
The one exception is a field that is a plain date, with no time: invoiceDate and dueDate of PUT /api take a bare day such as 2026-10-17, with no time and no offset. Anywhere else, if a write with a bare day returns validation_error, add a time and an offset.
The business time zone
Link to this section: The business time zoneThe account has an IANA time zone, which is the one bare days in filters are read in. Read it once from GET /api, in the timezone field, together with the currency and the language. Do not assume it from the country or from the server you run on.
Date filters on lists
Link to this section: Date filters on listsLists that support them take two families of filters, one for the creation time and one for the last update: createdOn, createdAfter, createdBefore, createdFrom, createdTo, and the same names with updated. Each accepts a bare day, read in the business time zone, or an ISO 8601 instant with an offset.
| Filter | Meaning |
|---|---|
…On | Falls on this date. |
…After | Is after this date. |
…Before | Is before this date. |
…From | Is on or after this date. |
…To | Is on or before this date. |
With a bare day, …After leaves out that whole day and …Before stops at its start, while …From starts at the beginning of the day and …To includes all of it.
For an incremental sync, updatedFrom and updatedBefore form a half-open window. The guide on syncing data shows how to use them without missing records.
Dates in MCP tools
Link to this section: Dates in MCP toolsMCP list tools take a single dateFilters object instead of separate parameters: dateFilters: { field: { gte, lte, gt, lt, on } }. A bare day in gte or on is the start of that business day, and in lte the end of that day; gt means after the end of that day and lt before its start. An instant with an offset is applied as given, except with on, which covers the whole business day that contains it.
If a day-based query returns records you did not expect, check the time zone first: the same bare day covers different instants in different time zones.
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.
Guides
Syncing data
Filmo v1 does not send webhooks, so you keep another system in step by polling: read what changed in half-open time windows, and run a separate sweep to find what was deleted. Do not follow the pagination cursor to decide what changed or what disappeared.
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 the50" priceConfiganddefaultExpensesof a service and thecustomPriceof an accessory are JSON numbers. Each document carries its own currency, which can differ from the account's.
Was this page helpful?