TL;DR: The key is fine - it just does not belong to the endpoint you are calling. Document Intelligence keys are region- and resource-scoped, so a key from one region's resource 401s against another region's endpoint every time. Open the resource in the portal, copy the endpoint shown there, and call that exact host.

```text
Invalid subscription key
```

1. In the Azure portal, open your Document Intelligence resource and go to Keys and Endpoint.
   Expected: one endpoint host and two keys; note the region embedded in the host name.
2. Compare that host against the URL your code calls.
   Expected: they differ - that mismatch is the whole bug.
3. Send a test request to the portal's endpoint with the portal's key, passing the key in the Ocp-Apim-Subscription-Key header.
   Expected: 202 Accepted (or 200) instead of 401.
4. Update your config to the portal endpoint and key pair, then re-run.
   Expected: 401s stop across the board.
5. If they already match, regenerate key 2 in the portal and switch to it - the stored key may be stale from a rotation.
   Expected: the fresh key authenticates.

## Use this when
- API calls return 401 "Invalid subscription key" but the portal's test console works
- you recently recreated the resource or moved regions
- the code worked until someone rotated keys

## Not for this skill when
- the error is 403 (that is firewall, VNet, or RBAC - not the key)
- you are using Microsoft Entra auth (no subscription key involved)
- every Azure service 401s (check the app's credential store instead)

## Variant phrasings
### azure document intelligence invalid subscription key 401
### form recognizer key works in portal not in code
### Ocp-Apim-Subscription-Key invalid but correct

## Why it happens
The 401 comes from the API Management gateway in front of your resource, which only accepts keys issued for that resource. The portal test console calls the right endpoint automatically, so the key "works" there while your code aims at a different region or an old resource - often after a resource was recreated and the config was never updated.

## Edge cases
- Multi-service Cognitive Services keys vs single-service Document Intelligence resources have different valid endpoints; keep the pair from the same resource blade.
- Sovereign clouds use different endpoint suffixes - a global Azure key never works there.
- Proxies sometimes strip custom headers; if curl works but your app 401s, inspect the outgoing headers.
- Key 1 vs key 2: rotating one while code uses the other is fine, but make sure you know which is live.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nIm1Svr2k6FWHznqUQSBrw