Leave Requests API

Summary

Three Direct operations create and query Leave requests. No get-by-id, general search, status filter, update, resubmit, or supporting-document operation exists.

Audience

Frontend/backend developers, QA, support, and implementation partners.

Reference Content

Family: Leave Requests. Maturity: Direct / Transitional. Authentication: bearer context expected; per-route enforcement Requires confirmation. Authorization: list/create scope Requires confirmation in extracted service. Tenant: required for create and expected for scoped queries.

Operation	Method and public route	Parameters/body and type	Response and statuses	Behavior and side effects
List Leave requests	GET /leave/requests	No route/query/body	200 LeaveRequestDto[]	Tenant-filtered newest-date-first list; no audit, balance, Attendance call, Workflow action, or events.
List approved in range	GET /leave/requests/approved	Required query start, end; optional laborId	200 LeaveRequestDto[]	Approved requests overlapping range; optional employee filter; read-only.
Create Leave request	POST /leave/requests	Body CreateLeaveRequest	200 LeaveRequestDto; handled failures 400	Validates tenant, employee/activity/joining date, date order, Attendance conflict, approved overlap, positive calculated days. Creates Pending or approved administrative result; can start Workflow; audits/timeline; emits high-level request/approval events and may update balance when approved.

CreateLeaveRequest fields: laborId, type, fromDate, toDate, optional reason, optional days (accepted but server recomputes), halfDay, and optional status (accepted for compatibility but server controls status). LeaveRequestDto fields: id, laborId, employee, manager, type, days, status, fromDate, toDate, reason, rejectionReason, and optional workflowInstanceId.

Safe examples:

GET /leave/requests/approved?start=2032-04-01&end=2032-04-30

{
  "laborId": 900001,
  "type": "Configured Leave",
  "fromDate": "2032-04-10",
  "toDate": "2032-04-11",
  "reason": "Planned absence",
  "halfDay": false
}

Success is a LeaveRequestDto with server-generated identifiers and calculated days. A safe error example is "End date cannot be before start date." with 400. Compatibility equivalents are documented separately.

Source References

• microservices/src/leave-service/Api/LeaveEndpoints.cs
• microservices/src/leave-service/Application/Dtos.cs
• microservices/src/leave-service/Application/LeaveWorkflows.cs

Related Articles

• Leave API
• Authentication and context
• Response and error model

See Also

• Leave technical documentation
• Leave business documentation

Keywords

• Leave API
• Leave Requests API
• Endpoint reference

Revision Information

• Status: Draft
• Last reviewed: 2026-07-15
• Review cycle: Quarterly