Skip to main content
Four read endpoints. All of them are scoped to your client_id and all of them serve stored snapshots — nothing is recalculated on read.

Retrieve one calculation

The body is the same document you received when you created it, including record, warnings and period_basis.

Including the audit trail

The trail is stored whether or not you asked for it at calculation time. Ask for it on read with ?include=audit_trail:
Unknown ids, and ids belonging to another client, both return 404 CALCULATION_NOT_FOUND. The two cases are indistinguishable on purpose.

List calculations

Cursor pagination

Pass the id of the last item you saw as starting_after. Because ids are ULIDs, sorting by id sorts by time — the cursor is stable even while new calculations are being written.

Superseded calculations

A calculation that has been replaced by a later one is flagged is_superseded in the listing. It is never removed and never modified. See Corrections.

Retrieve a batch

Returns the batch totals, every successful row, and the failed rows with the error that failed them — which is what you need to fix a partial run without re-sending the rows that worked.

Employers and employees

Both register themselves the first time you send their id. There is no create endpoint.
Both list endpoints take limit and starting_after and paginate the same way.
employee.id is unique within its employer, so emp_001 must always be addressed through its employer_id. An unknown employer returns 404 EMPLOYER_NOT_FOUND; an unknown employee under a known employer returns 404 EMPLOYEE_NOT_FOUND.