/api/v1 and returns JSON.
Base URL
Authentication
Every request must carry an API key as a Bearer token:- Create keys in Settings → API keys (Owner or Admin). The full key is shown once at creation — only a hash is stored, so copy it then.
- API access is a Professional+ feature (
api_access). Keys on a plan without it return403. - The key alone determines which organisation you’re reading. There is no
tenantIdparameter on any endpoint — you cannot read another organisation’s data with your key. - Revoke a key at any time from the same screen; a revoked key immediately returns
401.
Scopes
Each key is granted one or more scopes at creation. An endpoint requires the scope shown against it; a key lacking that scope returns403 insufficient_scope.
Rate limiting
Each key is limited to 120 requests per minute. Exceeding it returns429 with a
Retry-After header (seconds) and X-RateLimit-Limit / X-RateLimit-Remaining.
Errors
Errors are JSON with a stablecode:
HTTP methods
All v1 endpoints are read-only (GET) except POST /api/v1/transactions (the
transaction push). Any unsupported method on a route returns 405 Method Not Allowed with an
Allow header listing the permitted methods, before any authentication or data access occurs.
Endpoints
List projects
projects:read. Returns the organisation’s projects.
Get a project
projects:read. Returns a single project, or 404 if it isn’t in your organisation.
Project report
reports:read. Budget-vs-actual for the project. granularity is monthly
(default) or quarterly. Each cell carries budgeted, actual, and variance.
Project allocations
allocations:read. The allocations recorded against the project’s budget lines.
Transactions
transactions:read. Transactions are organisation-level (an allocation links a
transaction to a project), so this endpoint is not nested under a project.
rawData) and internal exclusion audit fields are never exposed.
Push transactions (batch)
transactions:write. Push cash transactions from an external finance system (SAP,
Oracle, PeopleSoft, or any ETL). This is the inbound counterpart to the Xero sync — for
organisations that can’t use a native pull integration. Pushed transactions participate in
the full allocation workflow (workspace, exclude, allocate, reports) exactly like synced or
CSV-imported ones, and are tagged provider: "api".
The organisation is determined solely by the API key — there is no tenant parameter.
Request body — a JSON object with a rows array (1–500 rows):
Each row is validated independently: valid rows are written even if others in the batch
are rejected. A row whose
amount changes on re-push and that already has allocations is
flagged needs_review (same as an edited Xero transaction).
status of created, updated, or rejected (with an errors array).
The response is 200 when at least one row succeeded, 422 when every row was rejected, and
400 when the envelope itself is malformed (missing rows, empty, or over 500 rows).