Integrate an External System
“How do I connect another system to BigLedger?” Your own server calls BigLedger’s REST API with an access key, and BigLedger can call yours back with a webhook. This section covers that path, from your first call to an integration that runs unattended. Pick the page that matches where you are.
Which page answers your question
| Your situation | Open | Why that page |
|---|---|---|
| You are about to build and want to know what every page here assumes | The Integration Surface | The API’s shape, what happens after a write answers, what BigLedger does not give you, and the reads that prove it worked |
| You have a tenant code and nothing else | Getting Started | It goes from sign-in to a key, a read, a write and the check that proves each |
| A call is refused and you cannot tell whether the key or the permission is at fault | Authentication | Each refusal code says which check failed and whose fix it is |
| You are about to write a sales document: the body, the paging, Finalise | Data API | It covers draft then Finalise, and what Finalise sets off after it answers |
| You are loading customers, items or a year of old invoices in one go, not as a feed | Batch and Import API | CSV import files and the JSON document import queue, for a one-off load |
| Your system has to hear about a change without asking every few minutes | Webhooks | It says what a webhook does not guarantee, and that decides how you build |
| You need to follow an e-invoice after the document left for LHDN | E-Invoice API | Submission, cancellation, rejection and the documents LHDN holds |
| You are about to build a connector to a marketplace shop | EcomSync related applets | BigLedger already brings marketplace orders in as sales orders; check before you build |
| You need a route this section does not name | API Reference | Its module references are generated from the backend’s route table |
What happens behind a write
Creating a document does not post it, and Finalise is a second call that answers before the
posting job runs, so a 200 means final and numbered, not the journal exists: read
posting_journal back to know. Create as a draft: a document sent as FINAL is stored FINAL with no
journal behind it, though since mid-October 2026 it is still handed to e-invoicing. The Integration Surface
walks the whole chain, the retry guard and the two Finalise routes, and
Data API has the calls.