I forked your repo and updated the library project to Net Standard 2.1 and the supporting projects to NET 5.0. After a little bit of .csproj/NuGet work, everything compiled and most of the tests ran. I think that you could update to Net Standard 2.1 without any issues, and it should make it more stable for future use.

Perhaps it is good practice to always stand up a separate Configuration API server instance in each environment. That said, I can imagine some scenarios when developers might want to reuse a single Configuration API server to serve multiple environments (e.g., multiple test environments).

I am requesting that you consider adding an "envName" query parameter to your HTTP Requests that returns the configurations. envName would simply contain the environment name of the client application (which would typically be the same as the environment name of the Configuration API server). You wouldn't need another parameter to AddApiSource -- just use Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") to retrieve the envName and send it along with the request.

This enhancement wouldn't require any additional handling for your ApiSource/ApiProvider, and it wouldn't break any code for developers who are implementing their own Configuration API servers right now. It would give implementers the ability to use a single Configuration API server for multiple client environments, when they might want this.

As a side note, if you decide to add envName as a query parameter, then you may want to make appId a query parameter, also. I wouldn't mind if this broke my code. It is a simple fix.

I just spent some time resolving a stupid issue on my part -- using [FromQuery] rather than [FromRoute] for the appId parameter in my Configuration Api Server. I noticed that when the ApiProvider is optional, the exception-handling essentially ignores errors and silently fails -- which is acceptable and desired behavior for this provider. That said, it can make trouble-shooting a little harder.

I know that this isn't standard practice, but what if the ApiSource/Provider optionally could return some basic config metadata for the source/provider? I was thinking that something like this (at least for the ApiKey approach) would be helpful:

{
    "ConfigurationMetadata": {
        "ApiSource": {
            "ConfigUrlVar": "ConfigurationApiUrl", 
            "AppId": "My.Application.Name",
            "AuthType": "ApiKey",
            "AuthSecretVar": "*******1234",
            "RequestUrl": "https://someDomain:1234/someController/My.Application.Name",
            "ResponseStatusCode": 404
        }
    }
}

If I had some metadata like this, it would have helped me with troubleshooting. Again, I know that it isn't standard practice to return metadata, but it would have been helpful for debugging purposes.

As an alternative, possibly hooking into the logging system and logging this info would be fine, but that might be a little bit harder to implement (and make it work for various scenarios, including automated testing).