Unexpected Namespace Qualification and Missing Usage Examples in .NET SDK v2.8.0

[frankdn-eye]

Hi WorkOS Team,

I've encountered a couple of issues while integrating the WorkOS.net v2.8.0 SDK into my .NET 8 Web API project and wanted to bring them to your attention.

1. Unexpected Namespace Qualification:

It appears there's an unexpected namespace qualification due to naming both the namespace and the static class the same (WorkOS). This leads to redundant and somewhat confusing code when using the SDK from a namespace other than WorkOS.

For example:

namespace NotWorkOS
{
    class MyClass
    {
        void MyMethod()
        {
           WorkOS.WorkOS.SetApiKey("SECRET_KEY"); // Requires double qualification
        }
    }
}

I believe this double qualification is not ideal and could be confusing for developers adopting the SDK, especially as it's not mentioned in the current documentation. It might be worth considering renaming either the namespace or the static class to avoid this collision, or make this clear in the documentation.

2. Missing Usage Examples for Not Implemented Services and API Request Methods

I've noticed a lack of clear implementation examples for services that appear to be not fully implemented in the SDK (like UserManagement). The documentation primarily showcases cURL calls, which made me explore the generic API request methods.

Furthermore, I'm struggling to understand how to effectively use them:

• WorkOSClient.MakeAPIRequest<T>

• WorkOSClient.MakeRawAPIRequest

The IntelliSense indicates that these methods accept a WorkOSRequest object as a parameter, which in turn requires an Option of type BaseOptions. However, the definition of BaseOptions is simply:

/// <summary>
/// A base class to represent request options to the WorkOS API.
/// </summary>
public class BaseOptions
{
}

This lack of concrete examples and the seemingly empty BaseOptions class leaves me confused about how to construct and use these powerful API request methods for custom interactions or accessing services that are not yet fully implemented in the SDK.

Questions:

• Is the double namespace qualification (WorkOS.WorkOS) intentional? If not, are there plans to address this in a future release?

• Are there any plans to provide more comprehensive examples for using services that are not yet fully implemented within the .NET SDK?

• Could you provide examples of how to properly construct and use WorkOSClient.MakeAPIRequest<T> and WorkOSClient.MakeRawAPIRequest, specifically detailing how to create the necessary WorkOSRequest with the appropriate Option?

• Does the current structure imply that the default WorkOSClient is not intended for general API interactions, and we should instead rely on a custom HttpClient for accessing services that are not yet fully implemented?

Understanding these points would greatly assist in the adoption and effective use of the WorkOS .NET SDK.
Thank you for your time and attention to these issues.

[frankdn-eye]

FYI - I am using the BaseOptions with inheritance.
I create my request object and inherit from BaseOptions.

public class WorkOSUser : BaseOptions {
    ....
}