Developer Portal - promoting credentials from Sandbox to Production

[DChiesa]

Suppose I have a developer portal, and it allows developers to register, signin, view the catalog of APIs available, and then "subscribe" or get credentials for "sandbox" versions of various APIs.

The developer builds and tests an app, and then requests access to the production system.

What's the best way to facilitate that?

- "Promote" the existing credentials that work in the sandbox, to also work in production?

- ask the developer to request new credentials for a different API Product? (Maybe the production API product requires manual approval)

- something else?

[dcouldwell]

I've seen a variety of approaches to this problem and it depends on the size of your API Consumer / Developer community and the balance required for self service vs some lightweight admin.

First point I would make is to strongly recommend against using the same credentials for the Sandbox and Production Apps. You don't have any real visibility of the protocols put in place at the consumer end around how they administer credentials. Enforcing some separation yourself is good basic security hygiene.

So in terms of promotion models here's what Ive seen

1. Promotion workflow in the Developer Portal
   Once an API Consumer is ready to promote to the next level (be it from Sandbox -> UAT, UAT -> Production or you may just move from Sandbox -> Prod) they submit a request through the Developer Portal.
   This request is received by the Developer Portal Admin who will review the request and then alter the API Consumer's permissions to allow them to see the next version of the API Product they are using i.e. if they start off using the Sandbox XXX Product this would usually be a 'public' product and they can only access the Prod XXX Product once an Admin has uplifted their permissions.
   Once the API Consumer has permissions they can then create a new App that they associate with the Prod Product.
   This process can be streamlined or potentially automated with interaction with another system that can confirm that the initial Sandbox validation has been completed.
2. Admin Promotion
   Once an API Consumer is ready to promote to the next level they submit a request through the Developer Portal to access to the next level. This could just be via an email or via a contact form.
   The Admin will review this request and create a new App for the Developer and Associate the App with the Prod Product themselves.
   The API Consumer can then view the new App in the Dev Portal and access the new credentials there.
3. Separate Dev Portals
   As above the API Consumer request promotion.
   This triggers the Dev Portal Admin to create a new account for the API Consumer in a separate Production Dev Portal where they will be able to create a Prod App and access Prod Products.

There are several Pros and Cons of the above approaches and it really depends on your API Consumer community and how you're interacting with them. Some thoughts to consider

• How many API Consumers do you have?
  Minimising manual steps is key if you have a large community.
• How many promotions do you have?
  Do App developers need to move Sandbox -> UAT -> Production or os Sandbox -> Production sufficient?
• Where will your core API Consumer community live?
  If you're creating two portals will content be duplicated or will one of these portals be the main point of contact?
• How much to you trust your API Consumers?
  Tighter governance == increased cost but may be required depending on your community.
  Option 1 above is open to abuse as once the API Consumer has access to the Prod Product they could just choose to associate it with their Sandbox App.

See also https://community.apigee.com/articles/23210/coordinating-api-and-app-development-cycles.html for more thoughts.