API Versioning
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
No formal API-versioning registration, version attributes, versioned route segment, media-type version, query-string version, or version-negotiation middleware was found for Workforce Scheduling.
Current strategy
Compatibility is achieved by maintaining parallel native and legacy-shaped route families rather than by assigning formal API versions. Gateway ownership changes the runtime target without changing the client route. DTOs contain no schema-version field.
Consequences
Contract evolution relies on additive changes, compatibility preservation, and coordinated cutover. There is no verified deprecation header, sunset signal, supported-version matrix, or compatibility retirement policy.
Classification
Formal versioning is Not implemented. Compatibility routes are Transitional. Versioning and deprecation policy require confirmation before external contract guarantees are made.
Source References
microservices/src/attendance-service/Program.csmicroservices/src/attendance-service/Api/AttendanceShiftPolicyEndpoints.csmicroservices/src/attendance-service/Api/ShiftPolicyCompatEndpoints.csmicroservices/src/gateway-api/Program.cs
Related Articles
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