Pushing a new Interactive Report to mypurecloud.com.au and the query builder just barfs when filtering by the ACMA recording timestamp. The data source is the Sydney edge, so the UTC+10 offset is clashing with the date range picker. Running platform v2024.3.1. The error payload is a 422 Unprocessable Entity. Compliance audit is looming and this report is doing jack all.
{
"code": "bad_request",
"message": "Invalid date format for ACMA compliance metadata filter",
"details": "Timestamp mismatch between query scope and Sydney edge timezone"
}
The ACMA timestamp field in the Analytics API expects strict ISO 8601 format, but the Interactive Report builder often mangles the timezone offset when dealing with non-UTC edges like Sydney. The 422 error usually means the date string isn’t parsing correctly on the backend.
You can bypass the UI builder entirely by constructing the request body manually. This gives you control over the exact JSON structure sent to /api/v2/analytics/conversations/aggregates. Make sure to use acma_recording_timestamp as the dimension and format the interval explicitly in UTC.
Here is a working Node.js example using the PureCloud SDK. Note the explicit date formatting to avoid the timezone clash.
const platformClient = require('@genesyscloud/platform-client-sdk');
const settings = require('./settings'); // Your OAuth settings
async function getAcmaReport() {
const analyticsClient = platformClient.AnalyticsApi;
// Define the body manually to ensure correct date formatting
const body = {
"interval": "P1D", // Daily interval
"dateFrom": "2024-01-01T00:00:00.000Z", // Explicit UTC
"dateTo": "2024-01-02T00:00:00.000Z", // Explicit UTC
"dimensions": [
"acma_recording_timestamp"
],
"metrics": [
"conversationCount"
],
"entityId": "all", // Or specific queue ID
"groupBy": [
"acma_recording_timestamp"
],
"select": [
"acma_recording_timestamp",
"conversationCount"
]
};
try {
const response = await analyticsClient.postAnalyticsConversationsAggregates(body, {
xGcIuDebugLabel: "ACMA_Report_Debug"
});
console.log("Report data:", response.body);
} catch (error) {
console.error("Failed to fetch report:", error.body);
}
}
getAcmaReport();
If you must use the UI, try setting the date range to a very narrow window first. Sometimes the builder fails on large date spans with the ACMA dimension due to cardinality limits. Also check that your OAuth client has the analytics:report:read scope.
The error payload you posted got cut off. If it mentions cardinalityExceeded, you’ll need to add a filter for a specific queue or user to reduce the dataset size before the timestamp dimension can be applied.