Leave Cancellation API

Summary

One Direct DELETE operation performs logical cancellation rather than physical deletion.

Audience

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

Reference Content

Maturity: Direct / Transitional. Authentication: expected. Authorization: extracted-service enforcement Requires confirmation; monolith compatibility confirms owned Pending cancellation and broader authorized cancellation. Tenant: required.

Operation	Method and public route	Parameters/body	Response and statuses	Behavior/side effects
Cancel Leave request	DELETE /leave/requests/{id}	Route id:int; no query/body	200 plain success string; missing/invalid becomes 400 through current wrapper	Delegates to status cancellation; Pending or Approved can become Cancelled; prior Approved usage is reversed; audit/timeline and high-level cancellation/balance events occur.

Example: DELETE /leave/requests/700001 → 200 "Deleted successfully". A missing request currently becomes a generic 400 from the cancellation wrapper rather than the underlying 404 category.

The PUT status operation also accepts Cancelled and returns a DTO, but is inventoried once under approval/rejection. Attendance records are not mutated. Payroll correction timing and post-Payroll restrictions are not implemented/confirmed. No withdrawal or cancellation-approval API exists.

Source References

• microservices/src/leave-service/Api/LeaveEndpoints.cs
• microservices/src/leave-service/Application/LeaveWorkflows.cs
• microservices/src/leave-service/Domain/Leave/LeaveRequest.cs
• Controllers/LeaveRequestsController.cs

Related Articles

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

See Also

• Leave technical documentation
• Leave business documentation

Keywords

• Leave API
• Leave Cancellation API
• Endpoint reference

Revision Information

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