MyWorkPal

This document intends to detail how to retrieve and update the Salary (Remuneration) records for a user within "MyWorkPal". It is already assumed the User is known and their MyWorkPal System ID stored/ready to use with all end points.

Pre-requisites:

API Client access

See How to create API Clients to see how to obtain API Client IDs and secrets

Permissions

The API Client requires all the base permissions to read tenants, users, and then permissions for read/write of the main Employee and Remuneration record details. Only tenants that the API client has access to will be returned.

Environment "variables"

Within all examples:

{{url}} would be a full HTTPS URI such as https://webapi.myworkpal.co.uk

{{tenant_id}} is the unique tenant ID for the target user account

{{sub_domain_name}} is the unique tenant subdomain (lowercase text) for the target user account

{{system_id}} the unique SystemID for the target user 

GET    /api/employee/remunerationdetail/get/{{system_id}}

With the desired User System ID (and subdomain) to hand - the following allows for retrieving, and then adding or updating property data against the user account within MyWorkPal. Originally, a single salary value and date was held on the main employee detail record. Therefore the organic growth to support multiple records and types has led to this extending the standard Employee GET end point.

Our API implementation allows delivery and then modification to all properties. It is obligatory to start with the GET to ensure all existing data/values are present. One may then modify existing, or supply new values, and submit back the original JSON structure to ensure a successful POST via the Set.

Full response structure, example user currently has no records:

{

   "userAccountId":10239,

   "torusAccountId":0,

   "lineManagerName":null,

   "tenantId":null,

   "selectedEmployeeGroupIds":null,

   "employeeGroupsAll":null,

   "id":1234,

   "displayName":null,

   "avatarImageFile":null,

   "groups":null,

   "startDate":null,

   "leaveDate":null,

   "hasLeft":null,

   "inLongTermAbsence":null,

   "costCentreId":null,

   "costCentreName":null,

   "costCentre":null,

   "costCentresAll":null,

   "payrollNumber":null,

   "payrollFrequency":null,

   "workTelephoneNumber":null,

   "alternativeWorkTelephoneNumber":null,

   "salary":null,

   "salaryDate":null,

   "futureSalary":null,

   "futureSalaryDate":null,

   "benefitAllowance":null,

   "benefitAllowanceDate":null,

   "futureBenefitAllowance":null,

   "futureBenefitAllowanceDate":null,

   "qualifyingEarnings":null,

   "qualifyingEarningsDate":null,

   "payDate":null,

   "dateCreated":null,

   "lastUpdated":null,

   "lineManagerRole":false,

   "holidayApproverRole":false,

   "jobDetails":null,

   "hrRoles":null,

   "remunerationOther":[],

   "remunerationSalary":[],

   "managerTorusAccountId":null,

   "typeOfManagerRoleName":null,

   "maximumProbationDates":null,

   "probationDates":null,

   "representTeamMembers":false

}

As can be clearly seen, this piggy-back of the Employee detail ensures the response has properties irrelevant to the scope here and can be ignored/discarded. The rest of this guide will operate on that basis. Here is the JSON result again this time condensed purely to those.

{
   "userAccountId":{{system_id}},
   "id":1234,
   "remunerationOther":[],
   "remunerationSalary":[],
}

In the above, basic/first Salary information would be found within RemunerationSalary. The end points support also RemunerationOther. A second list of salary information that can be stored for a user.

{
   "userAccountId": {{system_id}},
   "id":1234,
   "remunerationOther":[],
   "remunerationSalary":[
      {
         "basis":"Month",
         "frequency":"Monthly",
         "changeReason":"Upload",
         "salaryRemunerationType":0,
         "tabId":null,
         "id":12345,
         "userAccountId":0,
         "torusAccountId":0,
         "amount":123123,
         "startDate":"2025-09-01T00:00:00",
         "comments":"test"
      }
   ]
}

Next, an example with a reduced response but detailing the individual properties of the Salary record. SalaryRemunerationType of zero relates to the standard Salary record type. As usual, a few values are present and not used. A summary of the ones that make up the basic Salary record are as follows.

"requestDTO" primary properties and objects (Json camelcase)

For detail on how to request picklist values, please refer to:

https://support.myworkpal.co.uk/a/solutions/articles/101000558994

POST    /api/employee/remunerationdetail/post

With the appropriate Write permission, and a payload of JSON data born from the previously detailed GET, simply POST the data and await a response. If validation is successful and the request can be fulfilled, a simple empty 200 success status is sent back. If the request is invalid, a 400 bad request is returned.

{
   "userAccountId": {{system_id}},
   "id":1234,
   "remunerationOther":[],
   "remunerationSalary":[
      {
         "basis":"Month",
         "frequency":"Monthly",
         "changeReason":"Upload",
         "salaryRemunerationType":0,
         "tabId":null,
         "id":12345,
         "userAccountId":0,
         "torusAccountId":0,
         "amount":234234,
         "startDate":"2025-09-02T00:00:00",
         "comments":"test update"
      }
   ]
}

Note in this example, the original record ID 12345 is kept - ensuring an update operation of this existing default record. In this worked example case, it was supplied with pre-existing values. Here, the amount and date have been adjusted to £234234, start date 02/09/2025, and Comment: test update.

If one wishes to explore multiple record management, the API supports this via the following rules:

If each RemunerationSalary has a defined ID - this is expected to be existing data and will be an update operation when found (and validated as belonging to the user)

If a RemunerationSalary array item is supplied with ID = 0, this is instruction to attempt a fresh add of the data as new address. Ensure SalaryRemunerationType is set to zero and all mandatory values are set.

If a RemunerationSalary  is sent down within a GET that is then removed/erased from a subsequent SET post, this is taken as instruction for deletion. Ensure if modification to a record is not needed, then it is not discarded between retrieval and submission.