Application IPs Data Feed

The Netify Application IPs Data Feed provides network intelligence data that is typically used for:

  • QoS/QoE
  • Network routing policies
  • Blacklisting/whitelisting
  • IP-based machine learning models

You can find technical details about the information provided by the API in the Data Payload section below. For Netify Data Feeds product information, please click on the button below.

Netify Data Feeds Overview


Getting Started

You can find general Netify REST API information on Authentication, Response Codes, and other topics in the menu. You can also find hostnames, routes and specific details about API endpoints in the API Reference Documentation.

API Overview

API Quick Reference

ProTip: some applications use tens of thousands of server IP addresses to deliver images, videos, and application data. Payloads can be up to 50 MB.

Route https://feeds.netify.ai/api/v2/intelligence/application_ips/{application_tag}
Authentication x-api-key
Pagination 10

Data Payload

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

  • Application Information and logos
  • Domains
  • Network CIDRs
  • Active IPs

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

JSON Overview

"data": {
    { Application Object },
    [ Domain List ],
    [ CIDR List ],
    [ Active IP List ],
}

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.

One important note about application categories: if you are using a different categorization system (e.g. Cisco Umbrella, DNSFilter), you can customize the Netify categories to meet your needs. Contact us for more information.

"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"
}

Domain List

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. See the Domain Object documentation for more information on the JSON payload details.

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"
            },
        }
    },

CIDR List

Some applications run on company-owned network blocks. For example, Microsoft Teams connects to specific network blocks for video conferencing. Only the network CIDRs dedicated to a specific application are provided in the cidr_list part of the payload. If an application does not have any defined CIDR blocks, the cidr_list key will not exist.

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.

CIDR List JSON Example

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

Active IP List

The active IPs associated with the application but not part of the cidr_list blocks are provided in the active_ip_list field of the payload. Basically, the combination of the cidr_list and active_ip_list provides a complete list of networks/IPs used by the application. The data is derived from Netify DPI network traffic analysis. See adjacent sample.

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

Though many IP addresses serving applications are fairly static, IPs do get re-used. For example, most Amazon CloudFront CDN IPs for a specific application can change every week or so. This Application IPs data feed actively purges stale IP addresses. However, if you are looking for historical statistics for application IPs, please visit the IP Stats Data Feed page.

Shared IPs

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 services
  • Multi-app organizations, e.g. the YouTube and Gmail apps both use shared Google infrastructure

Active IP List JSON Overview

"active_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        { Platform Object (minified) }
    }
}

Active IP List JSON Example

"active_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"
            },
            ...
        }
    },

The shared and shared_score provide information on IP sharing. Every IP is given a score from 0 (dedicated) to 100 (shared). This score is published in the shared_score field. If the score is above 50, the shared flag is set to true. Details on the scores are provided in the table below.

Score Description
-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.

Other Data Feeds

Integration and Custom Solutions

Do you have any questions about integration, APIs or custom development?

Contact Us