Skip to main content
The Ledgitify REST API gives programmatic, read-only access to a single organisation’s data. It is versioned under /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 return 403.
  • The key alone determines which organisation you’re reading. There is no tenantId parameter 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 returns 403 insufficient_scope.

Rate limiting

Each key is limited to 120 requests per minute. Exceeding it returns 429 with a Retry-After header (seconds) and X-RateLimit-Limit / X-RateLimit-Remaining.

Errors

Errors are JSON with a stable code:

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

Scope: projects:read. Returns the organisation’s projects.

Get a project

Scope: projects:read. Returns a single project, or 404 if it isn’t in your organisation.

Project report

Scope: reports:read. Budget-vs-actual for the project. granularity is monthly (default) or quarterly. Each cell carries budgeted, actual, and variance.

Project allocations

Scope: allocations:read. The allocations recorded against the project’s budget lines.

Transactions

Scope: transactions:read. Transactions are organisation-level (an allocation links a transaction to a project), so this endpoint is not nested under a project.
The full provider payload (rawData) and internal exclusion audit fields are never exposed.

Push transactions (batch)

Scope: 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).
Each result carries 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).