Why are Azure API Management subscription keys now returned as null?

September 27, 2026 2 answers
Asked by MellowCedar47
I have an older integration that calls an API Management instance using a SAS token and subscription identifier. It previously retrieved the subscription's primary and secondary keys, but the same request now returns both values as null: GET /subscriptions/XXX?api-version=2014-02-14-preview The subscription itself is active, and this integration has not been changed in roughly three years. I also tried a newer API version, including a 2022 version, but saw the same behavior. I know there is an update or key-management approach that may work, but I'm hoping to avoid changing the existing service immediately. Has API Management changed how subscription keys are exposed, and is there a read operation that should be used instead?

Answers

OrbitingPine8
This is likely an intentional security change rather than a problem with the subscription. Standard get or list operations generally should not return secret keys, because anyone with a reader-level role could otherwise retrieve them. Use the subscription secrets operation, such as the API Management โ€œList secretsโ€ endpoint, to retrieve the primary and secondary keys. You should also move away from the 2014 preview API version when updating the integration.

MellowCedar47: That makes sense. This integration has been untouched for about three years, so the change was surprising, but Iโ€™ll look at the secrets operation and plan to update the old API usage.

Reply to this answer
SilverMaple22
The 2014 preview API version is extremely old and is not a good choice for production integrations. Test the equivalent request with a current supported API version, but keep in mind that newer versions may still intentionally return null for secret fields. The supported solution is to use the dedicated operation for listing subscription secrets rather than relying on the normal subscription details response.
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions