How do I verify the integrity of a downloaded feed file?
Checksum information is provided in the download response headers — look for a header such as x-goog-hash and use the algorithm and value it specifies to verify. Don't treat the ETag as an MD5 checksum; it isn't one.
Similar questions
What are the exact boundary semantics of the Anonymous +Residential Realtime feed's 5-minute window?
The window is inclusive of the start time and exclusive of the end time. For example, the file at /v2/anonymous-residential/realtime/<YYYYMMDD>/1300.json.gz covers detections from 12:55:00 up to and including 12:59:59 UTC — 13:00:00 is not included and appears in the next file (1305.json.gz) instead. When consuming consecutive 5-minute files, each detection belongs to exactly one file, so there's no gap or double-processing at the boundary between files.
When should I use the Exports API?
The Exports API is designed for environments where pre-processing isn't possible — for example, direct integration into a SIEM, IPS, or firewall. If you need full feed data, download the entire feed and perform your own transformation locally.
Why did a feed file change size or filename?
Feed files can change in size or filename when Spur makes a planned change to a feed's publication — for example, an updated data source or schema version. If an automated ingestion process depends on a specific filename, use the documented stable download mechanism rather than relying on a fixed filename pattern. If a change looks unexpected, contact support with the feed name, version, and the date you noticed the difference.
Why might a feed result differ from an API lookup for the same IP?
Data feeds are point-in-time snapshots, while the API can return more current, near-real-time data. A timestamp gap between feed generation and your API query is the most common cause of a difference.
How can I download data on all IPv4 and IPv6 addresses?
IP location, routing, and ownership information is produced at the network level and presented into netblocks. Other data such as client fields or service attributions are produced on an individual IP address basis. For our API customer this coverage is automatically merged to produce full IPv4 and IPv6 coverage. For on-prem services, a combination of these two granularities must be used to cover all IP space.
Related guides & explainers
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.
Context API Chrome Extension
Install Spur's Context API Chrome Extension to look up IP enrichment data directly from any web page — highlight an IP and get results inline, without leaving your browser. This is a developer-mode tool, not a Chrome Web Store listing.
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.
Expanding IP and Service Rows in the Explorer
Click any IP or service row in the Monocle Explorer's breakdown tables to expand an inline detail panel, without leaving the table.