Query on Custom RBAC Role for API Metadata Editing in Azure API Center

Hi @Praveen Kumar Kushwaha

Thank you for reaching out to Microsoft Q&A.

Azure API Center uses Azure RBAC for access control; however, based on the currently published Azure API Center resource provider operations, there are no documented RBAC permissions such as Microsoft.ApiCenter/services/apis/metadata/read or Microsoft.ApiCenter/services/apis/metadata/write. API metadata is managed as part of the API resource itself, and Azure API Center documentation does not currently expose separate RBAC actions that distinguish metadata updates from API definition updates. Because of this, granting write permissions on APIs would generally allow modifications to the API resource as a whole, making it difficult to enforce a strict "metadata-only editor" role using Azure RBAC alone. Therefore, the custom role definition shared in the question is unlikely to work because the referenced metadata-specific operations are not documented Azure API Center permissions.

Refer below points to resolve this issue or as a workaround:

1. Metadata-specific RBAC actions do not appear to be available

The following actions are not currently documented Azure API Center resource provider operations:

"Microsoft.ApiCenter/services/apis/metadata/read",
"Microsoft.ApiCenter/services/apis/metadata/write"

Therefore, Azure RBAC cannot validate or grant permissions using these action names. [

2. API write permission may allow broader modifications

To update API properties, users typically require API-level write permissions such as:

1 "Microsoft.ApiCenter/services/apis/write"

However, this permission is not documented as being limited to metadata updates only and may allow changes to other API properties, including API definitions. Therefore, RBAC alone may not provide the level of separation required between metadata management and API definition management.

3. Verify the available API Center operations in your tenant

To confirm the exact operations currently exposed by the Azure API Center resource provider in your environment, run the following command:

PowerShell

Get-AzProviderOperation Microsoft.ApiCenter/* |
Select-Object Operation

Azure CLI

az provider operation show --namespace Microsoft.ApiCenter

Review the output to determine whether Microsoft has introduced granular operations for metadata management that are not yet reflected in public documentation. [learn.microsoft.com]

4. Consider a custom role with API write and delete restrictions

If your objective is to prevent API deletion while still allowing API updates, you can consider a role similar to:

JSON

{
 "Name": "API Center Metadata Editor",
 "Description": "Can read and update APIs in API Center",
 "Actions": [
 "Microsoft.ApiCenter/services/read",
 "Microsoft.ApiCenter/services/apis/read",
 "Microsoft.ApiCenter/services/apis/write"
 ],
 "NotActions": [
 "Microsoft.ApiCenter/services/apis/delete"
 ],
 "AssignableScopes": [
 "/subscriptions/<subscription-id>"
 ]
}

Please note that this approach may still allow broader API modifications and does not guarantee metadata-only access.

5. Recommended workaround – Use governance controls outside RBAC

A common governance approach is to:

• Allow API Product Owners to maintain API metadata in API Center.
• Store OpenAPI specifications in GitHub or Azure DevOps repositories.
• Protect API definitions through:
  • Pull Request approvals
    • Branch protection policies
      • CODEOWNERS
        • CI/CD validation pipelines
        • Use API Center primarily for API inventory, discovery, and metadata governance.

This provides stronger separation between metadata management and API definition management than RBAC currently offers. Azure API Center documentation emphasizes metadata governance, custom metadata, API inventory management, and integration with automation workflows for governance scenarios.

Conclusion

At present, Azure API Center documentation does not show support for a dedicated RBAC role that can update only API metadata while preventing modifications to API definitions. The proposed custom role is therefore unlikely to function as expected because the metadata-specific permissions referenced are not documented API Center operations. The recommended approach is to verify the currently available provider operations and complement RBAC with repository, approval, and CI/CD governance controls