Your first call

Once your key is active, read your profile. It is the simplest call, and it tells you what your application may do.

With the .NET SDK

builder.Services
    .AddAnisPartners(options => options.Authority = new Uri("https://<the address Anis gave you>"))
    .WithSigner(EcdsaP256Signer.FromPemFile("/secure/partner-key.pem", keyId));

// later, from the container:
var profile = await anis.Profile.GetAsync(ct);
Console.WriteLine(string.Join(", ", profile.Application!.Scopes));

See the .NET SDK page for settings files, key custody and the rest of the client.

Use the latest SDK, 2.2.0

Anis does not sign the answer to your profile read — nor the other information calls (wallets, catalogue, owned cards) — and the SDK reads those answers as they are. SDK 1.x is deprecated: it cannot verify the answers Anis signs today. Install 2.2.0 in every language; 2.0.1 is the oldest version that still verifies them.

What comes back

Read your profile returns your partner and application ids, the Anis business account you act for, and the permissions your application has right now. Permissions come from your application’s live policy and are checked on every call — a change by Anis staff applies to your next request, not your next restart — so read them rather than caching them.

When a call is refused

Every refusal carries a code and a link to its page in Error codes. The first ones you may meet:

Code	Usually means
`invalid_credentials`	The key id, the key file, the clock or the address you call is wrong — or the key is not active (not yet, or no longer)
`malformed_signed_request`	Your signer builds the request wrongly: a signature header, the signed parts or their order, or the `Content-Digest`. It says nothing about your key
`insufficient_scope`	A missing permission, or a call from outside your allowed networks. Read your profile from the same host: if it answers, your network is fine — compare the permissions it lists with the one the call needs; if it is refused the same way, it is the network (or the application lacks `profile:read`)

Check your signature

If a signature will not verify, ask Anis what it saw: Check your signature runs your call through all of Anis’s checks, changes nothing, and reports the method, address, path and query it signed over, the key it found and the permissions in force. It needs the diagnostics:use permission.

var seen = await anis.Diagnostics.CheckSignatureAsync(ct);
Console.WriteLine($"{seen.Method} {seen.Authority}{seen.Path} ?{seen.CanonicalQuery} key {seen.KeyId}");

What the self-check answers tells you where to look:

The self-check	What it means
Succeeds	Your key, its state, your clock, the address and your network are fine. The failing call’s own path, query or body is the problem: compare that call’s signature base with the signing test vectors. If that call is refused as `insufficient_scope`, compare the permissions the self-check lists with the one the call needs.
Is refused as `malformed_signed_request`	Your signer builds requests wrongly: a signature header, the signed parts or their order, the `nonce` parameter, or the `Content-Digest` — the self-check sends exactly `{}`. Anis decides this before it looks at any key, so it says nothing about your key.
Is refused as `invalid_credentials`	The key id or key file, the key’s state, your clock, the signature form — or the address: call exactly the address Anis gave you. Work through the 401 checklist.
Is refused as `insufficient_scope`	You call from outside your allowed networks, or your application lacks `diagnostics:use`. Read your profile from the same host: if it answers, your network is fine — check that it lists `diagnostics:use`; if it is refused the same way, it is the network (or the application also lacks `profile:read`). Ask Anis staff to change either.

If nothing changed on your side

If the self-check is refused as invalid_credentials, the 401 checklist finds nothing and nothing changed on your side, your access may be paused: write to support@anis.ly with the requestId of the refused call.