Capabilities and limits of v1

Filmo is rental software, and the API exposes the same records the team sees in the app, with a few deliberate omissions. This page has four parts: what each resource supports, what is not available, the limits a request must respect, and the gaps that are known today.

The endpoint reference lists every operation of a resource: whether you can list, read, create, update and delete it, and which actions it has (reserve, cancel, validate, void…). Every operation is also an MCP tool with the same scope and the same limits; see the MCP overview. The matrix below summarises them for every resource: the operations for list, read, create, update and delete, the number of other actions, and the number of MCP tools. It is generated from the OpenAPI document, so it is always the current contract.

These are things you might expect from the API that it does not do. Each row names where the spec says so and what to do instead.

Some of these have a longer treatment elsewhere: syncing data for deletes and archived records, and data left out by design for costs, margins and personal data.

The same list is also generated from the spec, so a gap that a new release closes disappears from it:

The schema of each request sets maximum sizes. A request over a limit is rejected with validation_error, and errors[] names the offending field. The table below is generated from the spec, so it is always current.

• Lists that paginate return at most 500 records per page (limit, default 50). cursor and sort accept at most 200 characters. A few small lists have no pagination and return everything in one response: check the operation for a cursor parameter.
• A question to POST /api/v1/ai/ask is at most 4000 characters, and the only mode today is a single pass: there is no conversation to continue.
• A contact update accepts at most 20 addresses, 20 emails, 20 phone numbers and 20 websites.
• Creating an order accepts at most 100 lines, and an availability check at most 100 items. Checking the availability of staff or vehicles accepts at most 100 identifiers.
• A contact lookup accepts at most 200 references.
• A line-item return and an external invoice each accept at most 500 lines.
• List filters that accept several values, such as statuses, take up to 50 of them; assignedToStaffIds takes up to 200.

Rate limits are a separate matter: 120 requests per minute per key, and 30 per minute shared by the three availability queries. See rate limits.

Filmo runs the API on a hosting platform, and the platform bounds how large a request or a response can be and how long one call may last. Filmo does not publish the size limits as part of the contract, and apart from one operation it documents no duration limit either, so do not design around a specific size or duration.

• Keep requests small. Send large changes as several writes, each with its own Idempotency-Key.
• Keep pages at a size you have measured. A page of 500 records of a large object is a big response; if you see failures, lower limit.
• Over REST, POST /api/v1/ai/ask is allowed to run for up to 300 seconds and can take tens of seconds on questions that chain several queries. Allow a long client timeout, above 300 seconds, and do not retry before it expires. Through MCP, do not assume the same allowance. For every other operation there is no documented duration limit: set your own timeouts and handle a 504.
• The platform itself generates the 413, 502 and 504 responses; they are never application/problem+json and have no code. Branch on the HTTP status, not on the body. A 502 or a 504 on a write does not tell you whether the write happened: retry it with the same Idempotency-Key.

This table lists the documented limitations and the information or functionality needed to resolve each one. Entries are removed as they are resolved.