Request and response bodies are JSON (Content-Type: application/json), except the token endpoint, which is form-encoded. IDs are 24-character MongoDB ObjectId strings.
Collections are queried through a POST …/grid endpoint that accepts a server-side grid request — startRow and endRow for the page window, plus optional filterModel and sortModel — and returns the matching rows with a total row count. This is the same request the app’s data grids use.
POST /api/v1/projects/grid
{
"startRow": 0,
"endRow": 50,
"sortModel": [ { "colId": "name", "sort": "asc" } ],
"filterModel": {}
} Editable resources carry a version number. Every PATCH must include the version you last read; the server rejects the request with 409 Conflict if the resource has changed since (and 400 if version is missing). After a successful write, read the new version from the response and use it on your next edit.
The API uses standard HTTP status codes:
| Status | Meaning |
|---|---|
400 | Bad request — malformed body or a missing required field (such as version). |
401 | Unauthorized — missing or invalid bearer token. |
403 | Forbidden — the user lacks the privilege for this operation. |
404 | Not found. |
409 | Conflict — a stale version on a PATCH. |
429 | Too many requests — the rate limit has been exceeded. |
Any endpoint may respond with 429 Too Many Requests when a rate limit is exceeded. The response carries a Retry-After header giving the number of seconds to wait before retrying. Well-behaved clients should honour it — pause for that many seconds, then retry — rather than retrying immediately.
Rate limiting is not actively enforced today, but the 429 / Retry-After contract is stable and documented on every endpoint, so build for it now and your integration will keep working unchanged when limits are switched on.
You can see the 429 response listed against every operation in the API reference.