Leave Compatibility API

Summary

Five compatibility operations preserve the established Leave-request client contract while gateway ownership can move between monolith and Leave Service.

Audience

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

Reference Content

Maturity: Compatibility / Transitional. Authentication: required by monolith controller and expected through gateway. Authorization: monolith confirms self/team/tenant-wide visibility, approver scope, and owned-Pending/broader cancellation; extracted parity Requires confirmation. Tenant: required.

Operation	Method/public route	Request/parameters	Response/status	Behavior/side effects
List requests	GET /api/leave-requests	None	200 LeaveRequestDto[]/compatible rows	Scoped list; read-only.
List approved range	GET /api/leave-requests/approved	Required start, end; optional laborId	200 list; monolith may return 403 for out-of-scope employee	Approved overlapping range; read-only.
Create request	POST /api/leave-requests	CreateLeaveRequest-compatible body	200 request row; 400 validation/dependency	Self forced Pending; tenant-wide administration may auto-approve when Workflow is off; calculation/conflict/audit/event/balance behavior matches current owner.
Update status	PUT /api/leave-requests/{id}/status	Route id; status body with rejection reason	200 row; 400/404; 403 monolith scope; 409 managed restriction in service	Approval/rejection/cancellation; balance and audit/event effects.
Cancel request	DELETE /api/leave-requests/{id}	Route id	200 plain success; missing outcome owner-dependent	Logical cancellation in Leave Service; monolith compatibility can physically delete through its service, so semantics are Transitional.

Request/response fields align with Leave Requests and Approval. Monolith status payload also accepts a JSON string; the extracted DTO expects an object, so clients should use the object shape.

Safe examples: GET /api/leave-requests; POST with the synthetic request from the Direct page; PUT .../status with {"status":"Rejected","rejectionReason":"Scheduling conflict"}; DELETE /api/leave-requests/700001. Do not assume identical authorization or cancellation persistence until cutover parity is approved.

Source References

• microservices/src/leave-service/Api/LeaveEndpoints.cs
• Controllers/LeaveRequestsController.cs
• microservices/src/gateway-api/Program.cs

Related Articles

• Compatibility and routing
• Response and error model

See Also

• Leave API
• Leave technical documentation

Keywords

• Leave API
• Compatibility
• Leave Compatibility API

Revision Information

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