Studio REST Proxy 422 on /api/v2/analytics/conversations/details date format

General Discussion
1

{“code”: 422, “message”: “Invalid date range format for analytics query”}
Step one: the Studio SNIPPET builds a dynamic window using {{interaction.startTime}} and pipes it into REST Proxy at /api/v2/analytics/conversations/details. Step two: the trace log shows a clean JSON body, yet the proxy returns that 422 anyway. Tenant clock is locked to Europe/London. Backend SDK sits at 8.4.2. The dateFrom string definitely matches ISO 8601 when dumped to console. Proxy doesn’t parse it.

2

The 422 is almost certainly a timezone handling issue on the backend. Genesys Cloud’s analytics API is notoriously strict about date formats and expects explicit UTC offsets. If you’re just passing {{interaction.startTime}} directly, you might be sending local time or a format without the ‘Z’ suffix, which the parser rejects as ambiguous.

The dateFrom and dateTo parameters need to be in strict ISO 8601 format with a ‘Z’ suffix to indicate UTC. Since your tenant clock is set to Europe/London, you need to ensure the conversion happens before hitting the endpoint. The Studio interaction object usually provides timestamps in UTC, but sometimes the serialization drops the offset.

Here’s how to force the correct format in your REST Proxy configuration. You should construct the date string explicitly in the Studio expression to guarantee the ‘Z’ is present:

// Studio Expression for dateFrom
new Date(Date.parse({{interaction.startTime}})).toISOString()

Then, in your JSON body for the /api/v2/analytics/conversations/details call, map it like this:

{
 "dateFrom": "{{dateFromISO}}",
 "dateTo": "{{dateToISO}}",
 "groupBy": ["queueId"],
 "metrics": {
 "conversations": {
 "total": {
 "type": "COUNT"
 }
 }
 }
}

Make sure your integration has the analytics:query scope. Without it, you’ll get auth errors, but with bad dates, you get 422s. Also, check that the time range isn’t exceeding the retention policy limits for your organization. If you’re querying real-time data, consider using the summary endpoint instead, as it handles time windows more gracefully. The details endpoint is heavy and often fails on malformed ranges.