HR and Payroll API notes

For the REST API — the path grammar, access endpoints, authentication, paging, response envelopes and error codes — see the developer integration path. There is one API for the whole platform; there is no separate HR & Payroll API.

Integrate an external system →

Which endpoints an HR integration actually uses

Employees are entities. Employee Maintenance creates and updates them through the entity endpoints (EmployeeService POST / PUT), and the sub-records — payment methods, spending limits, company links, login links — through their own services, each with its own backend validator. An integration that loads staff therefore talks to the entity API, not to anything HR-specific, and the validation messages it can receive (…EMPLOYEE_CODE_ALREADY_EXISTS, …EMPLOYEE_CODE_SHOULD_NOT_BE_SET, ENTITY_HDR_OBJECT_TXNTYPE_DOES_NOT_EXISTS) are documented on the Employee Maintenance and Entity Maintenance pages.

Endpoint families that exist without a registered applet

The backend declares two URL prefixes for this area — hr/ and pyrll/ under the tenant domain prefix — and controllers exist under both: leave-application documents, accounts and approval settings under hr/leave-app/…; clock-in/out events and sessions under hr/time-attendance-…; and pay runs, payslips, salary structures, statutory rates and bank files under pyrll/…, with a pay-run workflow (calculate, approve, finalize, bank-file, gl-post, file, reject).

None of these is reachable through a registered applet as of the last registry export. They are listed here only so that an integrator who finds them in a permission list or a log knows what they are. Do not build against them on the strength of this page; their contracts belong to applets that are not yet released, and a contract that has never had a caller will change.

If you are integrating a payroll system with BigLedger today, the integration point is the journal, not these endpoints. The payroll system computes; BigLedger receives the monthly result as a general journal, imported or posted through the financial document API. That seam is stable, it is what existing integrations use, and it needs nothing from pyrll/. Whoever builds it agrees the account and cost-centre mapping with finance first; the check is that one month, imported end to end, ties to the payroll system’s own control totals.