Get Azure API Management Git Credentials using PowerShell

One of the many great features of Azure API Management is the fact that it has a built in Git repository for storing the current configuration as well as publishing new configurations.


This allows you to push updated Azure API Management configurations to this internal Git repository as a new branch and then Deploy the configuration to API Management.

The internal Git repository in Azure API Management is not intended to be used for a normal development workflow. You’ll still want to develop and store your Azure API management configuration in an external Git repository such as GitHub or TFS/VSTS and then copy configuration updates to the internal Git repository in Azure API Management using some sort of automated process (e.g. Continuous Integration/Continuous Delivery could be adopted for this).

The Internal Git Repository

To access the Internal Git Repository requires short lived (30 days maximum) Git credentials to be generated. This is fairly easy through the Azure API Management portal:


Unfortunately using the portal to get these credentials is a manual process and so would not be so good for an automated delivery process (e.g. CI/CD). You’d need to update these Git credentials in your CI/CD automation system every time they expired (every 30 days).

Get Git Credentials

A better approach to generating the Git Credentials is to use Azure PowerShell API Management cmdlets connected with a Service Principal to generate the Git credentials whenever you need them in your CI/CD pipeline.

This is not a completely straightforward process right now (which is unusual for the Azure PowerShell team), so I’ve created a simple PowerShell script that will take care of the nuts and bolts for you.


To run this script you’ll need:

  1. PowerShell 5 (WMF 5.0) or greater.
  2. Azure PowerShell Modules installed (make sure you’ve got the latest versions – 4.0.3 at the time of writing this).

You’ll also need to supply the following parameters to the script:

  1. The Azure Subscription Id of the subscription containing the API Management instance.
  2. The name of the Resource Group where the API Management instance is installed to.
  3. The service name of the API Management instance.

You can also optionally supply which of the two internal API Management keys, primary or secondary, to use to generate the credential and also the length of time that the Git credential will be valid for (up to 30 days).


Download the Script

  1. Download the script Get-AzureRMApiManagementGitCredential.ps1 using the PowerShell command:
  2. Unblock the script using the PowerShell command:

Using the Script

  1. Use the Login-AzureRMAccount cmdlet to authenticate to Azure. This would normally be done using a Service Principal if using an automated process, but could be done interactively when testing.
  2. Execute the script providing the SubscriptionId, ResourceGroup and ServiceName parameters (and optionally the KeyType and ExpiryTimespan) using the following PowerShell command:


The script will return an object containing the properties GitUsername and GitPassword that can be provided to Git when cloning the internal Git repository.

The GitPassword is not escaped so can not be directly used within a Git Clone URL without replacing any / or @ with %2F and %40 respectively.

In the example above I generated an internal Git Credential using the Primary Secret Key that will expire in 4 hours.

Typically you’d assign the output of this script to a variable and use the properties to generate the URL to pass into the Git Clone. For example:



  • When cloning the internal Git Repository you’ll need the clone URL of the repository. This is always the name of your Azure API Management instance followed by with appended to it E.g.
  • Once you’ve uploaded a new Git branch containing a new or updated Azure API Management configuration you’ll need to use the Publish-AzureRmApiManagementTenantGitConfiguration cmdlet to tell Azure API Management to publish the configuration contained in the branch. I have not detailed this process here, but if there is interest I can cover the entire end-to-end process.
  • The Primary and Secondary Secret Keys that are used to generate the internal Git Credential can be re-generated (rolled) individually if a Git credential is compromised. However, this will invalidate all Git Credentials generated using that Secret Key.

The Script

If you wish to review the script itself, here it is:

So, hopefully that will be enough information to get anyone else started on building a CI/CD pipeline for deploying Azure API Management configurations.



11 thoughts on “Get Azure API Management Git Credentials using PowerShell

  1. Erik says:

    Excellent post, thank you!

    I’ve experimented with running your PowerShell script as part of a VSTO build and using the output to set up a remote repo to the local repository that VSTO creates as part of the build process. The VSTO repo is cloned from my production environment, and I’m now trying to push that configuration to a DEV environment.

    Something like:

    cd $(Build.SourcesDirectory)
    $ApimPassword = [uri]::EscapeDataString($env:gitPassword)
    $ApimRepoUrl = “https://apim:$($ApimPassword)@$($ApimRepoUrl)”
    git push –force $ApimRepoUrl HEAD:integrationbranch

    But git doesn’t really like this 🙂

    Would be really interested in seeing your end-to-end solution.


      • Erik says:

        Awesome, thank you! So basically you clone the repo onto the agent machine, copy files locally from the VSTS repo to the APIM Git repo and then push those changes back.

        That was basically my Plan B, I just thought it could be accomplished in a simpler way by adding the APIM git repo as a remote to the VSTS repo and force pushing the VSTS repo onto the APIM one. I guess your approach is more in line with recommended usage of GIT anyway 🙂

        Anyway, I’ve integrated your solution into my release pipeline and it seems to work great. Next step is to move all the configuration that varies between instances into named values / properties and deploy those with an ARM template.

        Thanks again,

        Liked by 1 person

  2. You definitely could do it with your Plan A – but we went with Plan B because we have a multi-stage pipeline and it gave us the ability to “package” up the release into an artifact that we could then publish to the APIM in the release stages. E.g. We’d produce the artifact in the Build process and then in the release process we’d first publish the APIM config to our test APIM and execute tests on it – if they pass we’d repeat on our PROD APIM.

    Really glad I’ve been able to help! I will document this process up fully as soon as I’ve got the time!



  3. Shaun Titus says:

    Hi Daniel, thanks for this very helpful piece of code. The only issue I had with it is related to time zones. It appears that the $expiry is in local time zone but the credential is created in UTC. Since I’m in -07 my keys were all instantly expired! I was able to make this change and it worked:

    (Get-Date).touniversaltime() + $ExpiryTimespan

    I tested with a 2 minute expiry time span and it worked as expected.

    Thanks again for sharing!


    Liked by 1 person

    • Good catch Shaun – thank you for sharing! You’d be quite correct! Hopefully Microsoft will implement a cmdlet this for at some point. Although they are encouraging people to move away from using SCM to configure APIM. So they might not…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s