Need to migrate a ConsumerKey from one app to another? Here's how.

Today, in Apigee Edge, the consumer key is unique to an app, across an organization.

It's not the case that there is a 1:1 mapping of key to app. In fact a single app in Apigee Edge can have a set of "Credentials" and each one of those credentials includes an expiry (which may be "never"), a list of API Products, as well as a consumerKey and consumerSecret.

TODAY, it is possible to READ the consumerKey and consumerSecret for a given app, using the Administrative API in Apigee Edge, and also in the Administrative UI.

4495-single-credential.png

In some special cases, people might want to move a consumerKey from one app to another. This might happen if the developer who OWNS the app, goes away. Because administrators can read the key, and also add specific keys to apps, then it is possible to migrate.

There is no 2-click way to do this within the Apigee UI, unfortunately. And also, there is not a one-REST-call way to do it using the Apigee Edge API. BUT, there is a set of steps you can follow, and there are some tools that wrap up the Admin API calls and automates the entire effort.

The logic steps look like this:

  1. Determine the consumer key (aka API key) you want to migrate. = ORIGINAL_KEY, SECRET
  2. Find the App that contains the key. = APP1

    You can do this by searching in the Apigee UI: Paste the consumerkey into the search box at the top of the Apps list. There are also scripts you can run to do the searching.

  3. Create a new developer, or determine the existing developer to which you want to migrate the key. = DESTDEV
  4. Create a new app for that developer, or determine the existing app belonging to that developer, to which you want to migrate the key. = DESTAPP
  5. If necessary (if you created a new app), remove the implicitly generated credential from the app.
  6. Remove the credential (ORIGINAL_KEY) from the original app This is similar to the above, but for the original app + credential.
  7. Add the original credential (same ORIGINAL_KEY, SECRET values) to the destination app.
  8. Add the API Products that belonged to the original credential to the new credential

Here is one example, a Windows Powershell Script that defines a function called "Migrate-EdgeApiKey". This depends on the Windows Powershell module for Apigee Edge, and is included as part of the examples shipped with that module.

After running that script, an existing ConsumerKey that was valid and attached to App1 for Developer1, will be attached to App2 belonging to Developer2.

If anyone need some additional examples of how to do this in Nodejs or other scripting languages, let me know here.

The underlying administrative API to import a key+secret pair to an existing app is like this:

POST :mgmtserver/v1/o/:org/developers/:developer/apps/:appname/keys/create 
Authorization: :edge-auth
Content-type: application/json
{
  "consumerKey" : "Unique-ConsumerKey-GoesHere",
  "consumerSecret" : "secretGoesHere-ItCanBeQuiteLong-NeedNotBeUnique"
}

I am not in love with that API. Putting a verb ("create") in the URL makes my skin crawl. Or it could be the rash I got from that sketchy motel I stayed in. But anyway, no one should put a verb in a URL path, least of all Apigee. BUT, opinions about RESTful purity aside, that is the URL we're dealing with here.

This API works on an existing developer app belonging to an existing developer. You can create those in the normal way, of course (UI or API).

When creating an app either with the API or the UI, you will get a generated key+secret (potentially with an expiry). If you don't want THAT, and want ONLY the consumer key+secret that you're explicitly importing, just remove the generated key+secret. Like this:

DELETE :mgmtserver/v1/o/:org/developers/:developer/apps/:appname/keys/:consumerkey
Authorization: :edge-auth

You can do THAT ^^ in the UI as well. I forget if it is possible to remove ALL credentials from an app in the UI. You can in the API. So if you use the UI, you may have to FIRST add the known consumerKey, and then remove the generated one.

One MAJOR Disclaimer - this capability may go away in the future. Specifically the ability to READ consumer keys. (Importing keys will still work) The reason READ of keys may go away is that, possibly, Apigee will change so that the consumerKey and consumerSecret will be read-once data. In other words, the Apigee API (and thus UI) will send that data back just once, at the time the credential is provisioned. This change is being considered for security concerns. If you have input on that, as well, comment here. I have no specific timeline on that change, though.

Version history
Last update:
‎03-21-2017 10:18 AM
Updated by: