Skip to main content

API Limitations

Audience​

Developers, QA engineers, support engineers, security engineers, solution architects, and implementation partners.

Reference Content​

This page records source-verified Workforce Scheduling API behavior and boundaries.

Summary​

These limitations are verified from source. Production state and policy items are marked Requires confirmation.

Authentication​

  • Authentication is registered but not explicitly required by scheduling endpoint groups or a fallback policy.
  • Compatibility mutation logic trusts unauthenticated upstream requests.
  • OpenAPI authentication metadata was not verified.
  • Gateway authentication enforcement requires confirmation.

Authorization​

  • Native reads and mutations have no role or permission checks.
  • Named Attendance policies are registered but unused by scheduling routes.
  • Compatibility mutations deny authenticated non-administrators only.
  • Operational and scheduling diagnostic endpoints are not explicitly protected.

Scheduling​

  • The API models shifts, weekly offs, and policies rather than complete rosters.
  • No rotation, availability, demand, break, split-shift, swap, publication, or schedule-copy endpoint exists.
  • Holiday endpoints are outside this slice.
  • Retroactive attendance recalculation after configuration change is not exposed.

Assignment​

  • Only creation and employee-scoped listing exist.
  • Update, end, deactivate, reactivate, delete, bulk, group, and roster assignment are absent.
  • Overlap is checked before write without a database exclusion constraint.
  • No frontend assignment consumer was found.

Validation​

  • Validation is procedural; no dedicated validator framework or DTO annotations were found.
  • Positive identifiers are not uniformly validated across reads and mutations.
  • Shift-name uniqueness and assignment overlap can race.
  • No concurrency token, idempotency key, or request-size rule was verified.
  • Probe-hour validation is absent at the endpoint.

Compatibility​

  • Native and compatibility response/error patterns differ.
  • Direct delete conflicts on active assignments; compatibility delete deactivates them.
  • Native weekly-off updates are partial; compatibility updates replace the full active set.
  • Legacy overtime text maps to a narrower numeric meaning.
  • Compatibility retirement criteria require confirmation.

Gateway​

  • Runtime ownership depends on a feature-controlled route decision.
  • Weekly-off fallback can resolve to different existing owners.
  • Policy compatibility has no monolith counterpart.
  • Trusted header propagation and sanitization require confirmation.
  • Shadow access expands the routable compatibility surface.

Versioning​

  • Formal API versioning is Not implemented.
  • No deprecation or sunset mechanism was found.
  • Contract evolution depends on parallel route families and coordinated cutover.

Testing​

  • No dedicated backend unit/integration test project was found.
  • No automated frontend shift-management tests were found.
  • Existing assurance is script-centered.
  • Security, tenant, concurrency, binding, full contract, performance, and resilience coverage is missing.

Source References​

  • microservices/src/attendance-service/Program.cs
  • microservices/src/attendance-service/Api/AttendanceShiftPolicyEndpoints.cs
  • microservices/src/attendance-service/Api/ShiftPolicyCompatEndpoints.cs
  • microservices/src/attendance-service/Application/Services/ShiftPolicyCommands.cs
  • microservices/src/gateway-api/Program.cs

See Also​

Keywords​

  • Workforce Scheduling API
  • Shift endpoints
  • Attendance policy API

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Next review: 2026-10-20