DiligenceID Developers
GitHub

.NET SDK authentication

using DiligenceID;

var credential = new DiligenceApiKeyCredential(apiKey);

var management = DiligenceClients.CreateManagement(
    new Uri("https://api.example.diligence.id"), credential);

var product = DiligenceClients.CreateProduct(
    new Uri("https://api.example.diligence.id"), credential);

One credential, both clients, one service root — the clients carry their own path prefix, so moving between sandbox and production is one URL change.

Where the key comes from

Your secret store. The credential deliberately does not read from a file, an environment variable or a configuration provider: your application knows what its secret store is and the SDK cannot.

var apiKey = configuration["DiligenceID:ApiKey"]
    ?? throw new InvalidOperationException("DiligenceID API key is not configured.");

Never hard-code it or commit it.

Assert the environment at startup

if (!credential.IsSandbox)
{
    throw new InvalidOperationException("Refusing to run integration tests against production.");
}

IsSandbox reads the key's own prefix, so an application cannot believe it is talking to Sandbox while holding a Production key.

The key never reaches a log

ToString() returns DiligenceApiKeyCredential(sandbox). Interpolating the credential into a log message — the most common way a secret escapes — discloses nothing.

The credential is held in memory only. Nothing is written to disk or to any store.

Supplying your own HttpClient

var management = DiligenceClients.CreateManagement(endpoint, credential, httpClientFactory.CreateClient("diligence"));

Use this to apply the handlers, retry policies or proxy configuration your application already has. Note that a retry of a mutating call needs an Idempotency-Key to be safe.

Edit this page on GitHub