Claims API notes
There is one API for the whole platform. There is no separate Claims API and no separate host for it. For the path grammar, access endpoints, authentication, paging, response envelopes and error codes, see the developer integration path.
Integrate an external system →
Claims is not a generic document, and its endpoints show it
Most of what this wiki documents is a generic document — a sales invoice, a purchase order — reached
through the shared document endpoints by its server document type. A claim is not one. It has its
own domain, its own tables (bl_aat_claim_*) and its own controllers, so none of the generic document
patterns apply to it: no server document type, no posting status, no FINAL, no VOID.
Claim endpoints live under the audit-assurance-tax path:
| Resource | Path |
|---|---|
| Claim lines | /core2/tnt/dm/erp/aat/claims/document-lines/… |
| Claim cycles | /core2/tnt/dm/erp/aat/claims/cycle-hdrs/… |
The two access endpoints mean different things here
Every screen in both applets calls one of two endpoint suffixes, and the difference is the module’s whole access model:
…/login-entity-ep— scoped to the caller’s own employee record. These are the claimant screens. A claimant can only ever see and act on their own lines.…/backoffice-ep— the supervisor, finance and settings screens.
State changes are PUT calls to named processor paths rather than field updates — for example
…/document-lines/processors/withdrawals/…, …/processors/resubmission/…, …/processors/on-hold/…,
and …/processors/retry/backoffice-ep to re-queue a line whose approval sequence failed to build.
Permissions
Claims has no client-side permission definitions at all — neither applet has a single row in the client-side permission table, and neither reads any. Access is entirely server-side, granted through the shared Permission Wizard as API permission sets.
Two independent things then decide what a user can do:
- API permissions — whether the endpoint answers at all.
- Reviewer Setting and approval settings — whether that user may act on that line. A finance reviewer with every API permission in the tenant still cannot accept a line in a company where they hold no reviewer row, and cannot close a cycle unless their row is flagged as the final level.
Two things an integration should know
A closed cycle can be marked as synced. There is an ETL endpoint that lets an external system set a closed cycle’s syncing status to syncing, finished or failed after it has read the PV details. Nothing in BigLedger sets it beyond the initial ready-to-sync on close, so it is a flag for your integration’s own bookkeeping.
One per-company setting has no screen. Whether an approved line is attached to the open cycle immediately or swept in by the periodic job is a column on the cut-off row with no control on the create or edit form. Today it can only be set through the API.