Developers
“How do I connect another system to BigLedger?” “Is there an API, and what can it do?” The answer to both is one REST API, and there are two different jobs you can do with it: build a screen that runs inside BigLedger, or move data between BigLedger and a system of your own. They take different credentials, different toolchains and different hand-offs from BigLedger, so pick yours first.
The choice is about who is at the keyboard. An applet runs in a signed-in user’s browser and calls the API with that user’s token; an integration runs on your server and calls it with an access key. An applet holds no access key and an integration puts nothing inside the shell, so neither path does the other’s job. If you are building a Java backend application on BigLedger’s own libraries, that is a third job: Platform Library.
Which page answers your question
| Your situation | Open | Why that page |
|---|---|---|
| You have never called the API and want one record in and one out | Integration: Getting Started | It walks sign-in, issuing a key, a read, a write and the check that proves each |
| A call is refused and you do not know whether it is the key or the permission | Authentication | Each refusal code names which check failed and whose fix it is |
| You are about to build an integration and want what every integration page assumes | The Integration Surface | What happens after a write answers, what BigLedger does not give you, and the reads that prove it worked |
| You are about to write a document and need the body, the paging or the envelope | Data API | It covers draft then Finalise, and what Finalise sets off after it answers |
| You want to know whether a route exists, and what it is called | API Reference | Its module references are generated from the backend’s route table |
| You need request and response bodies for ledgers, cashbooks, suppliers or purchase invoices | ERP Core API | Six resources, documented field by field and verified by calling them |
| Your system has to hear about a change without asking every few minutes | Webhooks | It also says what a webhook does not guarantee, which decides how you build |
| You need something to happen on a schedule or after an approval | Automation | Scheduler, job processors and the approval engine, and the workflow engine BigLedger does not have |
| You are integrating with one module and want to know what its screens enforce for you | Integration notes by module | The rules an integration must keep itself, module by module |
You have an error code and want to know what sends it | Error Codes | Every code the backend declares, with the HTTP status where one is declared |
Build an applet
Almost every screen a BigLedger user sees is an applet, built and released on its own and mounted by the BigLedger shell at runtime.
What you need: Node.js, the Angular CLI (Angular 11–15), and two public npm packages —
blg-akaun-ts-lib for the API and, optionally, blg-akaun-ng-lib for UI components. The second
declares Angular 11 peers only, so on a later Angular read it rather than install it.
What you need from us: a registration record for your applet, and a tenant to install it into. Neither is self-service, and there is no local shell, so the first time you see your applet inside BigLedger is after that hand-off. Applet Development says what to ask for.
Integrate an external system
Your own system — a storefront, a warehouse tool, a marketplace connector, a data warehouse — exchanging data with BigLedger over HTTPS. One REST API, JSON in and JSON out, and a credential you issue yourself.
What you need from us: a tenant code, and a user in that tenant with the right permissions. The access key itself is one API call you make yourself.
Before you build, read The Integration Surface once: creating a document does not post it, a key acts as exactly one user, and a check a screen makes is yours to make when your system writes instead. It also has the symptom table, the reads that prove it worked, and what BigLedger does not give you.
Look something up
Getting help
- Developer questions: open an issue at BigLedger-Support/public, naming the applet or endpoint and what you expected. The queue is public, so keep your tenant code and your own data out of the post; anything specific to your tenant goes to your BigLedger contact (see Support).
- Public repositories: github.com/bigledger
- The product itself: akaun.com