Data API

Reference for the etl-ep endpoints — the server-to-server half of the BigLedger REST API. If you have not issued an access key yet, start with Getting Started.

Hosts

Both serve the same paths. Everything on this page is under api-etl.akaun.com.

Path grammar

/core2/{tnt|platform}/{dm|ms}/<module>/<resource>/<access-endpoint>

Access endpoints:

Almost every business resource has both a backoffice-ep and an etl-ep variant, calling the same handler with the same permission checks. Build against etl-ep: it is the variant maintained for unattended callers, and it will not move when the user interface changes.

The six operations

Most resources on this surface expose the same shape. Taking the item master as the example:

Many resources add extras — …/etl-ep/multi for batch create, …/etl-ep/query/count, …/etl-ep/query/snapshot, file attachment endpoints.

What is on the surface

Around 950 endpoint methods across 156 controllers, covering roughly 287 resources. The groups you are most likely to need:

Master data

{entityType} is one of entities, customers, suppliers, employees, merchants — so a customer read is GET /core2/tnt/dm/erp/entity/customers/etl-ep/query.

Business documents

Every document type goes through one controller, keyed by a URL slug:

There are 97 document-type slugs. The common ones:

Other modules

crm/ carries membership cards, classes, points transactions and contacts. alg/cc/ carries the contact-centre resources — agents, conversations, channels, tasks. cms/ carries website and post resources. fm/ carries files and labels. pgw/ carries payment providers and payment transactions. All follow the same six-operation shape.

If a resource you need is not listed here, it may still exist — ask for the current route rather than guessing it.

Request and response format

Headers

AccessId: <10 characters>
AccessKey: <25 characters>
tenantCode: <the tenant>
Content-Type: application/json      # on POST and PUT

Full credential detail in Authentication.

Envelopes

Single object or non-paged list:

{ "code": "OK_RESPONSE", "data": { }, "message": "" }

Paged (…/query):

{
  "totalRecords": 5217,
  "offset": 0,
  "limit": 200,
  "code": "OK_RESPONSE",
  "message": "",
  "data": [ ]
}

code is a platform response code, not an HTTP status. Match on it.

Responses are streamed, not buffered. A large page arrives progressively and the connection stays open for the duration — parse incrementally rather than waiting for a complete body.

Responses are gzip-compressed above 1 KB. Send Accept-Encoding: gzip.

Bodies

Write bodies are containers: a header object plus arrays of related rows, keyed by the underlying table names.

{
  "bl_fi_generic_doc_hdr":  { },
  "bl_fi_generic_doc_line": [ ],
  "bl_fi_generic_doc_ext":  [ ],
  "bl_fi_generic_doc_link": [ ]
}

The same container type comes back from GET, so the reliable way to learn a write body is to read a record and mirror it. Dates are ISO-8601 strings, never epoch numbers.

Query parameters

…/query endpoints share a common set, plus per-resource filters.

Most of the resources you will sync also accept, in ISO-8601:

Not every resource supports them. If a date filter does not change the result count, that resource does not implement it.

Document queries add server_doc_type, guid_comp, guid_branch, hdr_posting_status, doc_entity_hdr_guid, hdr_doc_ccy, and the correlation filters below.

Correlating with your own identifiers

Records carry three fields for your side of the mapping. They are yours to populate; BigLedger never writes them.

GET …/gen-doc/internal-sales-invoices/etl-ep/query?hdr_client_source=storefront&hdr_client_key=WEB-2026-0043117

Limits

Measured from the platform’s own configuration.

Because there are no enforced maxima, the practical limits are the timeout and your own patience. A 2 GB multipart upload and a two-hour request are both technically allowed and both bad ideas.

Error codes

Check code before HTTP status. A validation failure and a permission failure can share a status but never share a code.

Related documentation