Why the Organization Field Isn't Available the Same Way Across Spur's Data Feeds
The Context API's per-IP organization field isn't guaranteed in every data feed. Each feed has a different schema and covers a different slice of IP space, so field availability varies by feed.
The Context API's organization field describes the organization currently assigned to use a specific IP address — such as a customer, hosting provider, or service operator. This is a different, more granular concept than as.organization, which describes who owns and operates the Autonomous System (AS) that routes the IP via BGP.
Availability of the organization field differs across Spur's data feeds because each feed has its own schema and covers a different slice of IP space:
IP Geo feed— does not include an organization field at all. Its records cover geolocation data (city, country, subdivisions) and ASN information, not organization attribution.Anonymous +Residential feed— each record is an IP Context Object, the same schema the Context API returns, so the organization field can be present. But this feed only includes IPs contributing to anonymizing, residential, malware, peer-to-peer, blockchain proxy, or ZTNA infrastructure — not every IP — so it won't have a record for an IP outside that scope.Datacenter Hosting (DCH) feed— has its own organization field, but it describes the registered organization for the network block as a whole (a WHOIS-style, block-level value), not the per-IP "currently assigned to use" value the Context API returns. The two won't always match, and this feed is scoped to datacenter-hosting network blocks only.
Because each feed is scoped to a different category of IP space and uses its own schema, no single feed guarantees an organization value for an arbitrary IP the way a live Context API lookup can. If an IP isn't present in a given feed at all, that's a coverage gap (the IP falls outside what that feed tracks) rather than a missing field on an existing record — worth distinguishing when troubleshooting a lookup that comes back empty.
Related explainers
What "Client Proxies" Means in Spur Data
"Client Proxies" in Spur data describes proxy-network activity Spur observed coming from an IP — it does not mean the IP is owned or operated by the listed provider.
Anonymizing vs. Non-Anonymizing Tunnels: What the "anonymous" Flag Means
Not every tunnel Spur detects is built to anonymize. The tunnels object's anonymous flag distinguishes corporate/ZTNA infrastructure from services designed to obscure a user's origin.
Why Residential Proxy Classifications Can Appear on Legitimate Infrastructure
Residential proxy networks recruit real consumer devices to relay traffic, so a legitimate ISP's own IP ranges can show a residential-proxy classification without the ISP's knowledge or involvement.
Entrance IPs vs. Exit IPs for Anonymizing Tunnels
Some anonymizing tunnel configurations route through shared infrastructure, like Cloudflare, before reaching the tunnel operator's own exit point. Here's why blocking the entrance IP can affect unrelated legitimate traffic, and what to enforce on instead.
How Spur IP Classifications Work: Observed Behavior, Not IP Ownership
Spur classifications describe what was observed happening on an IP during a given window, not who owns the IP or ASN — a key distinction when investigating a classification that looks wrong.