Skip to main content

API Validation Catalog

Summary​

Lifecycle validation is distributed across HTTP binding, application handlers, domain aggregates, monolith controller checks, tenant-filtered queries, and Employee Service validators. No dedicated extracted onboarding request-validator classes were found.

Audience​

Developers, QA, support, and solution architects.

Reference Content​

Validation is catalogued by the boundary at which each rule is enforced.

Validation pipeline​

Request validation​

SurfaceVerified checks
Native minimal APIFramework binding plus handler validation; no onboarding-specific validator class
Public offer rejectionNon-empty reason
Compatibility statusCompleted blocked on status operation; dedicated completion required
Monolith onboarding taskEmployee and task name; employee tenant existence
Exit creationReason, last-working date, active-request uniqueness
Exit decisionsRecord existence, actor scope, permitted state, action-specific reason/date
Access revokeEligibility query based on state and effective date
Workflow callbackCallback body/result, subject type, tenant, requisition resolution

Domain validation​

  • Offer acceptance enforces terminal-state restrictions and idempotence.
  • Move-to-onboarding requires Accepted and reuses an active aggregate.
  • Onboarding status uses flexible enum parsing.
  • Completed onboarding is terminal; repeated Completed is idempotent.
  • Public offer rejection conflicts with Accepted.

Downstream validation​

Employee Service applies async create-command validation for employee code, names/contact/organization references, manager rules, and employment data. Recruitment does not duplicate the complete downstream validator set.

Frontend validation​

The onboarding page requires core employee, organization, joining, and compensation inputs before compatibility completion. The exit page checks dates and reason. These checks improve usability but are not authoritative server validation and may exceed what the extracted adapter consumes.

Missing or partial validation​

  • No extracted onboarding DTO validator class
  • No server-enforced document checklist
  • No automatic asset or clearance validation before exit processing
  • No link expiry/revocation validation found in public offer flow
  • Compatibility completion does not validate or consume every accepted field on the extracted path
  • No shared validator ensures parity across legacy and extracted targets

Requires confirmation​

  • Canonical request validator ownership.
  • Required limits, formats, and sensitivity handling for completion fields.
  • Whether invalid minimal-API binding receives a standardized error body in all cases.
  • Cross-target validation parity requirements.

Source References​

  • microservices/src/recruitment-service/Application/Commands/OnboardingCommands.cs
  • microservices/src/recruitment-service/Application/Commands/OfferCommands.cs
  • microservices/src/recruitment-service/Application/Compatibility/CompatCommands.cs
  • microservices/src/recruitment-service/Domain/Recruitment/Onboarding.cs
  • microservices/src/employee-service/Application/Validators/EmployeeCommandValidators.cs
  • Controllers/RecruitmentController.cs
  • Controllers/HrOperationsController.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/hr/RecruitmentOnboardingPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/hr/HrOperationsPage.tsx

See Also​

Keywords​

  • Domain validation
  • Missing validator
  • Validation parity

Revision Information​

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