“{“message”:“Bad Request”,“code”:400,“details”:[{“field”:“timeZone”,“message”:“must be a valid time zone identifier”,“code”:“invalid_format”}]}”-that’s the response when updating user preferences via the API, and it’s happening intermittently, but consistently enough to be a problem. The flow is MuleSoft calling the Genesys Cloud API to set timezone after a user completes an onboarding form, using the Java SDK version 49.0.0. It’s not a simple string issue, though-the SDK’s User object handles the timezone formatting, and the same payload works fine sometimes, then fails with that invalid format error. The user ID is passed correctly, and we’ve confirmed the user exists.
Genesys Cloud region: us-east-1
Java SDK version: 49.0.0
MuleSoft version: 4.4.0
API endpoint: PATCH /api/v2/users/{userId}
We’ve tried throttling the calls to eliminate any potential race conditions.
We’ve verified the timezone string is a valid IANA timezone identifier, like “America/Chicago”.
We’ve checked the user’s existing timezone to see if there’s a conflict, but the flow sets it regardless.
The payload being sent is something like this: User user = new User(); user.setTimeZone("America/Chicago"); patchUser(userId, user); - it’s not a formatting error on our end, it’s the API rejecting a valid timezone string.
The SCHEMA VALIDATION errors usually mean the timezone string isn’t IANA compliant - try formatting it as “America/Los_Angeles” instead of just “Pacific Time”. We’ve seen this come up a few times with SDKs and external integrations, and it’s usually a case of needing the full IANA name. You can verify the valid IANA timezone strings by fetching the list of time zones from the API. Here is a quick way to check available time zones with curl - replace YOUR_API_KEY:
That’s right - the IANA timezone format is mandatory (400). The SDK likely isn’t performing that validation itself. Why would it? A simple Terraform module variable constraint prevents this entirely.
variable "time_zone" {
type = string
validation {
condition = can(regex("^[A-Za-z/_-]+$", var.time_zone))
error_message = "Time zone must be a valid IANA identifier."
}
}
The regex ensures only valid IANA identifiers are passed to the API. It’s cleaner than attempting to parse the string within the integration layer.
That fixed it- switched to the full IANA timezone name and the 400 is gone, consistently. We’re on Zoom Contact Center, Genesys Cloud, and hadn’t accounted for that level of strictness in the preference update.
That’s fantastic to hear the IANA timezone fix worked! It’s so easy to overlook those little details- especially when things are working intermittently. We’ve got about 1200 agents and ran into a similar issue a few months back when integrating with a new HR system.
And just to add to what As noted above about Terraform validation- you can actually achieve the same thing with a custom input validation step in your MuleSoft flow! It’s a little more work upfront, but it prevents invalid timezones from even reaching the API, which is super nice! Here’s a quick DataWeave snippet- it uses a regex to check if the timezone is valid before the PATCH call.
%dw 2.0
output application/java
---
if (timezone matches "^[A-Za-z/_-]+$")
timezone
else
error "Invalid timezone format - must be a valid IANA identifier"
It’s not as concise as Terraform’s built-in validation, but it offers the same protection. It’s a good safety net!
It’s so easy to overlook those little details- especially when things are working intermittently. We’ve got about 1200 agents and ran into a similar issue a few months back when integrating with a new HR system.