Leave Workflow Callback API

Summary

One Internal Direct-group operation applies terminal Workflow approval or rejection to a managed Leave request.

Audience

Workflow/Leave developers, QA, architects, security reviewers, and support.

Reference Content

Maturity: Internal / Transitional. Authentication/authorization: approved trusted service boundary required; exact endpoint enforcement Requires confirmation. Tenant: required for correctly scoped request resolution and persistence.

Operation	Method/route	Request	Response/status	Behavior
Apply Workflow completion	POST /leave/workflow/callback	LeaveWorkflowCallbackRequest	200 LeaveRequestDto; 400 invalid; 404 unresolved request; 409 verified state mismatch	Resolves by request/subject/workflow identity; maps Approved/Completed or Rejected; ignores duplicate terminal callback; optionally verifies Workflow state; applies approval balance usage; audits/timeline; emits high-level decision/balance events.

Request fields: optional workflowInstanceId, optional subjectType, optional subjectId, optional leaveRequestId, result, and optional reason. At least enough identity to resolve a request is required in practice. Rejection uses the supplied reason or a service fallback.

A safe conceptual request uses synthetic correlation values and "result":"Approved"; sensitive trust material is never included in examples. This is not an employee-facing approval endpoint.

Source References

• microservices/src/leave-service/Api/LeaveEndpoints.cs
• microservices/src/leave-service/Application/WorkflowIntegration.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 Workflow Callback API
• Endpoint reference

Revision Information

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