Legacy Application Stats

If you signed up to Netify Data Feeds after October 2024, please follow the current Application Stats guide.

Data Payload

The Netify Legacy Application Stats Data Feed is an API that provides the following application details:

Application information and logos
Domains
Network CIDRs
Stats IPs
Protocol and port statistics

We break down each of these items in the following sections.

JSON Overview

"data": {
    { Application Object },
    [ Domain List ],
    [ CIDR List ],
    [ Stats IP List ],
    [ Protocol Port Stats ],
}

Application Object

The application block in the JSON payload provides general information about the given application: label, description, logos, tag name and more. See the application object documentation for more information on the JSON payload details.

"application": {
    "id": 120,
    "tag": "netify.twitter",
    "label": "Twitter",
    "full_label": "Twitter",
    "description": "Twitter is a ...",
    "home_page": {
        "url": "https://twitter.com",
        "text": "Twitter"
    },
    "category": {
        "id": 24,
        "tag": "social-media",
        "label": "Social Media"
    },
    "active": true,
    "favicon": "https://static.netify.ai/...",
    "icon": "https://static.netify.ai/...",
    "logo": "https://static.netify.ai/...",
    "favicon_source": "app",
    "icon_source": "app",
    "logo_source": "app"
}

The domain list contains all the domain definitions used to detect an application. For example, the following is a sample of domains used to match the Twitter application:

t.co
twimg.com
twitter.com
twimg.com.akahost.net
twitter.map.fastly.net
etc.

These domains are used to identify application network traffic flows via Netify DPI processing. The hostnames coming from TLS SNI, TLS certificate common names, HTTP headers, DNS requests, DNS hinting, and any hostname that pops out of deep packet inspection are compared to the domain lists.

Please note: for companies with large portfolios of applications, the subdomains can be important differentiators. For example, the googleapis.com domain is part of the Google domain list, but the youtubei.googleapis.com domain is part of Google-owned YouTube domain list.

If a domain belongs to a platform, the metadata is attached to the payload.

Domain List JSON Overview

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        { Platform Object }
    }

Domain List JSON Example

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        "platform": {
            "id": 1002,
            "tag": "akamai",
            "label": "Akamai",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            },
        }
    },

Some applications run across large network blocks. For example, Microsoft Teams connects to specific network blocks for video conferencing. In these cases, the cidr_list and cidr_type attributes will appear in the dataset. The cidr_type will be one of the following three values:

dedicated
hosted
multiproduct

Dedicated: CIDRs in this category are dedicated to serving the application. For example, Telegram CIDRs are not used by any other application -- it's all Telegram.

Hosted: CIDRs in this category are hosting other applications. For example, the Amazon AWS CIDRs can be used to identify all of AWS, but many applications are hosted on this network.

Multiproduct: CIDRs in this category belong to one organization, but are shared amongst different products. For example, the Apple CIDR list will have traffic from the following applications: iCloud, Apple Mail, Apple TV, etc.

If an application does not have any defined CIDR blocks, the cidr_type and cidr_list keys will not exist.

CIDR List and Type JSON Example

"cidr_type": "dedicated",
"cidr_list": [
    {
        "network": "8.25.194.0/23",
        "version": "ipv4"
    },
    {
        "network": "8.25.196.0/23",
        "version": "ipv4"
    },
    ...

The network CIDR list is derived from data provided directly from application vendors, Netify-derived network traffic analysis, and autonomous system number (ASN) definitions. These networks are fairly static, but there are at least a few changes to network CIDR lists every week.

The stats IPs associated with the application are provided in the stats_ip_list field of the payload. The data is derived from Netify DPI network traffic analysis.

If an IP belongs to a platform, the metadata is attached to the payload. However, to minimize payload size, a subset of fields in the platform is provided. See the Platform Object documentation for more information.

This Application Stats data feed includes historical statistics on IPs, including IPs that may now be used by a different application. If you are looking for a list of active IPs only, visit the Application IPs Data Feed page.

Stats IP List - JSON Example

"stats_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        "platform": {
            "id": 1006,
            "tag": "amazon-cloudfront",
            "label": "Amazon CloudFront",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            }
        }
    }
]

It is very common for applications to use shared IPs. Here are three common shared IP scenarios:

Content delivery networks
Third party platforms, e.g. a third-party mail service
Multi-app organizations, e.g. the YouTube and Gmail apps both use shared Google infrastructure

The shared_score provides information on IP sharing. Every IP is given a score from 0 (dedicated) to 100 (shared). Details on the scores are provided in the table below.

Shared Score Descriptions

-1: Analysis has not been completed.
0-10: Dedicated IP detected: dedicated network ASNs, IP certificate matches, reverse DNS matches.
10-20: Dedicated IP detected, high probability.
20-40: Dedicated IP detected, but possibility of sharing detected through heuristics / machine learning.
40-60: Gah. This often happens when IPs are churned (dedicated to one app, then later dedicated to a different app).
60-80: Shared IP detected, but possibility that it is dedicated.
80-90: Shared IP detected, high probability.
90-100: Shared IP detected: raw Netify intelligence data confirms sharing.

The protocol_port_stats field provides basic statistics about the protocols and ports used by the application. Most apps use standard HTTP and HTTPS, but IoT devices, TVs, mobile apps, and others can use additional ports and protocols.

Protocol	Port	Flow Percent
HTTP	TCP 80	82%
HTTPS	TCP 443	11%
HTTP	TCP 1119	6%
StarCraft	TCP 1119	< 1%
HTTP	TCP 3724	< 1%

You can customize the statistics available for applications. Please contact us for details.

Protocol Port Stats - JSON Example

"protocol_port_stats": [
    {
        "protocol_port": {
            "ip_protocol": {
                "id": 6,
                "label": "TCP"
            },
            "protocol": {
                "id": 196,
                "tag": "https",
                "label": "HTTPS"
            },
            "port": 443
        },
        "stats": {
            "flow_percent": "97.28",
            "byte_percent": "99.98",
            "average_bytes_per_flow": 175000
        }
    }
]

Route	https://feeds.netify.ai/api/v2/stats/applications/{application_tag}
Authentication	x-api-key
Pagination	not applicable

Legacy Application Stats

API Quick Reference

Data Payload

Application Object

Domain List

CIDR List and Type

Stats IP List

IP Shared Score

Protocol Port Stats