Hello,
Yes, there is a problem with the .Net SDK. But the resolution is possibly not what you expect/think of.
And you can already implement the proper handling without having to wait for this fix.
Some explanations below.
1) Platform API SDKs
That's also what the API Explorer is using to display the available API Endpoints, their supported parameters, input contracts, and reponse contracts.
On success (HTTP 2xx status), the Platform API responses are expected to contain a JSON body (JSON response content - Content-Type: application/json). The SDK takes the JSON response body and deserializes it to the class/model defined in the Platform API Swagger definition.
2) Download endpoint
The GET /api/v2/downloads/{downloadId} endpoint (GetDownload method in the .Net SDK) is one of the few endpoints which can answer with a 2xx HTTP status or with a 3xx HTTP Status (i.e. Redirect).
As a matter of fact, downloading a document/content, based on the downloadId value, is a two-step process.
First step - The purpose of the GET /api/v2/downloads/{downloadId} is to provide a download url (new/different) where the document/content is available.
Second step - You can then query the provided download url to get access to the document/content. It is not a Public API/Platform API url - the file is located on a different server. The request will not leverage the Genesys Cloud access token, but one which is provided in the download url.
If you invoke GET /api/v2/downloads/{downloadId} endpoint with issueRedirect = false (query parameter), the server will answer with a 200 OK and a response body that matches the "UrlResponse" model (which contains the download url).
If you invoke GET /api/v2/downloads/{downloadId} endpoint with issueRedirect = true, or with no issueRedirect parameter (query parameter), the server will answer with a 303 See Other and the download url will be available as a Response header, named "Location".
3) The issue in the .Net SDK
The problem is that the HTTP Client, used in the SDK, currently automatically processes a 3xx Response, issuing a consecutive GET request to the url provided as Response Location Header.
As the retrieved document is not a JSON content, corresponding to the "UrlResponse" model, this is causing a deserialization error when you are calling GetDownload(downloadId, null, null, null) or GetDownload(downloadId, null, true, null) (the third method parameter corresponds to the issueRedirect - null for unset, or true).
The reason why you are seeing the final content (document) when using API Explorer, is because it is automatically processing the 303 HTTP status and making a request to the provided download url. As there is no deserialization involved here, The API Explorer (web browser) can do it without raising an error.
So the .Net SDK fix will consist in preventing the SDK Http Client from automatically processing a Redirect. On 3xx, the SDK will raise an Exception to let the developer catch it and access the Location Header (download url) from the HTTP response.
To get access to the document, it will be necessary to make a new HTTP request to the downloadUrl to access it and download its content.
The GetDownload method will not perform the 2 steps - only the first one to get the download url.
4) Possible now
What that also means is that you don't need to wait for the fix to implement this in your code.
Call GetDownload(downloadId, null, false, null) so that the issueRedirect is set to false.
As explained above, the server will answer with a 200 OK status and a response body containing the "UrlResponse" json content.
You will not get a deserialization error.
But you will then need to make a second HTTP Request to get the file content.
Unfortunately, the SDK HTTP Client cannot be used for this - it is initialized with the api url (e.g. api.mypurecloud.com). And the file is hosted on a different server.
You can use something like below, using System.Net.Http.HttpClient to retrieve it.
See below for a simple example.
// string downloadId
string downloadFilename = "myfile.png";
UrlResponse urlResponse = apiInstance.GetDownload(downloadId, null, false, null);
string downloadUrl = urlResponse.Url;
// Using System.Net.Http
var httpClient = new HttpClient();
// Send the GET request to the download url
HttpResponseMessage httpResponse;
try
{
httpResponse = httpClient
.GetAsync(downloadUrl)
.ConfigureAwait(false)
.GetAwaiter()
.GetResult();
int statusCode = (int)httpResponse.StatusCode;
if (statusCode >= 400 || statusCode == 0)
{
Console.WriteLine("Error status getting download content: {0}", statusCode);
} else {
// Successful Response - Read the response content
try
{
var responseBodyByteArray = httpResponse.Content
.ReadAsByteArrayAsync()
.ConfigureAwait(false)
.GetAwaiter()
.GetResult();
// Write byte array to a file.
System.IO.File.WriteAllBytes(downloadFilename, responseBodyByteArray);
}
catch (Exception ex)
{
Console.WriteLine("Error reading download content");
}
}
}
catch (Exception ex)
{
Console.WriteLine("Error getting download content");
}
With the fix we are planning in the SDK, it would be similar if you call GetDownload(downloadId, null, false, null).
And if someone's forget to set the issueRedirect to false (not setting it or setting it to true), this will raise an ApiException.
In the catch of that exception, one would check the ex.ErrorCode to see if it is a 3xx (ex.ErrorCode >= 300 && ex.ErrorCode < 400) and would retrieve the download url from the Location Header (ex.Headers["Location]).
It would then be necessary to make a second HTTP Request to the download url, using System.Net.Http.HttpClient or another HTTP client.
Hope this clarifies.
We'll start working on the fix shortly.
Regards,
Original Message:
Sent: 02-18-2026 15:15
From: Matthew Raleigh
Subject: UrlResponse Possible Bug
In the API Explorer, the response for the /api/v2/conversations/emails/{conversationId}/messages endpoint contains attachment info for the email objects it returns:
The contentUri gives a URL that the attachment can be retrieved from, using the Downloads endpoint /api/v2/downloads/{downloadId}.
When executing the example code given for the .NET SDK in the API Explorer for this endpoint, it fails with the following deserialization exception:
Sending a test request to that endpoint within the API Explorer succeeds, with the following response:
Since the code for this SDK is open source, I can see here that the Downloads API attempts to deserialize the response from that endpoint into the UrlResponse model, which unfortunately will not work, as the actual API response does not match the UrlResponse model:
This seems like a bug within the .NET SDK. Can you confirm this? Have any of your other customers ran into this issue?
#PlatformSDK
------------------------------
Matthew Raleigh
Principal PS Consultant - Genesys Cloud
------------------------------