Skip to content
Developers
Platform Library

Platform Library

The BigLedger platform is published as three versioned Java libraries. Your application declares them as dependencies, serves every BigLedger endpoint plus your own from one process, and adds logic beside it without holding a copy of BigLedger source code. This page is for the developer deciding whether to build on it: who can fetch the libraries, what your process takes on once it loads them, and what goes wrong first.

This is not the REST API. If your code runs outside BigLedger and only needs to move data in and out, use the API Reference with an access key instead. That path needs nothing from this page. The platform library is for teams building a backend application that runs as a BigLedger deployment, with extra behaviour of its own.

Published, but not public

Yes, the libraries are published. A build workflow in bigledger/blg-akaun-platform-java publishes all three to GitHub Packages whenever a version tag is pushed. Three versions exist: 1.0.0 (6 August 2026), 1.1.0 (8 October 2026) and 1.2.0 (14 October 2026). Each publish run finished successfully.

They are not public. The repository they are published from is private. Before Gradle can download anything, BigLedger has to give your GitHub account or team read access. BigLedger has not published who qualifies for access or how long it takes. Ask your BigLedger contact before you plan a project around the libraries, not after. Once you have access, Getting Started covers the token and the build file.

The version these pages describe. They are read from one backend commit two days later than 1.2.0, so it matches no release exactly, and no release notes are published beside the tags. Versioning & Upgrades says what each release changed and how to move between them.

What you get

Getting Started
Get access, add the dependency, and run your first build
Building Your Application
Add endpoints and services, and boot the platform
Versioning & Upgrades
How releases are numbered and how to move between them
Troubleshooting
Common errors and current limitations

The libraries

Three artifacts are published under the com.bigledger group. They are released together and always share a version number.

ArtifactContains
akaun-apiThe application layer: REST controllers, endpoint handling, request authentication, background queues
javasdkThe platform core: domain services, units of work, the data access layer, tenancy, permissions
client-sdkShared value types: table classes, containers, query criteria, DTOs

akaun-api depends on javasdk, which depends on client-sdk. Declare javasdk as well as akaun-api: akaun-api carries it at runtime scope only, so without it a BigLedger import will not compile, while client-sdk arrives through javasdk without a declaration of its own (Getting Started has the build file).

What your process takes on

Your application serves every BigLedger endpoint, plus your own, from one process, and loading the platform also starts scheduled work in that process; starting it migrates no database. Building Your Application walks one request from arrival to your handler, the permission check your handler must make itself, and a worked GadgetSphere branch dashboard. When something fails, the symptom table names the fix, and Getting Started lists the requirements.

What you can build today

  • New REST endpoints alongside the standard BigLedger API
  • New services, scheduled work, and integrations that reuse BigLedger’s domain layer
  • New tables and data belonging to your application
  • Composition of existing BigLedger services: call the same services the standard endpoints call, and wrap them in logic of your own
Changing the behaviour of existing BigLedger endpoints is not supported. The platform publishes no hooks, filters or replaceable strategies for altering built-in behaviour, and nothing in this documentation promises that it will. If your requirement depends on this, talk to your BigLedger contact before designing around it. See Building Your Application.

Related documentation

Before you can build, BigLedger must grant package access; Getting Started takes you from that grant to a first compile. Building Your Application has the full controller example, what happens between a request and your handler, and a worked branch dashboard. Versioning & Upgrades covers moving between releases, and Troubleshooting opens with a symptom, cause and fix table.

  • Use this instead when your code runs outside BigLedger. Integrate an External System moves data over HTTP with an access key, and needs no access to the libraries or a master database.
  • Use this when the work is a screen. Applet Development builds a screen inside the BigLedger shell. An applet can call an endpoint you add here, alongside the standard ones.
  • Paired with your endpoint in practice. Authentication covers the tokens and access keys your handler receives. Error Codes explains every code your clients will see. The ERP Core API and Sales API list the standard routes whose services and permission lists you will reuse.
  • What your process takes part in. Automation and Webhooks describe the background work and notifications your process now helps run. The Scheduler applet holds the clocks the scheduled-work thread fires.
  • Where your permission check gets its answer. The roles and permission sets that isUserPermitted reads are kept in the Tenant Admin Applet. Your endpoint is only as narrow as the roles the tenant assigns there.
Last updated on