How to find out who is this (not set) developer app name?

[dhivyaaroma]

Team,

Can you please help us on how to find out, who is this (not set) i.e., the unregistered developer app name in Apigee Edge? We are using the private cloud, and seeing a heavy consumption of API from the (not set) developer.

Thanks,

Dhivya Aroma.

[apickelsimer]

Analytics will report (not yet) for a number of reasons, which are documented at https://docs.apigee.com/api-platform/analytics/why-am-i-seeing-analytics-entity-named-not-set.

From the docs -

As you review your analytics, you may see an entity value of (not set) displayed, including the parenthesis, for your API Proxies, Product, Developer, Developer Apps and other dimensions. This may or may not be an issue.

Oftentimes, (not set) means Edge doesn't have enough information. For example, developer apps are associated with developers, API products, and by extension API proxies. When a developer app makes an API call with an API key or OAuth token, all those associations are made in analytics. However, if an API proxy is open and doesn't require an API key, Edge has no way of knowing if there is a developer, developer app, or product associated with the API call.

Other times, (not set) could mean doesn't apply. For example, the "Flow Name on Error" dimension shows the named API proxy flows where errors occurred. In that case, all non-error calls will be shown as (not set) because there was no error in the calls.

[dhivyaaroma]

Hi ,

Thank you for the response. But our API is secured and not open. We have set up the oauth2.0 authorization for every API before making the calls. 

For a same API, we could see developer app & email. But for some calls which has high number, we are seeing (not set). 

Can you please help if I need to check anything in the code?

Thanks,

Dhivya Aroma.

[apickelsimer]

You should consider all the possibilities on why Apigee does not have enough information in which we default to a (not set) value. 

The most common reason is the API is being called by someone that does not have a valid credential. The fact that your proxy is protected by OAuth does not mean each and every request is actually passing a valid credential.

In fact, I recommend you explore the data more deeply by crafting a Custom Report. You can navigate the other dimensions Apigee collects like URI, http method/verb, response codes, client IP, and so on. This should give you an idea on who is calling what AND how Apigee responds to those requests. 

Particularly for APIs that are exposed to the internet publicly, you may find unwanted traffic, or traffic otherwise generated by a bot, or perhaps something malicious. It is not uncommon for bots to crawl public APIs looking for vulnerability. If you do suspect this is occurring, I recommend you take advantage of Apigee's Advanced API Security modules to pin point exactly what is happening. In these modules we include recommended steps for mediation and further protection. 

[dhivyaaroma]

Hi ,

Thanks for the detailed information. Sure, I will create the custom report and analyse the calls. I will also explore the Advanced API Security.

Thanks,

Dhivya Aroma.