WORKFORCEOS

FRONTEND GUIDE FOR AI CODING AGENTS - PART 11 - LeaveManagement Service

This document is a part of a REST API guide for the workforceos project. It is designed for AI agents that will generate frontend code to consume the project’s backend.

This document provides extensive instruction for the usage of leaveManagement

Service Access

LeaveManagement service management is handled through service specific base urls.

LeaveManagement service may be deployed to the preview server, staging server, or production server. Therefore,it has 3 access URLs. The frontend application must support all deployment environments during development, and the user should be able to select the target API server on the login page (already handled in first part.).

For the leaveManagement service, the base URLs are:

Preview: https://workforceos.prw.mindbricks.com/leavemanagement-api
Staging: https://workforceos-stage.mindbricks.co/leavemanagement-api
Production: https://workforceos.mindbricks.co/leavemanagement-api

Tenant URL Prefix and Header Forwarding

Tenant context is resolved by frontend routing strategy:

preview/test: URL prefix /{tenantCodename} (example: /babil/products)
production: tenant subdomain (example: babil.appname...)

Then backend API calls must always claim target tenant with header:

headers["mbx-company-codename"] = tenantCodenameFromUrl;

URL prefix/subdomain is frontend-only tenant selection. Use header forwarding for all tenant-scoped calls to leaveManagement service.

Scope

LeaveManagement Service Description

Handles employee leave/absence requests, review/approval workflows, and automatic integration with shift assignments, ensuring company data isolation and leave history access for employees and managers/admins.

LeaveManagement service provides apis and business logic for following data objects in workforceos application. Each data object may be either a central domain of the application data structure or a related helper data object for a central concept. Note that data object concept is equal to table concept in the database, in the service database each data object is represented as a db table scheme and the object instances as table rows.

leaveRequest Data Object: Tracks employee leave/absence requests including period, type, status, reason, and approval state. Linked to a user and (optionally) department, with audit fields for request and approval. Company-tenant scoped.

LeaveManagement Service Frontend Description By The Backend Architect

UX Hints - leaveManagement Service

Employees can submit leave requests with start/end dates, reason, and type; can view their own leave history and status.
Managers/admins see pending leave requests for review, and can approve/reject/cancel with audit trace (approver, decision, date, reason).
Approval of leave may unassign user from overlapping shifts automatically (notified on shift update).
Leave requests cannot be edited by employee after review begins (status != pending).
Employees get notifications upon decision; managers/admins see team/company-wide leave history.

API Structure

Object Structure of a Successful Response

When the service processes requests successfully, it wraps the requested resource(s) within a JSON envelope. This envelope includes the data and essential metadata such as configuration details and pagination information, providing context to the client.

HTTP Status Codes:

200 OK: Returned for successful GET, LIST, UPDATE, or DELETE operations, indicating that the request was processed successfully.
201 Created: Returned for CREATE operations, indicating that the resource was created successfully.

Success Response Format:

For successful operations, the response includes a "status": "OK" property, signaling that the request executed successfully. The structure of a successful response is outlined below:

{
  "status":"OK",
  "statusCode": 200,   
  "elapsedMs":126,
  "ssoTime":120,
  "source": "db",
  "cacheKey": "hexCode",
  "userId": "ID",
  "sessionId": "ID",
  "requestId": "ID",
  "dataName":"products",
  "method":"GET",
  "action":"list",
  "appVersion":"Version",
  "rowCount":3,
  "products":[{},{},{}],
  "paging": {
    "pageNumber":1, 
    "pageRowCount":25, 
    "totalRowCount":3,
    "pageCount":1
  },
  "filters": [],
  "uiPermissions": []
}

products: In this example, this key contains the actual response content, which may be a single object or an array of objects depending on the operation.

Additional Data

Each API may include additional data besides the main data object, depending on the business logic of the API. These will be provided in each API’s response signature.

Error Response

If a request encounters an issue—whether due to a logical fault or a technical problem—the service responds with a standardized JSON error structure. The HTTP status code indicates the nature of the error, using commonly recognized codes for clarity:

400 Bad Request: The request was improperly formatted or contained invalid parameters.
401 Unauthorized: The request lacked a valid authentication token; login is required.
403 Forbidden: The current token does not grant access to the requested resource.
404 Not Found: The requested resource was not found on the server.
500 Internal Server Error: The server encountered an unexpected condition.

Each error response is structured to provide meaningful insight into the problem, assisting in efficient diagnosis and resolution.

{
  "result": "ERR",
  "status": 400,
  "message": "errMsg_organizationIdisNotAValidID",
  "errCode": 400,
  "date": "2024-03-19T12:13:54.124Z",
  "detail": "String"
}

LeaveRequest Data Object

Tracks employee leave/absence requests including period, type, status, reason, and approval state. Linked to a user and (optionally) department, with audit fields for request and approval. Company-tenant scoped.

LeaveRequest Data Object Frontend Description By The Backend Architect

Employees submit leave requests for specific periods and types (vacation/sick/etc.).
Request status/pending until reviewed by an authorized manager/admin.
Approval auto-triggers removal from conflicting shifts and triggers notifications.
History and current status visible to both employee and department/company managers/admins.

LeaveRequest Data Object Properties

LeaveRequest data object has got following properties that are represented as table fields in the database scheme. These properties don’t stand just for data storage, but each may have different settings to manage the business logic.

Property	Type	IsArray	Required	Secret	Description
`userId`	ID	false	Yes	No	ID of employee/user requesting leave (auth:user.id)
`departmentId`	ID	false	No	No	Department (userGroup) id, for scoping leave if relevant
`requestDate`	Date	false	Yes	No	Datetime when leave requested
`leaveType`	String	false	Yes	No	Type of leave (e.g. vacation, sick, emergency).
`startDate`	Date	false	Yes	No	First day of leave (inclusive).
`endDate`	Date	false	Yes	No	Last day of leave (inclusive).
`reason`	String	false	No	No	Employee-provided reason/message for leave request
`status`	Enum	false	Yes	No	Leave request status (pending, approved, rejected, cancelled).
`approverId`	ID	false	No	No	UserId of manager/admin who approved/rejected/cancelled the request
`approvedDate`	Date	false	No	No	Date/time leave was approved/rejected/cancelled, if applicable.
`companyId`	ID	false	Yes	No	An ID value to represent the tenant id of the company

Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set.

Enum Properties

Enum properties are defined with a set of allowed values, ensuring that only valid options can be assigned to them. The enum options value will be stored as strings in the database, but when a data object is created an additional property with the same name plus an idx suffix will be created, which will hold the index of the selected enum option. You can use the {fieldName_idx} property to sort by the enum value or when your enum options represent a hiyerarchy of values. In the frontend input components, enum type properties should only accept values from an option component that lists the enum options.

status: [pending, approved, rejected, cancelled]

Relation Properties

userId departmentId approverId

Mindbricks supports relations between data objects, allowing you to define how objects are linked together. The relations may reference to a data object either in this service or in another service. Id the reference is remote, backend handles the relations through service communication or elastic search. These relations should be respected in the frontend so that instaead of showing the related objects id, the frontend should list human readable values from other data objects. If the relation points to another service, frontend should use the referenced service api in case it needs related data. The relation logic is montly handled in backend so the api responses feeds the frontend about the relational data. In mmost cases the api response will provide the relational data as well as the main one.

In frontend, please ensure that,

1- instaead of these relational ids you show the main human readable field of the related target data (like name), 2- if this data object needs a user input of these relational ids, you should provide a combobox with the list of possible records or (a searchbox) to select with the realted target data object main human readable field.

userId: ID Relation to user.id

The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target.

Required: Yes

departmentId: ID Relation to userGroup.id

The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target.

Required: No

approverId: ID Relation to user.id

The target object is a sibling object, meaning that the relation is a many-to-one or one-to-one relationship from this object to the target.

Required: No

Filter Properties

userId departmentId leaveType startDate endDate status companyId

Filter properties are used to define parameters that can be used in query filters, allowing for dynamic data retrieval based on user input or predefined criteria. These properties are automatically mapped as API parameters in the listing API’s.

userId: ID has a filter named userId
departmentId: ID has a filter named departmentId
leaveType: String has a filter named leaveType
startDate: Date has a filter named startDate
endDate: Date has a filter named endDate
status: Enum has a filter named status
companyId: ID has a filter named companyId

Default CRUD APIs

For each data object, the backend architect may designate default APIs for standard operations (create, update, delete, get, list). These are the APIs that frontend CRUD forms and AI agents should use for basic record management. If no default is explicitly set (isDefaultApi), the frontend generator auto-discovers the most general API for each operation.

LeaveRequest Default APIs

Operation	API Name	Route	Explicitly Set
Create	`createLeaveRequest`	`/v1/leaverequests`	Yes
Update	`updateLeaveRequest`	`/v1/leaverequests/:leaveRequestId`	Yes
Delete	`deleteLeaveRequest`	`/v1/leaverequests/:leaveRequestId`	Yes
Get	`getLeaveRequest`	`/v1/leaverequests/:leaveRequestId`	Yes
List	`listLeaveRequests`	`/v1/leaverequests`	Yes

When building CRUD forms for a data object, use the default create/update APIs listed above. The form fields should correspond to the API’s body parameters. For relation fields, render a dropdown loaded from the related object’s list API using the display label property.

API Reference

`Create Leaverequest` API

[Default create API] — This is the designated default create API for the leaveRequest data object. Frontend generators and AI agents should use this API for standard CRUD operations. Create a new leave/absence request as an employee user. Sets status to pending. Only allowed if user is creating for themselves. Start and end date are both inclusive.

API Frontend Description By The Backend Architect

UX: Employee fills leave request form (type, date range, reason). Submission creates pending request. Cannot be submitted for past dates, or overlapping with another approved request. User receives feedback/confirmation; entry appears in leave history.

Rest Route

The createLeaveRequest API REST controller can be triggered via the following route:

/v1/leaverequests

Rest Request Parameters

The createLeaveRequest api has got 7 regular request parameters

Parameter	Type	Required	Population
departmentId	ID	false	request.body?.[“departmentId”]
leaveType	String	true	request.body?.[“leaveType”]
startDate	Date	true	request.body?.[“startDate”]
endDate	Date	true	request.body?.[“endDate”]
reason	String	false	request.body?.[“reason”]
approverId	ID	false	request.body?.[“approverId”]
approvedDate	Date	false	request.body?.[“approvedDate”]
departmentId : Department (userGroup) id, for scoping leave if relevant
leaveType : Type of leave (e.g. vacation, sick, emergency).
startDate : First day of leave (inclusive).
endDate : Last day of leave (inclusive).
reason : Employee-provided reason/message for leave request
approverId : UserId of manager/admin who approved/rejected/cancelled the request
approvedDate : Date/time leave was approved/rejected/cancelled, if applicable.

REST Request To access the api you can use the REST controller with the path POST /v1/leaverequests

  axios({
    method: 'POST',
    url: '/v1/leaverequests',
    data: {
            departmentId:"ID",  
            leaveType:"String",  
            startDate:"Date",  
            endDate:"Date",  
            reason:"String",  
            approverId:"ID",  
            approvedDate:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"status": "OK",
	"statusCode": "201",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequest",
	"method": "POST",
	"action": "create",
	"appVersion": "Version",
	"rowCount": 1,
	"leaveRequest": {
		"id": "ID",
		"userId": "ID",
		"departmentId": "ID",
		"requestDate": "Date",
		"leaveType": "String",
		"startDate": "Date",
		"endDate": "Date",
		"reason": "String",
		"status": "Enum",
		"status_idx": "Integer",
		"approverId": "ID",
		"approvedDate": "Date",
		"companyId": "ID",
		"isActive": true,
		"recordVersion": "Integer",
		"createdAt": "Date",
		"updatedAt": "Date",
		"_owner": "ID"
	}
}

`Update Leaverequest` API

[Default update API] — This is the designated default update API for the leaveRequest data object. Frontend generators and AI agents should use this API for standard CRUD operations. Update an existing leave request. Employee can only edit their own request if status is pending. Manager/admin may change status (approve/reject/cancel), set approver/approval date. On approval, will trigger automatic removal from overlapping shifts via scheduleManagement service.

API Frontend Description By The Backend Architect

UX: Employees can only edit/cancel pending requests. Managers/Admins see status change controls for review (approve/reject/cancel), must provide response (automatically audits approver, time). On approval, user is removed from overlapping shifts and notified.

Rest Route

The updateLeaveRequest API REST controller can be triggered via the following route:

/v1/leaverequests/:leaveRequestId

Rest Request Parameters

The updateLeaveRequest api has got 8 regular request parameters

Parameter	Type	Required	Population
leaveRequestId	ID	true	request.params?.[“leaveRequestId”]
departmentId	ID	false	request.body?.[“departmentId”]
leaveType	String	false	request.body?.[“leaveType”]
startDate	Date	false	request.body?.[“startDate”]
endDate	Date	false	request.body?.[“endDate”]
reason	String	false	request.body?.[“reason”]
approverId	ID	false	request.body?.[“approverId”]
approvedDate	Date	false	request.body?.[“approvedDate”]
leaveRequestId : This id paremeter is used to select the required data object that will be updated
departmentId : Department (userGroup) id, for scoping leave if relevant
leaveType : Type of leave (e.g. vacation, sick, emergency).
startDate : First day of leave (inclusive).
endDate : Last day of leave (inclusive).
reason : Employee-provided reason/message for leave request
approverId : UserId of manager/admin who approved/rejected/cancelled the request
approvedDate : Date/time leave was approved/rejected/cancelled, if applicable.

REST Request To access the api you can use the REST controller with the path PATCH /v1/leaverequests/:leaveRequestId

  axios({
    method: 'PATCH',
    url: `/v1/leaverequests/${leaveRequestId}`,
    data: {
            departmentId:"ID",  
            leaveType:"String",  
            startDate:"Date",  
            endDate:"Date",  
            reason:"String",  
            approverId:"ID",  
            approvedDate:"Date",  
    
    },
    params: {
    
        }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequest",
	"method": "PATCH",
	"action": "update",
	"appVersion": "Version",
	"rowCount": 1,
	"leaveRequest": {
		"id": "ID",
		"userId": "ID",
		"departmentId": "ID",
		"requestDate": "Date",
		"leaveType": "String",
		"startDate": "Date",
		"endDate": "Date",
		"reason": "String",
		"status": "Enum",
		"status_idx": "Integer",
		"approverId": "ID",
		"approvedDate": "Date",
		"companyId": "ID",
		"isActive": true,
		"recordVersion": "Integer",
		"createdAt": "Date",
		"updatedAt": "Date",
		"_owner": "ID"
	}
}

`Delete Leaverequest` API

[Default delete API] — This is the designated default delete API for the leaveRequest data object. Frontend generators and AI agents should use this API for standard CRUD operations. Delete (soft) a leave request. Only the owner (employee) can delete a pending request; manager/admin may delete any cancelable request. Deletion is soft for audit/history.

API Frontend Description By The Backend Architect

UX: Employees can delete their own pending requests before review. Admin/manager can delete any not yet actioned or as override. Deletion removes from request history listing (soft deletes only).

Rest Route

The deleteLeaveRequest API REST controller can be triggered via the following route:

/v1/leaverequests/:leaveRequestId

Rest Request Parameters

The deleteLeaveRequest api has got 1 regular request parameter

Parameter	Type	Required	Population
leaveRequestId	ID	true	request.params?.[“leaveRequestId”]
leaveRequestId : This id paremeter is used to select the required data object that will be deleted

REST Request To access the api you can use the REST controller with the path DELETE /v1/leaverequests/:leaveRequestId

  axios({
    method: 'DELETE',
    url: `/v1/leaverequests/${leaveRequestId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequest",
	"method": "DELETE",
	"action": "delete",
	"appVersion": "Version",
	"rowCount": 1,
	"leaveRequest": {
		"id": "ID",
		"userId": "ID",
		"departmentId": "ID",
		"requestDate": "Date",
		"leaveType": "String",
		"startDate": "Date",
		"endDate": "Date",
		"reason": "String",
		"status": "Enum",
		"status_idx": "Integer",
		"approverId": "ID",
		"approvedDate": "Date",
		"companyId": "ID",
		"isActive": false,
		"recordVersion": "Integer",
		"createdAt": "Date",
		"updatedAt": "Date",
		"_owner": "ID"
	}
}

`Get Leaverequest` API

[Default get API] — This is the designated default get API for the leaveRequest data object. Frontend generators and AI agents should use this API for standard CRUD operations. Retrieve the details of a single leave request record. Enriches with user and department data in response. Owner (employee) can always view own request; admin/manager can view all requests in their company.

API Frontend Description By The Backend Architect

UX: Employee can view own leave request with details and status. Manager/admin see details and audit info. Related user, department, and approver info shown (join).

Rest Route

The getLeaveRequest API REST controller can be triggered via the following route:

/v1/leaverequests/:leaveRequestId

Rest Request Parameters

The getLeaveRequest api has got 1 regular request parameter

Parameter	Type	Required	Population
leaveRequestId	ID	true	request.params?.[“leaveRequestId”]
leaveRequestId : This id paremeter is used to query the required data object.

REST Request To access the api you can use the REST controller with the path GET /v1/leaverequests/:leaveRequestId

  axios({
    method: 'GET',
    url: `/v1/leaverequests/${leaveRequestId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequest",
	"method": "GET",
	"action": "get",
	"appVersion": "Version",
	"rowCount": 1,
	"leaveRequest": {
		"id": "ID",
		"userId": "ID",
		"departmentId": "ID",
		"requestDate": "Date",
		"leaveType": "String",
		"startDate": "Date",
		"endDate": "Date",
		"reason": "String",
		"status": "Enum",
		"status_idx": "Integer",
		"approverId": "ID",
		"approvedDate": "Date",
		"companyId": "ID",
		"isActive": true,
		"recordVersion": "Integer",
		"createdAt": "Date",
		"updatedAt": "Date",
		"_owner": "ID",
		"user": {
			"email": "String",
			"fullname": "String",
			"avatar": "String"
		},
		"approver": {
			"email": "String",
			"fullname": "String",
			"avatar": "String"
		}
	}
}

`List Leaverequests` API

[Default list API] — This is the designated default list API for the leaveRequest data object. Frontend generators and AI agents should use this API for standard CRUD operations. List leave requests visible to the user. Employees see their own; managers/admins can filter by department, user, status, and date. Response includes enrichment joins for user, department, and approver.

API Frontend Description By The Backend Architect

UX: Employees see their own requests; managers/admins can search/filter requests for department, user, date, or status; list includes enrichment data for related fields.

Rest Route

The listLeaveRequests API REST controller can be triggered via the following route:

/v1/leaverequests

Rest Request Parameters

Filter Parameters

The listLeaveRequests api supports 6 optional filter parameters for filtering list results:

userId (ID): ID of employee/user requesting leave (auth:user.id)

Single: ?userId=<value>
Multiple: ?userId=<value1>&userId=<value2>
Null: ?userId=null

departmentId (ID): Department (userGroup) id, for scoping leave if relevant

Single: ?departmentId=<value>
Multiple: ?departmentId=<value1>&departmentId=<value2>
Null: ?departmentId=null

leaveType (String): Type of leave (e.g. vacation, sick, emergency).

Single (partial match, case-insensitive): ?leaveType=<value>
Multiple: ?leaveType=<value1>&leaveType=<value2>
Null: ?leaveType=null

startDate (Date): First day of leave (inclusive).

Single date: ?startDate=2024-01-15
Multiple dates: ?startDate=2024-01-15&startDate=2024-01-20
Special: $today, $ltoday, $week, $lweek, $month, $leq-<date>, $lin-<date>
Null: ?startDate=null

endDate (Date): Last day of leave (inclusive).

Single date: ?endDate=2024-01-15
Multiple dates: ?endDate=2024-01-15&endDate=2024-01-20
Special: $today, $ltoday, $week, $lweek, $month, $leq-<date>, $lin-<date>
Null: ?endDate=null

status (Enum): Leave request status (pending, approved, rejected, cancelled).

Single: ?status=<value> (case-insensitive)
Multiple: ?status=<value1>&status=<value2>
Null: ?status=null

REST Request To access the api you can use the REST controller with the path GET /v1/leaverequests

  axios({
    method: 'GET',
    url: '/v1/leaverequests',
    data: {
    
    },
    params: {
    
        // Filter parameters (see Filter Parameters section above)
        // userId: '<value>' // Filter by userId
        // departmentId: '<value>' // Filter by departmentId
        // leaveType: '<value>' // Filter by leaveType
        // startDate: '<value>' // Filter by startDate
        // endDate: '<value>' // Filter by endDate
        // status: '<value>' // Filter by status
            }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequests",
	"method": "GET",
	"action": "list",
	"appVersion": "Version",
	"rowCount": "\"Number\"",
	"leaveRequests": [
		{
			"id": "ID",
			"userId": "ID",
			"departmentId": "ID",
			"requestDate": "Date",
			"leaveType": "String",
			"startDate": "Date",
			"endDate": "Date",
			"reason": "String",
			"status": "Enum",
			"status_idx": "Integer",
			"approverId": "ID",
			"approvedDate": "Date",
			"companyId": "ID",
			"isActive": true,
			"recordVersion": "Integer",
			"createdAt": "Date",
			"updatedAt": "Date",
			"_owner": "ID",
			"user": [
				{
					"email": "String",
					"fullname": "String",
					"avatar": "String"
				},
				{},
				{}
			],
			"department": [
				null,
				null,
				null
			],
			"approver": [
				{
					"email": "String",
					"fullname": "String",
					"avatar": "String"
				},
				{},
				{}
			]
		},
		{},
		{}
	],
	"paging": {
		"pageNumber": "Number",
		"pageRowCount": "NUmber",
		"totalRowCount": "Number",
		"pageCount": "Number"
	},
	"filters": [],
	"uiPermissions": []
}

`List Myleaverequests` API

List the currently logged-in user’s own leave requests. Always scoped to the authenticated user’s userId. Available to all roles.

API Frontend Description By The Backend Architect

UX: Shows the logged-in user’s own leave requests with status, dates, and approver info. Supports pagination and sorting by most recent first.

Rest Route

The listMyLeaveRequests API REST controller can be triggered via the following route:

/v1/myleaverequests

Rest Request Parameters

Filter Parameters

The listMyLeaveRequests api supports 6 optional filter parameters for filtering list results:

userId (ID): ID of employee/user requesting leave (auth:user.id)

Single: ?userId=<value>
Multiple: ?userId=<value1>&userId=<value2>
Null: ?userId=null

departmentId (ID): Department (userGroup) id, for scoping leave if relevant

Single: ?departmentId=<value>
Multiple: ?departmentId=<value1>&departmentId=<value2>
Null: ?departmentId=null

leaveType (String): Type of leave (e.g. vacation, sick, emergency).

Single (partial match, case-insensitive): ?leaveType=<value>
Multiple: ?leaveType=<value1>&leaveType=<value2>
Null: ?leaveType=null

startDate (Date): First day of leave (inclusive).

Single date: ?startDate=2024-01-15
Multiple dates: ?startDate=2024-01-15&startDate=2024-01-20
Special: $today, $ltoday, $week, $lweek, $month, $leq-<date>, $lin-<date>
Null: ?startDate=null

endDate (Date): Last day of leave (inclusive).

Single date: ?endDate=2024-01-15
Multiple dates: ?endDate=2024-01-15&endDate=2024-01-20
Special: $today, $ltoday, $week, $lweek, $month, $leq-<date>, $lin-<date>
Null: ?endDate=null

status (Enum): Leave request status (pending, approved, rejected, cancelled).

Single: ?status=<value> (case-insensitive)
Multiple: ?status=<value1>&status=<value2>
Null: ?status=null

REST Request To access the api you can use the REST controller with the path GET /v1/myleaverequests

  axios({
    method: 'GET',
    url: '/v1/myleaverequests',
    data: {
    
    },
    params: {
    
        // Filter parameters (see Filter Parameters section above)
        // userId: '<value>' // Filter by userId
        // departmentId: '<value>' // Filter by departmentId
        // leaveType: '<value>' // Filter by leaveType
        // startDate: '<value>' // Filter by startDate
        // endDate: '<value>' // Filter by endDate
        // status: '<value>' // Filter by status
            }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequests",
	"method": "GET",
	"action": "list",
	"appVersion": "Version",
	"rowCount": "\"Number\"",
	"leaveRequests": [
		{
			"id": "ID",
			"userId": "ID",
			"departmentId": "ID",
			"requestDate": "Date",
			"leaveType": "String",
			"startDate": "Date",
			"endDate": "Date",
			"reason": "String",
			"status": "Enum",
			"status_idx": "Integer",
			"approverId": "ID",
			"approvedDate": "Date",
			"companyId": "ID",
			"isActive": true,
			"recordVersion": "Integer",
			"createdAt": "Date",
			"updatedAt": "Date",
			"_owner": "ID",
			"user": [
				{
					"email": "String",
					"fullname": "String",
					"avatar": "String"
				},
				{},
				{}
			],
			"department": [
				null,
				null,
				null
			],
			"approver": [
				{
					"email": "String",
					"fullname": "String",
					"avatar": "String"
				},
				{},
				{}
			]
		},
		{},
		{}
	],
	"paging": {
		"pageNumber": "Number",
		"pageRowCount": "NUmber",
		"totalRowCount": "Number",
		"pageCount": "Number"
	},
	"filters": [],
	"uiPermissions": []
}

`Get Myleaverequest` API

Retrieve the details of a single leave request by ID, scoped to the currently logged-in user. The user can only see their own leave request. Enriches response with user, department, and approver info.

API Frontend Description By The Backend Architect

UX: Employee views their own leave request detail with full info. Enriched with user, department, and approver joins. Returns 404 if the record doesn’t exist or doesn’t belong to the logged-in user.

Rest Route

The getMyLeaveRequest API REST controller can be triggered via the following route:

/v1/myleaverequest/:leaveRequestId

Rest Request Parameters

The getMyLeaveRequest api has got 1 regular request parameter

Parameter	Type	Required	Population
leaveRequestId	ID	true	request.params?.[“leaveRequestId”]
leaveRequestId : This id paremeter is used to query the required data object.

REST Request To access the api you can use the REST controller with the path GET /v1/myleaverequest/:leaveRequestId

  axios({
    method: 'GET',
    url: `/v1/myleaverequest/${leaveRequestId}`,
    data: {
    
    },
    params: {
    
        }
  });

REST Response

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "leaveRequest",
	"method": "GET",
	"action": "get",
	"appVersion": "Version",
	"rowCount": 1,
	"leaveRequest": {
		"id": "ID",
		"userId": "ID",
		"departmentId": "ID",
		"requestDate": "Date",
		"leaveType": "String",
		"startDate": "Date",
		"endDate": "Date",
		"reason": "String",
		"status": "Enum",
		"status_idx": "Integer",
		"approverId": "ID",
		"approvedDate": "Date",
		"companyId": "ID",
		"isActive": true,
		"recordVersion": "Integer",
		"createdAt": "Date",
		"updatedAt": "Date",
		"_owner": "ID",
		"user": {
			"email": "String",
			"fullname": "String",
			"avatar": "String"
		},
		"approver": {
			"email": "String",
			"fullname": "String",
			"avatar": "String"
		}
	}
}

After this prompt, the user may give you new instructions to update the output of this prompt or provide subsequent prompts about the project.

WORKFORCEOS

Service Access

Tenant URL Prefix and Header Forwarding

Scope

LeaveManagement Service Frontend Description By The Backend Architect

UX Hints - leaveManagement Service

API Structure

Object Structure of a Successful Response

Additional Data

Error Response

LeaveRequest Data Object

LeaveRequest Data Object Frontend Description By The Backend Architect

LeaveRequest Data Object Properties

Enum Properties

Relation Properties

Filter Properties

Default CRUD APIs

LeaveRequest Default APIs

API Reference

Create Leaverequest API

Update Leaverequest API

Delete Leaverequest API

Get Leaverequest API

List Leaverequests API

List Myleaverequests API

Get Myleaverequest API

`Create Leaverequest` API

`Update Leaverequest` API

`Delete Leaverequest` API

`Get Leaverequest` API

`List Leaverequests` API

`List Myleaverequests` API

`Get Myleaverequest` API