Payroll API Compatibility and Routing

Summary

The gateway selects monolith or Payroll Service ownership for compatibility routes while native Payroll routes support shadow/direct verification.

Audience

Frontend and backend developers, QA and support engineers, architects, security reviewers, and implementation partners.

Overview

Routing model

Compatibility route families retain client-facing monolith shapes. Gateway-controlled ownership can direct those requests to the monolith or Payroll Service. Native Payroll paths remain a separate shadow/direct surface used for service validation. Exact internal route tables and routing-setting names are intentionally excluded.

Transitional differences

Native and compatibility contracts differ in DTO shape, error bodies, identifier types, filtering, and lifecycle side effects. Native unfreeze produces Unfrozen and recovery reversals. Salary compatibility unfreeze produces Draft and does not use the same native event/reversal path. Cutover scripts verify route source and parity; rollback after Payroll Service writes requires reconciliation planning.

No endpoint is marked deprecated. Compatibility is Transitional, not deprecated.

Source References

• microservices/src/gateway-api/Program.cs
• microservices/src/payroll-service/Api/PayrollCompatEndpoints.cs
• microservices/src/payroll-service/Application/PayrollCompatService.cs
• microservices/scripts/smoke-payroll-cutover.ps1
• microservices/scripts/compare-payroll-parity.ps1
• microservices/scripts/payroll-cutover-go-no-go.ps1

Related Articles

• Payroll API
• Payroll technical documentation

See Also

• Payroll business documentation
• Payroll module

Keywords

• Payroll API
• Payroll API Compatibility and Routing

Revision Information

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