API Reference
BigLedger’s REST API is served under /core2/. Every endpoint follows one shape:
/core2/{tnt|platform}/{dm|ms|cm}/<family>/<resource>/<access-endpoint>The last segment is the access endpoint, and it names the caller the route was designed for — backoffice-ep for a signed-in back-office user, login-ep for an authenticated portal login, login-entity-ep for a customer or supplier acting on their own records, etl-ep for a server-to-server access key, and public-ep where an endpoint is deliberately unauthenticated. It is a naming convention rather than the authorisation check itself, which matters more than it sounds: see the two layers. Authentication covers the credentials; the Data API reference covers headers, paging, envelopes and limits.
How much API there is
The whole surface is derived from the backend’s controllers into a committed route table (data/routes.tsv, regenerated by kb/tools/export-route-table.py), so the numbers here are counted, not estimated. At the commit named in the front matter the backend serves 18,630 routes from 2,216 controllers. 18,617 are under /core2/; the other 13 are a home page, a diagnostics endpoint, a short-link redirect and eight routes for the embedded web-chat widget.
By access endpoint: 1,116 routes are etl-ep — the server-to-server surface an integration uses (see the integration path) — and 9,483 are backoffice-ep, the surface the platform’s own applets call with a signed-in user’s token. The remaining 8,031 serve logins, public storefront pages, platform operation, and — 5,769 of them — carry no access segment at all.
Those tallies classify a route by the segment in its path, which is a naming convention and not the authorisation check — see below before reading any of them as a limit on what your credential can reach.
Two references, and which one answers your question
There are two reference layers under this section, built by different methods, and they answer different questions. Neither is a draft of the other.
| Module references — generated | ERP Core API — hand-written | |
|---|---|---|
| What it gives you | Every route, per controller: method, path, handler, and the file and line it is declared at | Six resources in depth: request and response bodies, what each field means, what is required, the document lifecycle, and what a failure looks like |
| How it was made | Rendered from a route table exported from the backend’s 2,216 Spring controllers at a named commit | Written from the backend, then verified by calling the live API — all 117 documented paths called, create, update and delete exercised on every resource, the test records removed afterwards |
| How complete it is | Complete over one slice: routes whose path carries an etl-ep segment, plus read-only public-ep routes, for the controllers each page names | Six resources only, chosen because an integration needs them first. Deliberately not complete |
| How it goes wrong | It cannot drift — a regeneration fails if a page and the backend disagree — but it describes no behaviour at all | It is prose, so it goes stale when the product moves; it carries the commit and the date it was verified at |
Read the generated page to find out whether a route exists, what it is called, and what else the same controller serves. Read the ERP Core page when you are about to write the call and need the body, the required fields and the failure modes. Then Data API for the things common to every call — hosts, headers, paging, the response envelope, limits.
The two layers do not partition the API
A route missing from the generated pages is not a route your access key is refused. The access segment in a path is a naming convention; the backend does not use it to decide which credential is accepted, and falls back in both directions:
- an
etl-ephandler that finds no usableAccessId/AccessKeypair tries the bearer token instead (EndpointMethod.java:300-307), so anetl-eproute also serves a signed-in user; - a request that carries no
Authorizationheader at all falls through to the access-key interceptor (TenantAuthorizationInterceptor.java:64-79), so a route with noetl-epsegment can still be called with an access key.
What decides the outcome is the permission the handler checks, which each ERP Core page lists per operation.
This is why the two layers do not line up, and where the disagreement is sharpest is worth knowing:
chart of accounts, ledgers and cashbooks have no etl-ep route in the route table at all, so they
appear on no generated page — yet all three were exercised live and are documented here. Where the two
references disagree, the live-verified page is the stronger evidence. The remaining discrepancy — how an
/etl-ep path resolves on a controller that declares no such mapping — is recorded and open, and the
back-office paths those pages also list are rows in the table.
Families, and which have a reference page
The family is the first segment after /core2/{tnt|platform}/{dm|ms|cm}/. The twenty largest, with what is documented today:
| Family | Routes | Reference page today |
|---|---|---|
erp — documents, entities, items, finance, e-invoice | 8,669 | The ERP Core API (chart of accounts, ledgers, cashbooks, suppliers, purchase invoices and payment vouchers, with request and response bodies verified against production); the eight module references below (its etl-ep and read-only public-ep surface, one table per controller); the E-Invoice API (16 back-office routes with request and response bodies); the Data API reference (19 etl-ep routes for generic documents, financial items and entities) |
alg — the contact centre and bots | 1,077 | Unified Contact Center API (357 routes, 35 of 82 controllers) |
crm | 817 | — |
cms — content and storefront pages | 785 | — |
dm — tenant-level records outside a module (branches, companies, labels) | 455 | — |
wf — workflow and issues | 442 | — |
pgw — payment gateways | 293 | Integrations API (payment providers and payment transactions, 10 etl-ep routes) |
sfa — sales force automation | 283 | — |
fi — finance outside erp | 272 | — |
mrp — manufacturing | 271 | — |
applet — applet registry and links | 267 | — |
ecomsync — marketplace synchronisation | 256 | Integrations API — the connectors themselves serve backoffice-ep only and the page lists them as not exposed |
del — delivery | 244 | — |
dgmkt — digital marketing | 232 | — |
hr | 203 | — |
pyrll — payroll | 202 | — |
identity — login, access keys, subjects | 201 | Authentication (login and access-key issue) |
inv — inventory | 193 | Inventory API (2 etl-ep routes; the rest is backoffice-ep) |
iam — permissions and roles | 189 | — |
tpy — third-party services (e-signing, e-KYC, credit checks) | 183 | Integrations API — backoffice-ep only, listed as not exposed |
A further 184 families — most of them platform-side and under fifty routes each — share the remaining 3,083. The full list, with a count per family, is the # families: line in the header of data/routes.tsv.
Module references
Eight module references and the error-code index, every one generated from the route table so that a path can only appear on a page if the backend serves it. Each page lists the etl-ep (server-to-server access key) routes and the read-only public-ep routes of its controllers, one table per controller, the {docType} slugs it covers where the generic-document controller is involved, and closes with what the family serves on backoffice-ep only and how many of its routes carry no access segment at all. Neither of those closing lists is a statement about what an access key can reach — see the two layers. The pages carry no behaviour prose: what a route does is the Data API reference’s and the module hubs’ territory.
| Page | Routes | Controllers | Covers |
|---|---|---|---|
| Accounting | 194 | 27 | journals, subledgers, tax transactions and filings, credit limits and terms, companies, branches and locations, payment and receipt vouchers |
| E-Invoice | 30 | 9 | documents submitted to LHDN, submission queues, LHDN integration, e-mail reports, PEPPOL |
| Sales | 171 | 20 | entities, the generic-document controller with 42 sales document slugs, pricing, commission schemes |
| Inventory | 249 | 20 | the item master, inventory items and transactions, stock takes, labels, warehouse item labels, attributes, 11 stock document slugs |
| Purchasing | 150 | 16 | entities and the generic-document controller with 40 purchase document slugs |
| Reports | 8 | 2 | two sales reports; the 84 bi-reports routes and the financial reports are backoffice-ep only |
| Batch and Import | 130 | 30 | CSV import files for customers, suppliers, employees, price books and nine document types; the JSON import queue |
| Integrations | 36 | 4 | marketplace item listings and fulfilments, payment gateways; the connector and third-party families are backoffice-ep only |
| Error Codes | 410 codes | — | every code value the API can return, with the 11 HTTP statuses the source declares |
Together the eight pages cover 754 of the 1,349 routes on the integration surface (etl-ep plus read-only public-ep) and the Unified Contact Center pages a further 57. No page yet: the other 210 contact-centre routes (Q-0396), cms (96), crm (95), the claims sub-family under erp (49), and the storefront reads (reviews, item views, catalogue search). Anonymous write routes on public-ep are deliberately not documented anywhere.
What is verified
The nine module references were unpublished on 6 September 2026 because they described endpoints that do not exist; the pages at those URLs today are the generated ones above. A cached copy of an old page is not a reference for anything.
Related
- Getting started with integration — nothing to moving real data in seven steps
- Webhooks — what BigLedger pushes to you, and the guarantees it does not offer