Bug: Rate limit headers are corrupted as "System.String[]" in ApiResponse

[jecar]

Bug Report: Rate limit headers are corrupted as "System.String[]" in ApiResponse

Description

When using the *WithHttpInfo variants of the API methods (for example GetEmailEventReportWithHttpInfo or SendTransacEmailWithHttpInfo), the HTTP headers returned in the ApiResponse<T> object are incorrectly serialized.

Instead of receiving the actual header values (like "100" for a remaining limit), the dictionary values are set to the literal string "System.String[]".

Environment

• SDK: brevo-csharp
• Version: Latest (Commit 5cc0753)
• Platform: .NET / C#

Root Cause Analysis

In the generated API classes (e.g., TransactionalEmailsApi.cs), the response headers are mapped to the ApiResponse dictionary using a .ToString() call on the header value.

In recent versions of the underlying HTTP client (RestSharp), headers are stored as IEnumerable<string>. In .NET, calling .ToString() on an enumerable returns the name of the type ("System.String[]") instead of its first element.

Buggy code identified (around line 2576 and 4317):

localVarResponse.Headers.ToDictionary(x => x.Key, x => x.Value.ToString())

Steps to Reproduce

1. Execute an API call using a WithHttpInfo method.
2. Access any rate-limit header in the response:

var response = apiInstance.GetEmailEventReportWithHttpInfo(...);
var remaining = response.Headers["x-sib-ratelimit-remaining"];
Console.WriteLine(remaining); // Outputs: "System.String[]"

3. Attempting to parse this value as an integer will fail.

Suggested Fix

The mapping logic should be updated to extract the first element of the header collection instead of calling .ToString() on the collection itself.

Proposed Correction:

localVarResponse.Headers.ToDictionary(
    x => x.Key, 
    x => System.Linq.Enumerable.FirstOrDefault(x.Value) ?? string.Empty
)

Impact

This issue prevents developers from implementing proper client-side throttling and monitoring. Since headers are the only way to track remaining quotas per endpoint (as per Brevo documentation), this bug forces developers to bypass the SDK and use manual HttpClient implementations to get accurate rate-limiting data.

---

Note: This bug likely affects all API classes generated with the same template.