Skip to main content

API Limitations and Confirmation Register

Summary

The lifecycle API is Transitional. The following limitations are verified implementation boundaries, not roadmap commitments.

Audience

Engineering, QA, support, security, architecture, and product owners.

Reference Content

AreaVerified limitationClassification
AuthenticationExtracted endpoints do not require the registered authentication schemeSecurity review required
AuthenticationEmployee handoff forwards tenant context without workload credentialSecurity review required
AuthorizationExtracted policy list is empty; native and compatibility groups apply no policySecurity review required
AuthorizationGateway does not authorize proxied lifecycle trafficImplemented boundary
Tenant isolationActive-onboarding lookup bypasses global filters without explicit tenant predicateSecurity review required
Tenant isolationPublic links perform cross-tenant lookup by capability valueRequires confirmation
ValidationNo dedicated extracted onboarding request validatorsPartial
ValidationChecklist, document, asset, payroll, and clearance prerequisites are not enforcedNot implemented
CompatibilitySame route can have different security, persistence, profile, login, and error behaviorTransitional
CompatibilityExtracted completion consumes only part of the compatibility DTOPartial
ResponsesNo common lifecycle response or error envelopeTransitional
ResponsesCompatibility completion handles sensitive login-bootstrap materialSecurity review required
Employee integrationNo distributed transaction or automatic reconciliationNot implemented
Employee integrationOrganization, manager, and location mapping is incompletePartial
ChecklistOnly a generic task save/workspace boundary existsFoundation
WorkflowExisting callback is requisition-only and has no required endpoint policyFoundation/security review
NotificationsExit uses internal dispatch; extracted onboarding has no verified notification HTTP boundary/resolverPartial
HealthProcess health does not establish dependency readinessFoundation
OpenAPISwagger middleware exists without a curated lifecycle contractFoundation
TestingNo dedicated exit, security, parity, failure-path, or UI suites foundCoverage gap
VersioningNo explicit API versioning, deprecation, or sunset strategyNot implemented

Priority confirmation themes

  1. Require authentication and operation-specific authorization at extracted boundaries.
  2. Define trusted tenant and service-identity contracts and test isolation.
  3. Decide compatibility parity, cutover, rollback, and retirement criteria.
  4. Remove or redesign sensitive completion-response behavior.
  5. Add offboarding, dual-target, downstream-failure, and security automation.
  6. Establish lifecycle versioning and OpenAPI ownership.

Source References

  • microservices/src/recruitment-service/Program.cs
  • microservices/src/recruitment-service/Api/Policies.cs
  • microservices/src/recruitment-service/Api/RecruitmentEndpoints.cs
  • microservices/src/recruitment-service/Api/RecruitmentCompatEndpoints.cs
  • microservices/src/recruitment-service/Infrastructure/Persistence.cs
  • microservices/src/recruitment-service/Infrastructure/EmployeeServiceClient.cs
  • microservices/src/gateway-api/Program.cs
  • Controllers/RecruitmentController.cs
  • Controllers/HrOperationsController.cs

See Also

Keywords

  • API limitations
  • Security review
  • Compatibility risk

Revision Information

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