Nope - that's not the way to do it. The Developer App is a management entity, and there is no runtime policy that allows an Apigee Edge proxy to modify the Developer App entity.
You *could* invoke the management API from within the API Proxy, but that's an ANTI-pattern, and I strongly recommend against it.
Instead I think there's probably a better way to solve the problem.
When the Asynch target invokes the callback (webhook?) into Apigee Edge, does that callback include a "state" field?
I'm thinking when you initially call into that asynch system, you pass it a "state" or some opaque string that uniquely identifies the outbound call. This would also implicitly relate the developer, the user, and any other context you want to retain for later processing of the asynch response. Your API Proxy could store all of this in Cache, at runtime, using the opaque string as the cache key, before invoking the outbound asynch target system. This cache key could also be the developer ID, or the app id, or ... something else that is derivable from the original caller and its API key.
Then when the asynch target calls back, it would pass in that opaque string. The proxy then does the cache lookup using the opaque string and retrieves everything it needs to retrieve. If the proxy wants to update that cache item, it can do so, using the same cache key, or a second cache key derived from the first. like "original-cache-key-response" or whatever.
The cache entry can have a TTL on it, say 5 minutes or whatever is reasonable. If the asynch target does not respond within that TTL, then the cache entry disappears and the asynch system is assumed to have experienced an error.
When the original client callsl back in, the API proxy can look in "original-cache-key-response" for the data sent in form the asynch system.
This is how I would do it.
If you really want to permanently update the Developer app, you should do that administratively, not at runtime in the API proxy.
LinkedIn
Twitter
