This document intends to detail how to retrieve and create/update the Benefit package assignment 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 benefit record details and the Tenant's Benefit Package information. 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

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


Tenant level package data

GET {{url}}/api/tenant/benefits/packages/list/get/{{tenant_id}}?$orderby=Name



This will return a full list of benefit packages for the specified tenant Id. The endpoint accepts an odata query string.  The example above demonstrates ordering by Name.


Full response structure:


[

  {     "id": 1,     "tenantId": 2,     "name": "Default",     "shortDescription": null,     "isDefault": true,     "benefits": null,     "benefitCount": 40,     "userCount": 427,     "lastUpdated": null,     "autoRenew": true,     "recalculateValues": true,     "snapshotValues": true,     "autoWindows": true,     "autoEnroll": true,     "repeatWindows": false,     "maximumProbationDates": null,     "useAutoEnrollAssessments": null   } ,..... ]


Shown example is a results set for a single benefit package, which will be clearly marked as the default. When multiple results feature, only one can ever be configured and utilised as default. The TenantID is repeated, and a count of membership (users currently assigned) is available, as well as how many Benefits have been placed within the package. The all important ID will be required for altering or adding a System User to the package.


User package assignment

GET  {{url}}/api/user/benefit/package/get//{{tenant_id}}/

{{system_id}}


With the desired Tenant Id and System Id to hand - the above end point will return the current benefit package. An empty result will imply there is no package, and the system will be treating the User as belonging to the default Benefit Package.


Full response example, for when a User is assigned/saved against a Benefits package (including the default):


{

"benefitsPackageId": 123 "benefitsPackageName": "test" "dateCreated: "2018-12-10T17:06:01.077" "id": x "lastUpdated": "2025-12-23T14:01:54.313" "tenantId": x "torusAccountId": x "userAccountId": x,  "benefitsPackage": {.......} }


The response contains the section "benefitsPackage" with details about the assigned package, with the all important ID present in the main part of the response, alongside the name. NOTE: the tenant/user identifiers are not currently returned.


To formulate the creation or update of assigning a user to an existing package:


"requestDTO" primary properties and objects (Json camelcase)

UserId int
Mandatory
BenefitsPackage
objectMandatory
 --- Idint
Mandatory



POST    {{url}}/api/user/benefit/package/set


With the appropriate Write permission, and a JSON request DTO containing these 3 values as detailed - a user will be successfully assigned to the desired


An example for supplying a Package Id of 123 for the target user:


{
   "userId": {{system_id}},
   "benefitsPackage": { "id": 123 }
}


This will successfully assign the given User to the package, from having no value, or from their existing package. An Exception will be thrown if the access checks or not met, or the package does not relate to the tenant in which the user is created.