Yes, that is worth reporting (and raising a ticket).
I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.
Original Message:
Sent: 05-28-2026 21:56
From: Nick Tait
Subject: AuditApi.getAuditsQueryTransactionIdResults() woes
I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:
- Specifying a large pageSize: 500
- Specifying opts: { allowRedirect: true }
- The size of the audit events that would be returned exceeds the threshold (1MB?).
- My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.
It turns out that this is blocked due to CORS restrictions:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.
Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?
Thanks,
Nick.
------------------------------
Nick Tait
Genesys Consultant
------------------------------
Original Message:
Sent: 05-26-2026 17:14
From: Nick Tait
Subject: AuditApi.getAuditsQueryTransactionIdResults() woes
Hi Jerome.
Thanks for your insights.
I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).
I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!
Nick.
------------------------------
Nick Tait
Genesys Consultant
Original Message:
Sent: 05-26-2026 05:43
From: Jerome Saint-Marc
Subject: AuditApi.getAuditsQueryTransactionIdResults() woes
Hello,
- "So I followed the instruction in the error message and added { allowRedirect: true } to the request."
You can also reduce the page size to avoid hitting the limit.
I mean reducing the value of your pageSize parameter (as it appears to be set to the max: 500).
- "Now I see the getAuditsQueryTransactionIdResults is getting a 302 response, but the response doesn't contain a Location header. I'm not sure if the lack of a Location header is the reason, but getAuditsQueryTransactionIdResults is throwing an exception that looks like this: {"id":"83e71391-0d7f-4e54-9fce-b5e4344a3c88","pageSize":500,"cursor":...,"downloadUrl":...}"
I unfortunately couldn't reproduce it in my org as I don't have enough audit events. I mean I don't have enough activity in it to reach the limit.
But yes, if you do not see a Location header in the 302 response, with the Javascript SDK, that is likely the reason why you are getting this exception, with the content of the response body being carried in the error.
At this time, you will have to extract the downloadUrl from the exception (if present - that's a 302) and make a query to that url, or reduce the pageSize and do paging using cursor (to avoid hitting the limit).
- "Should the "GET /api/v2/audits/query/{transactionId}" API be updated to include a Location header when a 302 response is returned?"
It is still worth opening a ticket to request the Location header to be added to the 302 response.
But I can't say if this will be accepted or not. As you wrote in your comment related to the RFC, it it states "The server SHOULD generate a Location header field in the response containing a URI reference for the different URI.", that's not a MUST....
- "Should the (JavaScript) SDK function AuditApi.getAuditsQueryTransactionIdResults be updated so that if a 302 response is received, it automatically follows the redirect (instead of throwing an exception)?"
Unfortunately, there is nothing that can be done in the Javascript SDK in regards to this.
The SDK uses axios as the http client underneath. And in the SDK, Axios will automatically follow a redirect if a 30x reponse is received with a Location header in it (can't be blocked when use in a browser app - only in node.js app). That's what happens with the getOutboundContactlistExport endpoint (GET /api/v2/outbound/contactlists/{contactListId}/export), when download query parameter is set to true.
And a 30x response, if not able to be redirected, will raise an error in axios client.
The reason is also because the Platform API SDKs are automatically generated based on the Platform API Swagger definition (https://api.mypurecloud.com/api/v2/docs/swagger), so it'd be difficult to introduce a specific handling just for this endpoint in the SDK building process.
So it'd be useful if you could open a ticket (on the Platform API) to request the addition of the Location header in that endpoint response.
If this is accepted, it will solve this SDK limitation/constraint.
Otherwise, I'll try to think about what's possible. But I can't promise anything on this.
But at this time, this will modify both success response and error response and for all API endpoints.
I could possibly introduce a global setting as well that only applies to the error/exception (and that doesn't modify success response behavior) - something like apiClient.setReturnExtendedErrorResponses(true)
Regards,
------------------------------
Jerome Saint-Marc
Senior Development Support Engineer