Thanks for your question. It's a good one.
I'm not sure about the documentation. I can tell you how it actually works, though.
The key thing: There is no way to update keyExpiresIn.
You said you wanted to update a developer app to modify the expiry. But: An expiry value is not part of the developer app; a developer app does not expire. If you query any developer app with the API, you will see expiry values as part of the CREDENTIAL or credentials associated with the app. The app has a 1:N relationship with credentials. You may have understood all of this, but I want to be as precise and clear as possible on this. Expiry applies to credentials, not apps.
OK now, having said that, the mgmt API for creating an app can be a little confusing for a couple reasons.
- first, because, while apps and credentials are distinct, and while there is a 1:N relationship between app and credentials, when you ask to create an app, you will get both an app and a credential!
Back when the API was created, someone thought it would be handy to implicitly and automatically create a single credential when the Admin API was called to create an app. Who wants an app with no credentials, right?
So when creating an app, you can optionally pass in keyExpiresIn as a toplevel field in the JSON (or XML if you like). But, if present, that field applies ONLY to the credential that is automatically (implicitly) generated when you create the app. That field is not stored with the app, and doesn't apply to the app. If the field isn't present, you get a credential that never expires. Following RESTful design, maybe it would have been better to accept a query param like "expiryForInitialKey" , rather than accepting "keyExpiresIn" in the payload.
If you later add another credential to the app, you again need to specify keyExpiresIn for that credential, if you want one. The app doesn't "remember" the keyExpiresIn that you used for the initial credential. There are no smarts in the backend logic to look in previously created credentials and use the expiry that was used there, for newly created credentials.
- The Second reason the API is confusing, is this: the field you use to specify expiry is called "keyExpiresIn", but when you retrieve the credential entity, the actual value returned is "expiresAt". This is very un-RESTy. Accepting keyExpiresIn on the query string might have solved this, too.
To repeat, you cannot update the expiry (expiresAt) of a credential. You can:
- specify the expiry when you ask Apigee Edge to generate a credential (via keyExpiresIn)
- add or remove API Products as authorized on a credential
You can also:
- revoke or approve API Products (without adding or removing them) on a credential
- revoke or approve a specific credential
- revoke or approve an app
- revoke or approve a developer
Also:
- There is no such thing as expiry of "a developer app". Apps don't expire.
- There is no such thing as expiry of "a developer".
- You cannot (AFAIK) specify the expiry of an external credential that you import into Edge. (This feels like an unnecessary limitation, but we've never removed it).
- You cannot "un-expire" an expired credential. Expiry is different than revocation.
- Credential keys must be unique in an organization.
- You can remove credentials (keys) from an app. This means it's possible for an app to have zero credentials. When creating an app, you always get 1 cred. But you can then remove that, and you will have an app with zero credentials.
Does this clarify things?
If you point me to a specific doc page that contradicts any of the above, I will first apologize about the misinformation, and then I'll make sure we get the doc page fixed.
LinkedIn
Twitter
