Troubleshooting: authentication
401 Unauthorized
The key was not accepted. The response deliberately does not say why — distinguishing "no such key" from "revoked" from "expired" would let someone probe for valid identifiers.
Check, in order:
The header format. Authorization: ApiKey did_test.abc.xyz — the scheme is ApiKey, not Bearer, and
there is a single space.
Whitespace. A key read from a file or an environment variable often carries a trailing newline. Trim it.
Truncation. Keys are long. A key copied from a terminal that wrapped, or from a field with a length limit, may be short. Check the length against what was issued.
The right key for the right environment. A did_test. key against a Production host fails.
Revocation. If it worked yesterday and not today, ask whoever administers your tenant whether it was rotated.
403 Forbidden
The key is valid; it lacks the scope this operation needs.
The scope is on the operation's reference page, and in the specification as x-diligenceid-scope. Compare it
with what your key carries.
This is not fixed by retrying, and not by a different key format. It needs a key with the scope.
404 on something you know exists
Almost always the wrong environment. A Sandbox key asking for a Production resource gets 404 — not 403, because a 403 would confirm the resource exists.
Check the key prefix. Then check whether the resource was created in the other environment.
400 MissingApiVersionParameter
Management calls need ?api-version=2026-08-30. Product calls do not.
400 UnsupportedApiVersionValue
The version you named is not one this deployment serves. The error message lists the supported versions.
Deliberately distinct from MissingApiVersionParameter: one is a missing parameter, the other is a version
that does not exist here, and they need different fixes.
Nothing above fits
Capture x-ms-request-id from the response and quote it. It identifies the exact request.