Usage of Singleton HTTPClient in server to server commutation for complex scenario

Hello!

Thank you very much for your answer.

From your response, I understand that you recommend to use the IHttpClientFactory.

Since I'm newbie in .Net core, I need some best practices as long with code example on how to implement the following scenario:

ServiceA - calling the endpoints from Adomain.com with static Bearer token authorization

ServiceB - calling the endpoints Bdomain.org with static Bearer token authorization

ServiceC - calling the endpoints Cdomain.org with static Bearer token authorization

ServiceD- - calling the endpoints from Ddomain with header x-api-key

ServiceE- - calling the endpoints from Edomain with no authetication

For example:

1. Should we have a typed client per each service?
2. For the services A,B,C that have the same type of authorization can I use same typed or named client?
3. Can I "reuse" a typed or named client for multiple services and changed the http client configuration within the constructor of these services?

Can you please guide me with some skeleton code for implementing the above?

I'm a interesting on how to configure the http client for them and how to register them in the Program.cs using dependency injection.

I'll look forward for your suggestions.

Best regards,

Florin

Thank you for reaching out.

Recommended Approach: Use IHttpClientFactory with Typed Clients

In .NET Core, when calling multiple external services with different base URLs and authentication, the best practice is to use IHttpClientFactory with a typed client for each service. This pattern is strongly recommended by Microsoft because it:

Provides configuration isolation (each service has its own base URL, headers, SSL settings).

Prevents header and token leakage between services.

Manages connection pooling and DNS updates automatically, avoiding socket exhaustion.

Makes your code more testable, maintainable, and scalable.

Answering Your Questions

Typed client per service?\ Yes. Each external API (ServiceA, ServiceB, etc.) should have its own typed client. This encapsulates configuration and avoids cross-contamination.

Same type of auth across A, B, C — can I reuse one client?\ No. Even if they all use Bearer tokens, each has a different base URL and token. Sharing one client risks mistakes and isn’t thread-safe.

Can I reconfigure a client at runtime?\ Avoid this. The injected HttpClient should be treated as pre-configured. If you need dynamic information (e.g., user-specific tokens), add them per request with HttpRequestMessage, not by mutating default headers.

Example Skeleton

Program.cs registration (keep all config here):

builder
{
    
    
        
}
builder
{
    
    
        
}
builder
{
    
    
        
}
builder
{
    
    
}
builder
{
    
    
}

Typed client class:

public
{
    
    
    
    
        httpClient
    
    
    
        
    
}

Repeat similar classes for ServiceB, ServiceC, etc.

Important Best Practices

Do not inject typed clients into singleton services → Typed clients are transient; capturing them in a singleton prevents DNS refresh and can cause stale connections.

Use interfaces for better testability → e.g. AddHttpClient() makes it easier to mock in unit tests.

Handler pooling → Under the hood, IHttpClientFactory reuses HttpMessageHandler instances with a default 2-minute lifetime, which prevents socket exhaustion while respecting DNS changes.

Dynamic headers → Add them per request (HttpRequestMessage) instead of setting them globally on the injected client.

In summary: create one typed client per service, configure each in Program.cs, inject where needed, and let IHttpClientFactory handle connection pooling and lifetimes for you. This is the safest, cleanest, and most future-proof solution.

Let me know if you need any further help with this. We'll be happy to assist.

If you find this helpful, please mark this as answered.

Hi!

From your answer, I understood that I should use typed clients.

My concerns are related with increased number of typed clients that I should implement, that will share similar code.

Another aspect, is related with the code that you've shared.

It seems for me that something is missing. Is it possible to give me example of typed client code for services A,B, C ?

Thank you for reaching out.

In .NET Core, when calling multiple external services with different base URLs and authentication, the best practice is to use IHttpClientFactory with a typed client for each service. This pattern is strongly recommended by Microsoft because it:

Provides configuration isolation (each service has its own base URL, headers, SSL settings).

Prevents header and token leakage between services.

Manages connection pooling and DNS updates automatically, avoiding socket exhaustion.

Makes your code more testable, maintainable, and scalable.

Answering Your Questions

Typed client per service?\ Yes. Each external API (ServiceA, ServiceB, etc.) should have its own typed client. This encapsulates configuration and avoids cross-contamination.

Same type of auth across A, B, C — can I reuse one client?\ No. Even if they all use Bearer tokens, each has a different base URL and token. Sharing one client risks mistakes and isn’t thread-safe.

Can I reconfigure a client at runtime?\ Avoid this. The injected HttpClient should be treated as pre-configured. If you need dynamic information (e.g., user-specific tokens), add them per request with HttpRequestMessage, not by mutating default headers.

Reducing Duplication (Best Practices)

If you want to avoid too much boilerplate, you can combine typed clients with other patterns:

1. Base class for shared logic

Put common GetAsync/PostAsync helpers in a BaseApiClient.\ Each service client inherits it and only defines the service-specific endpoints.

public abstract class BaseApiClient

public abstract class BaseApiClient
{
    protected readonly HttpClient _httpClient;

    protected BaseApiClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    protected async Task<T> GetAsync<T>(string endpoint)
    {
        var response = await _httpClient.GetAsync(endpoint);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadFromJsonAsync<T>();
    }
}

public class ServiceAClient : BaseApiClient
{
    public ServiceAClient(HttpClient httpClient) : base(httpClient) { }
    public Task<User> GetUserAsync(int id) => GetAsync<User>($"/api/users/{id}");
}

public class ServiceBClient : BaseApiClient
{
    public ServiceBClient(HttpClient httpClient) : base(httpClient) { }
    public Task<Product> GetProductAsync(string id) => GetAsync<Product>($"/api/products/{id}");
}

This way, you don’t duplicate HTTP handling code — only the API-specific methods.

2. Interfaces for testability

You can register clients against interfaces, e.g. IServiceAClient, IServiceBClient.\ This makes mocking and unit testing much easier.

public interface IServiceAClient
{
    Task<User> GetUserAsync(int id);
}

public class ServiceAClient : BaseApiClient, IServiceAClient
{
    public ServiceAClient(HttpClient httpClient) : base(httpClient) { }
    public Task<User> GetUserAsync(int id) => GetAsync<User>($"/api/users/{id}");
}

// Program.cs
builder.Services.AddHttpClient<IServiceAClient, ServiceAClient>(client =>
{
    client.BaseAddress = new Uri("https://Adomain.com/");
    client.DefaultRequestHeaders.Authorization =
        new AuthenticationHeaderValue("Bearer", "TOKEN_A");
});

Your controller can now depend on IServiceAClient instead of the concrete class, which is cleaner and test-friendly.

Final Guidance

Typed clients per service = best practice. Don’t merge multiple APIs into one client.

If worried about boilerplate:

• Put shared HTTP logic into a base class.
• Use interfaces to keep things testable.

Don’t fear the number of classes — each is small, focused, and easier to reason about.

Reference:

• Use the IHttpClientFactory - .NET Make HTTP requests using IHttpClientFactory in ASP.NET Core
• Use IHttpClientFactory to implement resilient HTTP requests [free.blessedness.top], [free.blessedness.top], [free.blessedness.top]
• Interfaces - define behavior for multiple types - C#
• Best practices for writing unit tests - .NET [free.blessedness.top], [free.blessedness.top]

Let me know if you need any further help with this. We'll be happy to assist.

If you find this helpful, please mark this as answered.

Hope you're doing well. Could you please let us know if the issue still persists or if it has been resolved? If everything is working fine now, we’d appreciate it if you could mark the response as answered. We’re planning to close the thread by 21 October, so we are hoping for your reply before that.