Indicators in Pulsedive are enriched from multiple sources.
Understanding where data comes from helps you evaluate the freshness, coverage, and trustworthiness of what you’re seeing.
Collection Methods
Pulsedive collects and enriches indicator data from four sources: scanning, third-party sources, community submissions, and Pulsedive Research.
Scanning
Pulsedive scans indicators directly to collect properties.
All scans run from hardened, rotating proxies across multiple countries.
There are two scan types:
- Passive: Lookups that do not interact directly with the target, including WHOIS, DNS, and metadata retrieval.
- Active: Direct outreach to the target using headless browser instrumentation, which intercepts HTTP requests, TLS certificate data, cookies, and other response data.
Active scans are more comprehensive but generate more noise than passive scans.
To learn more about scanning through the API, visit Scan overview.
Sources
Sources are third-party organizations, research projects, and automated pipelines that contribute curated indicator lists to Pulsedive.
Source data is the primary driver of threat linkage and risk signal for many indicators.
Pulsedive is in the process of standardizing this terminology across the platform.
You may encounter the term “feeds” in legacy parts of the UI and documentation.
Note that this refers to third-party data sources ingested into Pulsedive, not the Pulsedive Feeds product, which is a separate bulk export service.
Pulsedive Research
The Pulsedive team manually curates threats, links indicators to threats, retires stale data, and maintains overall data quality.
This research applies to Pulsedive Community only.
Enterprise Differences
Pulsedive Community and Enterprise use the same scanning infrastructure, but data sources differ.
| Data Source | Community | Enterprise |
|---|
| Scanning | ✓ | ✓ |
| Sources (third-party) | ✓ Historical data from launch | ✓ Historical data from instance setup date |
| Community submissions | ✓ | ✗ |
| Pulsedive research | ✓ | ✗ |
Data Freshness
Indicators carry a family of timestamps that tell you when different collection events last occurred.
Understanding these timestamps helps you evaluate how current an indicator’s data is.
| Field | Description |
|---|
stamp_added | When Pulsedive first added the indicator |
stamp_updated | When Pulsedive last updated the indicator record, either through internal maintenance or a scan |
stamp_seen | When Pulsedive last observed the indicator, whether through a scan, a feed, or a user submission or report |
stamp_probed | When Pulsedive last actively scanned the indicator |
stamp_retired | When Pulsedive retired the indicator, if applicable |
stamp_seen and stamp_probed answer different questions.
stamp_seen tells you when any external signal last confirmed the indicator’s existence.
stamp_probed tells you when Pulsedive last reached out to the indicator directly.
An indicator can be recently seen in a source without having been actively scanned, and vice versa.
To learn more about how these timestamps relate to an indicator’s lifecycle, refer to the Lifecycle section of the Indicators page. 
