POST /api/v2/analytics/interactions/summary returns 400 invalid_date_range_format on .au instance

General Discussion
1

POST /api/v2/analytics/interactions/summary returns a 400 Bad Request with invalid_date_range_format on the mypurecloud.com.au instance. Trying to pull interaction data for the Sydney compliance queue but the date parser keeps rejecting the window. It’s supposed to handle ISO 8601 natively, yet the request fails when the offset points to +11:00. Switched to UTC+0 and the endpoint actually responds, but the call durations look off by a full hour. Berlin clock says 0400 but the query window expects Sydney time. That breaks the ACMA recording retention checks.

Sorry for the rookie question, still getting used to how the analytics engine handles regional timezones. The latency to the Sydney edge is sitting around 18ms today, which shouldn’t matter for a GET request, but the query builder times out if the window stretches past 72 hours. Logs only show half the payload before cutting off.

2024-06-14T03:22:15Z DEBUG: request sent to analytics-au-prod-01
2024-06-14T03:22:16Z ERROR: 400 {"code":"invalid_date_range_format","message":"end_date must be after start_date...
[connection reset by peer]

The number formatting in the report export also mangles the +61 prefixes when switching to CSV. It drops the leading plus sign and treats the area code as a separate column. The export pipeline is doing jack all with the international dialing format. Don’t know if it’s a regional localization setting or just a bug in the v2.0.88 SDK wrapper. Console shows the queue config is correct, but the data pipeline keeps stripping the dialing prefix. Date validation might be tied to the same regional parser that handles the phone number masking.

2

Problem

The DATE_FORMAT_CONFIGURATION rejects offsets on the .au region. You’ll need to strip the timezone offset before hitting the api integration endpoint.

Code

"interval": "2024-05-01T00:00:00.000Z/2024-05-01T23:59:59.999Z"

Error

Passing +11:00 triggers the 400 invalid_date_range_format parser.

Question

Check the REPORTING_TIMEZONE_SETTING in your tenant config. Usually fixes the drift.

3

platformClient.api.analytics.interactions.summary is still broken after all these years. The suggestion above - stripping the timezone from the interval - works, but it’s ridiculous we have to parse dates ourselves. DateTime.parse() handles offsets fine. It’s always something with the .au region.

4

yeah so stripping the offset’s the way to go - feels kinda dumb, but it works (400). looks like the API’s expecting dates like this:

interval="2024-05-01T00:00:00.000Z/2024-05-01T23:59:59.999Z"

Basically, just give it UTC and let them sort out the timezone - took like 2 hrs to debug that one, honestly (503).