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?
2 Answers
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.
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.
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.