trying to pull the last month of queue performance data for our sydney contact center. the dashboard shows everything fine, but when hitting the /api/v2/analytics/details/queue endpoint with our local au number ranges, it’s throwing a 400 Bad Request with InvalidNumberFormat. looks like backend expects strict US E.164 formatting instead of the standard AU mobile prefix we use daily. acma rules mean we can’t change the trunk normalization, so keeping original dialled digits for audit logs is mandatory.
tenant sits on ap-southeast-2 region, accessing via mypurecloud.com.au. latency between berlin and sydney is doing jack all to the api response time, but payload definitely fails validation on the first request. we’ve tried passing numbers with and without leading zero. also swapped timezone parameter to Australia/Sydney instead of UTC. nothing changes the error code.
- tenant region: ap-southeast-2 (sydney)
- api version: v2 (analytics/details/queue)
- sdk: genesys-cloud-node-sdk v5.2.1
- filter:
interval=PT1H, groupBy=direction, query=queue.id=eq:123456789
- error response:
{"errorCode":"InvalidNumberFormat","message":"The provided phone number does not match the expected E.164 pattern."}
checked architect flow for inbound route. number normalization is set to passthrough. maybe analytics engine strips country code before validation? or is there specific header needed for au data exports? added X-Genesys-Request-Id manually, same result. reporting scheduler in ui also fails with generic DataProcessingException when targeting same queue. export job just times out after 30 seconds anyway.
“filters”: [
{ “dimension”: “fromNumber”, “operator”: “is”, “value”: “+61412345678” }
]
strip the leading zero. e164 doesn't care about local dialing habits. the api rejects `04...` hard. just prepend `+61` and drop that zero. works every time.
The point above is correct about the format, but watch out for rate limits if you’re looping through a bunch of these. the analytics endpoint is strict on burst. cache the token in redis with a 3500s ttl so you’re not re-authing on every retry.
400 Gone. The +61 prefix fix nailed it. Just wanted to add a note on the downstream side since I’m piping this data into Kafka.
When you start streaming those queue details, the schema registry can get cranky if the number format flips between requests. Make sure your connector config has schema.name.source set to something stable, and don’t forget to enable key.converter.schemas.enable=false if you’re just using the raw string. The EventBridge to Kafka bridge expects consistent types. If you send a mixed bag of +61 and 04 numbers, the Avro schema might break or reject the record entirely.
Also, watch the timestamp granularity. The API returns ISO 8601, but Kafka Connect often strips the timezone offset if you don’t configure the timestamp.extractor correctly. Set it to Record or Wall depending on your needs. Defaulting to Wall usually causes drift in the data lake. Keep the TTL low on the cache as mentioned above, but verify the retry backoff is exponential. Linear retries will get you throttled hard by the API gateway.
The 400 error is usually just the parser choking on the local dialing prefix. The endpoint strictly expects E.164, so +614... is mandatory. If you’re building this in Zapier, just add a Formatter step to strip the leading zero and prepend the country code before the API request. Keeps the code clean.