WFM Utilization Report API 400 Bad Request: Invalid Date Range for Chicago Shift

General Discussion
1 
{
 "errors": [
 {
 "code": 400,
 "message": "Invalid date range. End date must be after start date.",
 "parameter": "endDate"
 }
 ]
}

Background

Our team manages workforce scheduling for a mid-sized contact center operating in the America/Chicago timezone. We publish schedules weekly using the standard WFM workflows. Agents utilize the self-service portal for shift swaps and time-off requests, which generally function without issue. Recently, we integrated a custom dashboard to visualize real-time utilization metrics derived from the WFM reporting APIs. The integration relies on the GET /api/v2/wfm/reports/utilization endpoint. We are using the Genesys Cloud Python SDK version 6.2.1.

Issue

When attempting to fetch utilization data for the current week (Monday to Friday, Chicago time), the API consistently returns a 400 Bad Request error. The error payload explicitly states that the endDate must be after the startDate, despite the dates provided being logically correct and formatted as ISO 8601 strings with timezone offsets.

For example:

  • startDate: 2023-10-23T00:00:00-05:00
  • endDate: 2023-10-27T23:59:59-05:00

This issue only occurs when the report spans across multiple days. Single-day reports succeed. We have verified that the agent groups and skill IDs passed in the request body are valid and exist in the organization. The problem persists across different API keys and users with wfm:report:read permissions.

Troubleshooting

  1. Date Format Verification: Confirmed that the dates are in strict ISO 8601 format with the correct -05:00 offset for Chicago. Tried UTC offsets (+00:00) with no change in outcome.
  2. SDK Validation: Tested the same request using Postman with raw JSON payloads to rule out SDK serialization bugs. The error remains.
  3. Scope Check: Verified that the API keys have the necessary wfm:report:read and wfm:schedule:read scopes.
  4. Single-Day Test: Narrowed the date range to a single day (e.g., 2023-10-23 to 2023-10-23). The request succeeds, returning data correctly.

Has anyone encountered a similar validation error with multi-day WFM utilization reports? Is there a known limitation or a specific format requirement for multi-day ranges in the current API version?