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|cm}/<module>[/<sub-module>]/<resource>/<access-endpoint>

Read a path off this page or the API Reference rather than composing one: the scope and layer segments are usually present but 65 of the 1,191 etl-ep routes sit directly under /core2/dm/… or /core2/ms/…, one uses the cm layer, and most paths carry a sub-module (erp/fi/fi-items, erp/gen-doc/{docType}, alg/cc/actions) rather than the bare module-plus-resource shape below.

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:

A handful of resources add extras, and they are rarer than they look: …/etl-ep/multi for batch create exists on five resources (contacts in both crm and erp, employees, financial items, and generic documents), …/etl-ep/query/count on two (entities), and …/etl-ep/query/snapshot on twelve. File attachment endpoints appear where the resource carries files. Check before you plan around one.

What is on the surface

1,044 endpoint methods across 173 controllers, covering roughly 306 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.

The document chain

The fourth key in that container, bl_fi_generic_doc_link, is the one nothing else on this page explains, and it is the one you will need. It is how a business document says which document it came from — a delivery order pointing back at the sales order it fulfils, an invoice pointing back at the delivery order.

The link is made line to line, not document to document. When BigLedger converts one document into another, it writes one link row for each goods-or-service line it carried across, and each row records the header and the line on both sides.

    flowchart LR
  subgraph SRC["Sales Order — doc 1, the source"]
    direction TB
    SH["bl_fi_generic_doc_hdr<br/>guid = A"]
    SL1["bl_fi_generic_doc_line<br/>guid = A1"]
    SL2["bl_fi_generic_doc_line<br/>guid = A2"]
    SH --- SL1
    SH --- SL2
  end
  subgraph LNK["bl_fi_generic_doc_link"]
    direction TB
    L1["guid_doc_1_hdr = A<br/>guid_doc_1_line = A1<br/>guid_doc_2_hdr = B<br/>guid_doc_2_line = B1<br/>server_doc_type_doc_1_hdr = INTERNAL_SALES_ORDER<br/>server_doc_type_doc_2_hdr = INTERNAL_OUTBOUND_DELIVERY_ORDER<br/>txn_type = KO"]
    L2["guid_doc_1_hdr = A<br/>guid_doc_1_line = A2<br/>guid_doc_2_hdr = B<br/>guid_doc_2_line = B2<br/>same two document types<br/>txn_type = KO"]
  end
  subgraph DST["Delivery Order — doc 2, the target"]
    direction TB
    DH["bl_fi_generic_doc_hdr<br/>guid = B"]
    DL1["bl_fi_generic_doc_line<br/>guid = B1"]
    DL2["bl_fi_generic_doc_line<br/>guid = B2"]
    DH --- DL1
    DH --- DL2
  end
  SL1 --> L1
  SL2 --> L2
  L1 --> DL1
  L2 --> DL2
  

Read the columns as doc 1 is where it came from, doc 2 is where it went. Every link row also denormalises the transaction date and the server document type of both ends, so you can filter a chain without joining back to the documents.

Three things follow, and all three change how you write against this.

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