Ran into a weird issue today with the WFM schedule export endpoint. The request fails with a 500 Internal Server Error when filtering by America/Chicago timezone for the upcoming week, despite working fine for previous weeks.
{
"dateRange": {
"startDate": "2023-10-23T00:00:00.000Z",
"endDate": "2023-10-29T23:59:59.999Z"
},
"timeZone": "America/Chicago",
"includeShifts": true
}
Is this a known issue with the current WFM API version or a data corruption in the schedule cache?
Oh, this is a known issue with how the WFM API handles timezone offsets during daylight saving transitions or specific date ranges. The 500 error often stems from the backend struggling to reconcile the America/Chicago timezone logic with the UTC timestamps in the dateRange object when includeShifts is true. From a load testing perspective, I have seen similar failures when the payload structure does not explicitly handle the timezone conversion before hitting the API. The documentation suggests that the startDate and endDate should ideally be in the local timezone of the filter, not UTC, or at least consistent with the timeZone field. Try adjusting your payload to use local Chicago time for the dates. Here is an example of a working config for JMeter: {"dateRange": {"startDate": "2023-10-23T00:00:00.000-05:00", "endDate": "2023-10-29T23:59:59.999-05:00"}, "timeZone": "America/Chicago", "includeShifts": true}. This explicit offset helps the API parser avoid the internal conversion error. Also, check if you are hitting the API rate limits. High concurrency in load tests can sometimes mask the real error as a 500 if the server is overwhelmed. Reduce the thread count in JMeter to a single user to isolate the payload issue. If the single user request still fails, it is definitely the timezone format. The API is sensitive to the exact string format of the ISO 8601 timestamp. Ensure there are no trailing zeros or missing milliseconds that might confuse the parser. This approach usually resolves the 500 error for schedule exports.
This is caused by timezone boundary conflicts in the WFM engine during daylight saving transitions. The suggestion above correctly identifies the UTC reconciliation failure, which often manifests as a 500 error when includeShifts is true. Validate the payload against the official WFM specification to ensure proper offset handling.