Can I get a different apikey for the same developer for each different product?

Not applicable

Our APIs offer some services that are best consumed in the browser or on mobile, and others that are best consumed on the server.

I would like the developers using our API to be able to generate two different API keys, one for each context, so that they are not loading the key that should be kept secret on the server into the code sent do their clients.

However, when I separate these two contexts as different products, I find the same API key used for both products is the same. Are products the right way to separate these use-cases? If so, how can I force the generation of a different apikey for each product?

0 6 1,133
6 REPLIES 6

Using a separate app for each app will generate different keys. Browser app, mobile app1, mobile app2, etc.

So have 2 different products, and only allow the user to select them from a drop-down list in the portal, so that they are forced to create 2 apps, one for each product?

Yeah, something like that. Ideally a developer should be creating an app for each consuming app, in my opinion, and not re-using API keys across apps.

adas
Participant V

@tpearson you can actually have different API keys for the same app for each API product. This can be done using the UPDATE call for the developer app. Here's what you can do:

Create Apiproduct 1:
POST /v1/o/myorg/apiproducts

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ApiProduct name="productv1">
    <ApiResources/>
    <ApprovalType>auto</ApprovalType>
    <Attributes/>
    <Description></Description>
    <DisplayName>productv1</DisplayName>
    <Environments/>
    <Proxies/>
    <Scopes>
        <Scope></Scope>
    </Scopes>
</ApiProduct>

Create Apiproduct 2:
POST /v1/o/myorg/apiproducts

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ApiProduct name="productv2">
    <ApiResources/>
    <ApprovalType>auto</ApprovalType>
    <Attributes/>
    <Description></Description>
    <DisplayName>productv2</DisplayName>
    <Environments/>
    <Proxies/>
    <Scopes>
        <Scope></Scope>
    </Scopes>
</ApiProduct>

Create a developer app with productv1:
POST /v1/o/myorg/developers/mydev@apigee.com/apps

<App name="myApp">
<AccessType>read</AccessType>
<CallbackUrl>http://example.com</CallbackUrl>
<ApiProducts>
<ApiProduct>productv1</ApiProduct>
</ApiProducts>
</App>

Now notice that you have an app with 1 set of key/secret for the apiproduct 'productv1'. You can then use the update call to add a new apiproduct to the app which will generate a new set of key/secret for this new apiproduct:

Update developer app:
PUT /v1/o/myorg/developers/mydev@apigee.com/apps/myApp

<App name="myApp">
<AccessType>read</AccessType>
<CallbackUrl>http://example.com</CallbackUrl>
<ApiProducts>
<ApiProduct>productv2</ApiProduct>
</ApiProducts>
</App>

Note that I am only specifying productv2 and not both v1 and v2, because I only want new keys to be generated for productv2 and the existing key for productv1 should continue to be there. If you specify both, then new keys would be generated for both the products along with the existing key for productv1.

This should help you generate 1 key per apiproduct for the same app, so you need not create 1 app per apiproduct just because you want different keys for each apiproduct and restrict access to your apis.

The UI hides this complexity from you, and by default adds the new apiproduct to the existing key so that you don't see a new key being generated when you edit the app using the management UI to add a new apiproduct. I hope this was useful.

@arghya das..could you please tell how to run the Update App call using Management API..for eg: what body to pass in the request as application/json content.

Here you go, @Sonali Morey:

curl -X PUT -H "Content-Type: application/json" -d \
'{ "attributes" : [ {"name" : "foo", "value" : "bar" } ], "name" : "myApp", "apiProducts" : ["product2"], "keyExpiresIn" : "-1" }' "https://api.enterprise.apigee.com/v1/organizations/myorg/developers/me@example.com/apps/myApp" -u edge_email

Important: Don't forget to include any existing app attributes in the update call, as shown above. Otherwise you'll lose them.

(I've tweaked the API docs to include this use case.)