Changelog

This page records notable changes to the PeopleForce APIs — new endpoints, fields, and behavioural changes — newest first.

Unreleased

• Breaking, for companies on compensation components. New companies start on compensation components. PUT /api/v4/people/:person_id/compensation/salaries/:id now returns 422 with an error naming the field when the request sends per, overtime, or pay_schedule_id. It accepts the per the salary already has, so a salary read from the API can be sent back unchanged. A field sent as null counts as not sent. A salary takes its pay period from its compensation component, so per in responses always matches the component's frequency. The endpoint accepts compensation_component_id, but a salary's component cannot change once it is saved: a different ID returns 422. Salary responses include compensation_component. Companies still on compensation types see no change.
• GET /api/v4/people/:id now returns the Ukrainian compliance fields that hire compliance processes create, such as ua_tax_id and ua_disability_group. Like any custom field, one is returned only when a role attached to the key grants view access to it. These fields are read-only in v4: POST /api/v4/people and PUT /api/v4/people/:id ignore them.
• Empty array filters (such as statuses[]=) on GET /api/v4/compliance/compliance_cases and GET /api/v4/compliance/compliance_case_documents are now ignored instead of returning 400. Unknown values still return 400.
• Added GET /api/v4/leave_requests and GET /api/v4/leave_balances. Both list across every person the service account can see, rather than one person at a time, and both need the new Time off permission on a role attached to the key — without it they return 403. A role that grants Time off but affects nobody gets an empty list, not a 403.
• Initial v4 documentation: Company API v4 and Careers API v1.