Update company app creating additional credentials

I am calling the management API to update a company app. When I provide an apiProduct to the body of the request a new set of credentials are created for the app. I am trying to build this into an automated process. I was wondering if there was a way to either have the old credentials removed when I do an update or if the apiProduct is the same as one that is already there to not add new credentials. It seems like the only way to do that would be to make a get call and then compare the products with the body I was going to send. Is that correct?

1 5 620
5 REPLIES 5

Any updates on this. I am trying to understand my options?

Let me understand your goal.

You are updating a company app. You want to add a product to an existing credential.

Yes, it is possible to ADD a product to the list of products that a specific CREDENTIAL allows access to.

The hierarchy of entities is like this:

  • Developer / Company
    • 1: N Apps
      • 1:M Credentials
        • 1:P Products

Via the Admin API, there are REST calls that make it possible to:

  1. create a developer or company
  2. create an app associated to a developer or company. When you do this, a CREDENTIAL is automatically and implicitly created, and the credential is configured to allow access to a specific set of API products. The "Create App" API call basically does "create an app, add a credential, and allow access to {x,Y,Z} products for that credential". The credential, not the app, has an expiry, which is potentially "never".
  3. Add an auto-generated credential to an existing App. When you do this, you get a new credential, and it is authorized for a distinct set of API Products. This may or may not be the same set of API products as is authorized for any of the other credentials on the app.
  4. Add a product to an existing credential, or Remove a product from an existing credential. (Essentially, update the list of products authorized for a credential).
  5. "Import" a key + secret pair; this is like adding an auto-generated credential (#3 above), except, unfortunately and puzzlingly, there is no way to also specify the set of API products for which the imported key/secret is authorized. You can add API products in a second API call.
  6. Remove (delete) a credential from an existing app.
  7. Revoke a Credential, temporarily. This means calls to VerifyApiKey will fail at runtime. If there is a token that was derived from the credential, VerifyAccessToken will fail too. GenerateAccessToken will not work when applied to a revoked credential. (** all subject to cache!)
  8. Approve a credential that had been revoked.

There is no way to update the expiry of a credential.

Examples of the above follow. These all use "developers" and ":developer", but you want "companies" and ":company".

#2: Create a new app

POST :mgmtserver/v1/o/:org/developers/:developer/apps
Authorization: :edge-auth
Content-type: application/json


{
  "apiProducts": [ "helloworld" ],
  "attributes": [ { "name" : "key", "value": "42"} ],
  "keyExpiresIn" : "86400000",
  "name" : "AppNameHere-UniqueForThisDeveloper"
}

#3: Add a credential to an existing app

POST :mgmtserver/v1/o/:org/developers/:developer/apps/:app
Authorization: :edge-auth
Content-type: application/json


{
  "apiProducts": [ "helloworld" ],
  "attributes": [ { "name" : "date added", "value": "20181009-1553"} ],
  "keyExpiresIn" : "86400000"
}

#4: update the list of API products for an existing credential. You must pass the full list of API Products. It REPLACES the previous (possibly empty) list.

POST :mgmtserver/v1/o/:org/developers/:developer/apps/:appname/keys/:consumerkey
Authorization: :edge-auth
Content-type: application/json


{
  "apiProducts" : [ "ApiProduct1", "ApiProduct2" ]
}

#5: Import a key/secret pair as a new credential on an existing app

POST :mgmtserver/v1/o/:org/developers/:developer/apps/:app/keys/create 
Authorization: :edge-auth
Content-type: application/json


{
  "consumerKey" : "ConsumerKeyHere-itMustBeUnique",
  "consumerSecret" : "SecretHere-NeedNotBeUnique"
}

#6: remove a credential

DELETE :mgmtserver/o/:org/developers/:dev/apps/:app/keys/:consumerkey
Authorization: :edge-auth

#7 temporarily revoke an existing credential. This uses a zero-length payload.

POST :mgmtserver/v1/o/:org/developers/:dev/apps/:app/keys/:consumerkey?action=revoke
Content-Type: application/octet-stream 
Authorization: :edge-auth

It is also possible to revoke:

  • an api product on a specific credential. The credential is still good for the other products on the credential.
  • an App. Effectively (but not actually) all the credentials on the app are revoked.
  • A developer. Effectively all the dev's apps are revoked.

...but you didn't ask about those things so I won't give examples of those.

#8 mark a previously revoked credential as approved. This also uses a zero-length payload.

POST :mgmtserver/v1/o/:org/developers/:dev/apps/:app/keys/:consumerkey?action=approve
Content-Type: application/octet-stream 
Authorization: :edge-auth 

when revoking or approving a key, keep in min that the MPs cache keys. The TTL 180s, but it is undocumented and is subject to change.

As a result if you

  1. use a key... (eg pass it for VerifyApiKey)
  2. revoke the key via the Admin API
  3. immediately try to use the same key again

...then at the 2nd use, the key will still be treated as "approved" because it is cached. If you wait 180s, then the key will be treated as revoked. The same applies when approving a key that was revoked - you need to wait for the cache to expire in the MP. Also worth remembering: the cache is per MP node.

garysole
Participant II

It seems that the documentation here: https://apidocs.apigee.com/management/apis/put/organizations/%7Borg_name%7D/companies/%7Bcompany_nam...is incorrect. At the moment it indicates that you MUST include apiProduct, attributes and callbacks otherwise these values will get removed. However, including apiProducts generates a new API key - which is not ideal behavior for an update. The documentation should state that apiProducts should NOT be included in the Company App Update API. If needing to update API products, call the Credential API. Just providing attributes in the company update does not affect the API products that are part of the credentials and does update the app level attributes. Be careful if you update the top level attributes and there is a same name attribute at the credential level, because the credential level attributes take precedence.