Signal by NFX Investor Scraper

Slug: fatihtahta/signal-nfx-scraper

Overview

Signal by NFX Investor Scraper collects structured investor profiles from public investor lists on Signal by NFX. Signal by NFX organizes public information about venture investors, firms, investment stages, sectors, check sizes, locations, professional backgrounds, portfolios and investing networks, making it useful for focused fundraising and market research. The actor turns one or more public investor-list URLs into repeatable, schema-aware records that are easier to review and compare than unstructured profile pages. Use it for investor discovery, fundraising research, firm and role analysis, contact enrichment, market mapping and recurring research workflows. Results are delivered as structured Apify dataset records suitable for review, export, ETL pipelines, BI dashboards, CRM enrichment, AI-agent workflows and downstream processing. Stable identifiers, source context and run summaries support recurring collection without implying that every public profile or optional field will always be available.

What Makes This Actor Different

• Grouped investor records: Identity, firm, investment preferences, contact links, list memberships, professional background, portfolio, network, media and record counts remain organized in documented nested objects.
• Deduplication-friendly identity: Every normal record includes investorId; pair it with source.sourceList.slug when the same investor can appear in more than one selected list.
• Fundraising-oriented attributes: Published stage, vertical, check-size, location, role and firm fields support investor targeting without presenting those values as commitments or current investment availability.
• Optional verified-email workflow: Email discovery can be enabled explicitly. The record distinguishes accepted and risky results, while RUN-SUMMARY reports the run-level enrichment outcome.
• Progressive dataset availability: Completed profiles are saved during the run, making the dataset useful for review and downstream processing even before a larger multi-list run finishes.
• Operational run receipts: RUN-SUMMARY and RUN-SUMMARY.html provide status, duration, saved and duplicate counts, stage, vertical, firm and email breakdowns, representative profiles and completion context.
• Optional MCP handoff: User-authorized Apify MCP connectors can receive a compact post-run summary and public Apify output links. Full investor rows are not sent through MCP by default.
• Pipeline-ready contract: Nullable optional fields, documented nested shapes and additionalProperties support schema-aware ingestion while allowing the public record to evolve.

Who Should Use This Actor

• Founders and fundraising teams: Build a focused research list by investment stage, sector or Signal list, then review firm, role, check-size and location fit.
• Venture market analysts: Compare the investors, firms and public preferences represented across multiple thematic or stage-based lists.
• Accelerators and ecosystem teams: Create structured investor directories for internal research, founder support and program operations.
• CRM and revenue operations teams: Enrich investor and firm records with public identity, role, profile, website and social-link context.
• Data engineering and analytics teams: Load normalized investor records into warehouses, search indexes, BI tools and recurring research pipelines.
• AI agents and workflow builders: Give an agent a bounded investor-list input, a documented record contract and a run receipt for follow-up analysis.
• Research and operations teams: Schedule repeatable collection and use stable identifiers to reconcile public-profile changes across runs.

Common Use Cases

• Investor discovery: Collect the public profiles associated with a specific Signal investor list.
• Fundraising research: Review published stage, sector, check-size, location, firm and role information before human qualification.
• Firm and role mapping: Group investors by firm, position, professional headline or associated lists.
• Portfolio research: Analyze published portfolio companies, rounds, co-investors and investment counts where available.
• Network analysis: Review public co-investor and investing-connection context for relationship research.
• CRM enrichment: Add public profile URLs, websites, social links and optional accepted work emails to existing investor records.
• Recurring research: Run the same list inputs on a schedule and compare records using stable IDs and collection timestamps.
• Agentic workflow handoff: Collect a scoped dataset, inspect the run receipt and pass selected records or a compact summary to the next workflow step.

Real-World Questions This Data Can Answer

• Which public investors appear on a specific stage- or sector-focused Signal list?
• Which firms and roles are most represented across the selected investor lists?
• Which investors publish check-size or geographic preferences relevant to a fundraising thesis?
• Which profiles include public portfolio, education, work-history or network context?
• Which records have accepted email enrichment results, and what was the run-level enrichment outcome?
• Where does the same investor appear across multiple Signal lists?
• Which public profile attributes changed between two scheduled collections?
• Did the run complete, stop early, return no records or finish with partial profile detail?

Quick Start

1. Open the actor in Apify Console.
2. Add one public Signal URL under /investor-lists/.
3. Set a small limit, such as 10, for the first validation run.
4. Leave email enrichment disabled until you have confirmed the base record shape.
5. Start the run and inspect the first dataset records plus RUN-SUMMARY.
6. Increase the limit, add more list URLs or schedule recurring runs after validating the output.

Input Parameters

The actor accepts investor-list URLs, a total output limit, optional email settings and optional MCP delivery connectors.

Parameter	Type	Description	Default
startUrls	array of strings	One or more public URLs under https://signal.nfx.com/investor-lists/. Duplicate URLs are ignored.	–
limit	integer, minimum 0	Maximum number of unique investor profiles to save across all supplied lists. 0 intentionally saves no records.	50000
getEmails	boolean	Attempts work-email enrichment and saves only accepted results. Review emailStatus and the run summary before using an address.	false
includeRiskyEmails	boolean	When email enrichment is enabled, includes risky or accept-all results and marks them with emailStatus = "risky". Disable for valid-only output.	true
mcpConnectors	array of unique MCP connector resources	Optional user-authorized Apify connectors for compact post-run summary delivery. The full dataset is not sent by default.	[]

Choosing Inputs

Use startUrls to define the research scope. A single list produces the cleanest segment for analysis, while multiple lists are useful when you want one combined dataset and can retain source.sourceList.slug as the segment label.

Start with a small limit to validate field availability and downstream mappings. Increase it only after checking several records because profile detail varies between investors. The limit applies across all supplied lists, so separate runs are preferable when each list needs its own fixed quota or independent monitoring history.

Keep getEmails disabled for identity, firm, portfolio or network research that does not require contact enrichment. When enabling it, choose whether risky or accept-all results belong in your workflow with includeRiskyEmails, then treat emailStatus as part of your acceptance policy.

Select mcpConnectors only when a compatible, user-authorized destination should receive the compact run handoff. Leaving it empty keeps delivery limited to the Apify dataset and key-value-store artifacts.

Input Recipes

• Validation run: Use one investor-list URL, set limit to 10 and keep email enrichment disabled. Inspect identity, firm and source context before expanding the run.
• Single-segment research: Use one stage- or sector-specific list with a limit sized for the intended analyst or CRM review queue.
• Cross-list comparison: Supply several related list URLs, then group results by source.sourceList.slug, stage and vertical.
• Strict email enrichment: Enable getEmails, disable includeRiskyEmails and review both row-level emailStatus and the run-level enrichment status.
• Broader contact research: Enable both email fields when your policy allows risky or accept-all results to enter a separate human-review queue.
• Recurring monitoring: Reuse the same list URLs and input settings on a schedule, then upsert by investorId plus list slug and compare selected public fields.

Example Inputs

Validate one investor list

{
  "startUrls": [
    "https://signal.nfx.com/investor-lists/top-fintech-seed-investors"
  ],
  "limit": 10,
  "getEmails": false
}

Collect a larger investor list

{
  "startUrls": ["https://signal.nfx.com/investor-lists/fintech-seed"],
  "limit": 200,
  "getEmails": false
}

Enrich accepted emails with a strict policy

{
  "startUrls": [
    "https://signal.nfx.com/investor-lists/top-fintech-seed-investors"
  ],
  "limit": 50,
  "getEmails": true,
  "includeRiskyEmails": false
}

Output

Output Destination

The actor writes results to an Apify dataset as JSON records. The dataset is designed for direct consumption by analytics tools, ETL pipelines, AI agents and downstream APIs with minimal post-processing.

The current public dataset contains one record shape: an investor profile with recordType = "investor". Run summaries and reports are separate key-value-store artifacts, not dataset rows.

Record Envelope and Stable Identifiers

The recommended idempotency key is the composite investorId + source.sourceList.slug. investorId identifies the investor, while the list slug preserves the list-specific occurrence needed for cross-list analysis.

Use this composite key for dataset deduplication and upserts. Stable identity plus source.crawledAt makes records easier to merge, synchronize and compare across repeated runs. source.profileUrl is the public audit link for the investor profile; source.sourceList records the list context that produced the row.

Example: investor record

{
  "recordType": "investor",
  "investorId": "sample-investor-101",
  "source": {
    "sourceList": {
      "slug": "fintech-seed",
      "stage": "Seed",
      "vertical": "FinTech"
    },
    "profileUrl": "https://signal.nfx.com/investors/sample-investor",
    "crawledAt": "2026-07-26T00:00:00Z"
  },
  "email": null,
  "emailStatus": null,
  "person": {
    "personId": "sample-person-101",
    "fullName": "Alex Sample",
    "firstName": "Alex",
    "lastName": "Sample",
    "slug": "sample-investor",
    "headline": "Partner at Sample Ventures",
    "roles": ["VC", "Investor"],
    "voteCount": 12
  },
  "firm": {
    "firmId": "sample-firm-10",
    "name": "Sample Ventures",
    "slug": "sample-ventures",
    "currentFundSize": "$100M"
  },
  "investmentPreferences": {
    "position": "partner",
    "checkSize": {
      "min": 100000,
      "max": 1000000,
      "target": 500000
    },
    "locations": ["San Francisco Bay Area"]
  },
  "contact": {
    "website": "https://example.com",
    "linkedin": "https://www.linkedin.com/in/sample-investor/",
    "twitter": null,
    "crunchbase": null,
    "angellist": null,
    "facebook": null
  },
  "lists": [
    {
      "stage": "Seed",
      "slug": "fintech-seed",
      "vertical": "FinTech"
    }
  ],
  "background": {
    "education": [
      {
        "degree": "MBA",
        "fieldOfStudy": "Business",
        "school": {
          "name": "Sample University",
          "displayName": "Sample University",
          "studentCount": 10000
        }
      }
    ],
    "experience": [
      {
        "title": "General Partner",
        "company": {
          "name": "Sample Ventures",
          "displayName": "Sample Ventures",
          "employeeCount": 25
        },
        "start": {
          "month": 1,
          "year": 2020
        },
        "end": {
          "month": null,
          "year": null
        }
      }
    ]
  },
  "portfolio": {
    "summary": {
      "investmentCount": 1,
      "hasMore": false
    },
    "investments": [
      {
        "company": "Sample Labs",
        "totalRaised": [],
        "coinvestors": ["Example Capital"],
        "rounds": [
          {
            "stage": "seed",
            "date": "2025-04-01",
            "amount": "$3M",
            "isLead": true
          }
        ]
      }
    ]
  },
  "network": {
    "coinvestorsInvestors": [],
    "coinvestorsScoutsAndAngels": [],
    "connections": []
  },
  "media": [],
  "images": {
    "profile": ["https://example.com/sample-investor.jpg"]
  },
  "counts": {
    "degrees": 1,
    "positions": 1,
    "lists": 1,
    "portfolioInvestments": 1,
    "connections": 0,
    "networkInvestors": 0,
    "networkScouts": 0
  }
}

The example is synthetic. Optional fields can be null or empty when the public profile does not provide them.

Run Summary, Map, And Artifacts

The default key-value store contains two stable run receipts:

• RUN-SUMMARY: Machine-readable JSON with generated, start and finish times; duration; status; requested limit; saved chunks and records; duplicate count; email coverage; record-type, stage, vertical, firm and email-status breakdowns; representative investors; stop reason; and artifact keys.
• RUN-SUMMARY.html: Human-readable report of the main status, totals, research coverage and representative profiles.

RUN-SUMMARY-ERROR can appear only when the JSON summary succeeds but the HTML report cannot be saved. Summary reporting is best-effort and never adds records to the default dataset.

Use the JSON summary as a run receipt for automated completion checks, recurring-run comparisons and workflow routing. Use the HTML report for operator review before exporting or importing the dataset. This actor does not create an interactive map because its public record contract does not contain geographic coordinates.

Field Reference

Record identity and source

• recordType (string, required): Record family; currently investor.
• investorId (string, required): Source-provided investor identifier.
• source (object, required): Public provenance and collection context.
• source.sourceList.slug (string, optional): URL slug for the source investor list.
• source.sourceList.stage (string or null, optional): Published stage represented by the list.
• source.sourceList.vertical (string or null, optional): Published sector represented by the list.
• source.profileUrl (URL string, optional): Public Signal investor-profile link.
• source.crawledAt (date-time string, optional): UTC record collection timestamp.

Email enrichment

• email (string or null, optional): Accepted work-email candidate when enrichment succeeds.
• emailStatus (string or null, optional): Email classification such as valid or risky; null can mean enrichment was disabled or no accepted address was found.

Person

• person (object, required): Investor identity and professional context.
• person.personId (string or null, optional): Source-provided person identifier.
• person.fullName (string, optional): Published investor display name.
• person.firstName / person.lastName (string or null, optional): Published name components.
• person.slug (string or null, optional): Public profile slug.
• person.headline (string or null, optional): Published professional headline.
• person.roles (array of strings, optional): Published role labels in source order.
• person.voteCount (integer or null, optional): Source-displayed platform vote count, not an investment-quality score.

Firm

• firm (object, optional): Published investment-firm context.
• firm.firmId (string or null, optional): Source-provided firm identifier.
• firm.name (string or null, optional): Published firm display name.
• firm.slug (string or null, optional): Published firm slug.
• firm.currentFundSize (string or null, optional): Source-displayed fund-size label, preserved as published.

Investment preferences

• investmentPreferences (object, optional): Published position, check-size and location preferences.
• investmentPreferences.position (string or null, optional): Published investor position.
• investmentPreferences.checkSize.min (number or null, optional): Published minimum investment amount.
• investmentPreferences.checkSize.max (number or null, optional): Published maximum investment amount.
• investmentPreferences.checkSize.target (number or null, optional): Published target investment amount.
• investmentPreferences.locations (array of strings, optional): Published geographic investment preferences.

Contact links

• contact (object, optional): Public website and social-profile links.
• contact.website (URL string or null, optional): Published investor or firm website.
• contact.linkedin (URL string or null, optional): Published LinkedIn profile.
• contact.twitter (URL string or null, optional): Published X or Twitter profile.
• contact.crunchbase (URL string or null, optional): Published Crunchbase profile.
• contact.angellist (URL string or null, optional): Published AngelList profile.
• contact.facebook (URL string or null, optional): Published Facebook profile.

Lists and background

• lists (array of objects, optional): Other associated Signal lists; each item can contain stage, slug and vertical.
• background.education (array of objects, optional): Published education entries.
• background.education[].degree (string or null, optional): Degree label.
• background.education[].fieldOfStudy (string or null, optional): Field of study.
• background.education[].school.name / displayName (string or null, optional): School names.
• background.education[].school.studentCount (integer or null, optional): Source-provided platform count, not verified enrollment.
• background.experience (array of objects, optional): Published work-history entries.
• background.experience[].title (string or null, optional): Position title.
• background.experience[].company.name / displayName (string or null, optional): Company names.
• background.experience[].company.employeeCount (integer or null, optional): Source-provided platform count, not verified headcount.
• background.experience[].start.month / end.month (integer or null, optional): Partial start or end month.
• background.experience[].start.year / end.year (integer or null, optional): Partial start or end year.

Portfolio

• portfolio.summary.investmentCount (integer or null, optional): Published count of known investments.
• portfolio.summary.hasMore (boolean, optional): Whether the source indicates more investments than are included.
• portfolio.investments (array of objects, optional): Published investment entries.
• portfolio.investments[].company (string or null, optional): Portfolio-company name.
• portfolio.investments[].totalRaised (array, optional): Source-provided fundraising values; item shape can vary.
• portfolio.investments[].coinvestors (array of strings, optional): Published co-investor names.
• portfolio.investments[].rounds (array of objects, optional): Known funding-round context.
• portfolio.investments[].rounds[].stage (string or null, optional): Published round stage.
• portfolio.investments[].rounds[].date (string or null, optional): Source-provided round date.
• portfolio.investments[].rounds[].amount (number, string or null, optional): Published round amount in its source-provided numeric or formatted representation.
• portfolio.investments[].rounds[].isLead (boolean or null, optional): Whether the investor is identified as a lead.

Network

• network.coinvestorsInvestors (array of objects, optional): Published co-investor profiles.
• network.coinvestorsScoutsAndAngels (array of objects, optional): Published scout and angel profiles.
• network.*[].investorId (string or null, optional): Network investor identifier.
• network.*[].person (object, optional): Network person ID, name components and slug.
• network.*[].firm (object, optional): Network firm ID, name and slug.
• network.*[].position (string or null, optional): Published position.
• network.*[].imageUrls (array of URL strings, optional): Published profile images.
• network.connections (array of objects, optional): Published investing connections.
• network.connections[].targetPerson (object, optional): Connected person name and slug.
• network.connections[].targetFirm (object, optional): Connected firm name and slug.

Media, images and counts

• media (array of objects, optional): Published media links with url, title and imageUrl.
• images.profile (array of URL strings, optional): Published profile-image URLs.
• counts (object, optional): Actor-generated entry counts for the main grouped arrays.
• counts.degrees (integer, optional): Number of education entries.
• counts.positions (integer, optional): Number of experience entries.
• counts.lists (integer, optional): Number of associated-list entries.
• counts.portfolioInvestments (integer, optional): Number of included portfolio investments.
• counts.connections (integer, optional): Number of investing connections.
• counts.networkInvestors (integer, optional): Number of investor co-investors.
• counts.networkScouts (integer, optional): Number of scout and angel co-investors.

Data Model Notes

• Identity: Use investorId + source.sourceList.slug for list-specific upserts. Use investorId alone when maintaining one cross-list investor entity.
• Provenance: source.profileUrl links to the public investor profile, while source.sourceList identifies the selected list that produced the row.
• Research attributes: person, firm and investmentPreferences contain the primary identity and targeting fields.
• Nested context: background, portfolio, network, media and images keep related public attributes grouped for JSON-first ETL.
• Optional values: Null-check profile detail, contact, email, preference and research fields; an empty array means no entries were included, not necessarily that none exist.
• Point-in-time signals: Vote counts, roles, firm context, check sizes, portfolio entries and contact information can change after collection.
• Repeated runs: Compare records by stable identity and use source.crawledAt plus Apify run metadata to establish observation time.

Data Quality, Guarantees, And Handling

• Structured records: Results are normalized into predictable JSON objects for downstream use.
• Field preservation: Meaningful schema-supported investor values are kept in stable public fields or grouped objects; optional source values can still be absent for a specific profile.
• Best-effort collection: Fields can vary by public availability, profile completeness, visibility and source-side changes.
• Optional fields: Null-check optional values in downstream code, dashboards and AI workflows.
• Deduplication: Use investorId + source.sourceList.slug for list-specific records or investorId for a cross-list investor entity.
• Freshness: Results reflect publicly available information observed at run time.
• Repeated runs: Use the recommended identity key when synchronizing into warehouses, CRMs, search indexes, vector stores or monitoring systems.
• Schema awareness: Rely on documented fields and handle newly missing optional fields gracefully.
• Run receipts: Use RUN-SUMMARY and RUN-SUMMARY.html to audit status, counts, enrichment outcomes and research coverage without treating them as dataset records.

Tips For Best Results

• Start with one list and a small limit before running a broader research job.
• Inspect several records because profile-detail availability varies.
• Use separate runs when each investor list requires independent quotas or trend history.
• Preserve source.sourceList.slug when combining list exports.
• Enable email enrichment only when the workflow requires it.
• Route risky email results to human review or disable them with includeRiskyEmails.
• Use stable identifiers rather than names for deduplication.
• Review the run summary before importing records into a production CRM or warehouse.

How to Run on Apify

1. Open the actor in Apify Console.
2. Add one or more public Signal investor-list URLs.
3. Set the maximum number of investor profiles.
4. Configure optional email enrichment or MCP delivery.
5. Click Start, then inspect the first dataset records and run summary.
6. Download results in JSON, CSV, Excel or another Apify-supported format.

Agentic And API-First Usage

The actor can serve as a structured public investor-research step inside fundraising, market-intelligence and data-enrichment workflows. Its bounded input surface, stable record family, nested field reference and run receipts make it suitable for systems that need predictable evidence rather than unstructured page text.

Agent workflow pattern

1. Generate or select one or more supported Signal investor-list URLs.
2. Choose a validation limit and email policy.
3. Run the actor manually, on a schedule or through Apify platform automation.
4. Wait for completion and read the dataset records.
5. Validate records against the field reference and read the run summary for status, counts, duplicates and enrichment outcomes.
6. Upsert list-specific records using investorId + source.sourceList.slug.
7. Trigger investor qualification, CRM enrichment, market analysis, alerts, search indexing or human review.

For reliable agentic use:

• Keep prompts and automations grounded in the documented input parameters.
• Start with small validation runs before allowing larger automated collection.
• Provide downstream AI steps with the field reference and one representative record.
• Provide RUN-SUMMARY when an agent needs to reason about completion and record counts.
• Treat missing optional values as null or unavailable rather than asking an agent to infer them.
• Store the Apify run ID, input configuration and export metadata alongside the downstream batch.
• When context is limited, pass the input schema, idempotency key, field reference and representative example instead of the full README.

Scheduling & Automation

Scheduling

Automated Data Collection

Schedule runs to refresh investor research for a consistent set of Signal lists. Keep the input configuration stable when the goal is change detection.

1. Navigate to Schedules in Apify Console.
2. Create a daily, weekly or custom schedule.
3. Configure the list URLs, limit and enrichment policy.
4. Enable notifications for run completion.
5. Add webhooks when another system should process completed runs.

Integration Options

• CRM enrichment: Sync investor identity, firm, role, public links and accepted email results into account or contact records.
• Warehouses and BI: Analyze list representation, stage, sector, firm and email coverage across recurring runs.
• Webhooks: Trigger validation, ingestion, notification or review workflows after completion.
• Google Sheets or Airtable: Review smaller investor lists collaboratively before CRM import or outreach.
• Search and vector indexes: Make public investor profiles discoverable for internal research and retrieval workflows.
• MCP connectors: Authorize a compatible connector in Apify, select it in the actor input and receive the compact run summary and Apify output links in the destination tool.
• API-driven ETL: Consume JSON records and run receipts from automated data pipelines.

Export Formats And Downstream Use

Apify datasets can be exported for manual review or consumed by downstream systems:

• JSON: Best for APIs, applications, AI agents and data pipelines that preserve nested fields.
• CSV or Excel: Useful for spreadsheet review, stakeholder handoff and lightweight analysis.
• API access: Supports automated ingestion into internal systems.
• BI and warehouses: Supports reporting, historical analysis and recurring research monitoring.
• Search or vector indexes: Supports investor discovery, semantic retrieval and agent context.

Downstream Pipeline Guide

• Idempotency: Use investorId + source.sourceList.slug for list-specific upserts.
• Null handling: Treat optional email, firm, preference, contact and profile-detail fields as nullable.
• Type handling: Preserve numbers, booleans, arrays and nested objects in JSON-first systems.
• Flattening: Flatten nested fields deliberately for CSV or Excel and retain the original JSON export for full fidelity.
• Partitioning: Store run date, source-list slug and workflow name alongside each downstream batch.
• Change detection: Compare repeated records by stable key and selected fields such as firm, role, preferences, email status, portfolio count and public links.
• Quality checks: Monitor saved count, duplicate count, required IDs, full-name availability and fill rates for fields important to your workflow.
• Human review: Route records with missing critical targeting fields, risky emails or unusual changes into a review queue.
• Retention: Choose separate retention policies for raw exports, normalized tables and outreach systems.

Performance And Coverage Expectations

No production benchmark is published in this README. Runtime depends on the number and size of selected lists, the requested limit, public profile availability, profile-detail density and whether email enrichment is enabled. A highly focused validation run can finish sooner than a large multi-list research run, while email-enriched or detail-rich runs can take longer.

Treat the requested limit as an output ceiling, not a promise that the selected lists contain that many available unique profiles. Use the saved-record count, duration, stop reason and breakdowns in RUN-SUMMARY as the measured evidence for each completed run. The actor does not claim fastest execution, complete investor coverage or lossless source reproduction.

Limitations

• Results depend on what Signal by NFX publicly exposes at run time.
• Optional profile, firm, contact, portfolio, network and background fields can be null or empty.
• The requested limit can exceed the number of available unique profiles.
• The same investor can appear in multiple lists and should be reconciled according to the intended data model.
• Published roles, preferences, portfolio information, vote counts and contact links can become stale.
• Email enrichment can be disabled, unavailable or unable to produce an accepted address.
• The dataset supports research and workflow operations; it does not provide investment, legal or outreach-compliance advice.

Troubleshooting

• No results returned: Confirm that each input is a public Signal URL under /investor-lists/ and that the list currently contains visible profiles.
• Fewer results than expected: Check whether the list has enough unique profiles and whether the total limit is shared across multiple URLs.
• Some fields are empty: Optional fields depend on the information publicly available for each profile.
• Duplicate-looking investors: Compare investorId and source.sourceList.slug; the same investor can legitimately occur in multiple selected lists.
• Run takes longer than expected: Lower the validation limit, use fewer lists or disable email enrichment.
• Email is null: Check whether enrichment was enabled and review emailStatus plus the run-level enrichment status.
• Output changed: Compare current records with the field reference and retain a small sample for support.
• Downstream import failed: Check JSON validity, nullable fields, nested objects and whether the destination requires flattened columns.

FAQ

What data does this actor collect?

It collects public investor identity, firm, role, stage, sector, check-size, location, contact, list, background, portfolio, network, media and optional accepted-email context when available.

Can I search by arbitrary name, firm, location or keyword?

No. The public input contract accepts Signal investor-list URLs rather than arbitrary search filters. Choose a list whose published scope matches the research question.

Why did I receive fewer records than my limit?

The limit is a maximum. A list can contain fewer available unique profiles, and duplicates across inputs do not create extra records for the same list-specific key.

How should I choose a limit for my first run?

Start with approximately 10 records, inspect several outputs and increase the limit after confirming field coverage and downstream mappings.

What is the best unique key?

Use investorId + source.sourceList.slug for list-specific records. Use investorId alone only when maintaining one consolidated investor entity across lists.

Where can I find the run summary?

Open the actor run’s outputs in Apify. RUN-SUMMARY provides machine-readable JSON, while RUN-SUMMARY.html provides a human-readable report.

Does the actor create an interactive map?

No. The investor record contract does not expose coordinates, so the actor does not publish a map artifact.

Can I schedule recurring runs?

Yes. Use Apify Schedules with a stable list and enrichment configuration, then compare records by the recommended key.

Can I use the output with AI agents?

Yes. Provide the agent with the input contract, field reference, representative record and run summary, and require nullable-field handling.

Can I export the data to CSV, Excel or JSON?

Yes. Apify dataset exports support these common review and pipeline formats.

What does MCP delivery send?

It sends a compact run summary and available Apify dataset and report links through a compatible selected connector. It does not send the full investor dataset by default.

What should I include when reporting an issue?

Include the redacted input, Apify run ID, expected and actual behavior, a small output sample when helpful and the downstream destination or export format for pipeline issues.

Compliance & Ethics

Responsible Data Collection

This actor collects publicly available investor and venture-market information from Signal by NFX for legitimate business purposes, including:

• Venture and fundraising research
• Investor-directory and ecosystem analysis
• CRM enrichment and operational data workflows

Users are responsible for ensuring that collection, storage, enrichment and use comply with applicable laws, regulations and the source site’s terms. This section is informational and not legal advice.

Best Practices

• Use collected information in accordance with applicable laws, regulations and the target site’s terms.
• Respect individual privacy and personal information.
• Use the actor responsibly and avoid disruptive or excessive collection.
• Do not use the dataset for spam, harassment, discrimination or other harmful purposes.
• Apply relevant data-protection, electronic-communications, consumer-protection and sector-specific requirements.
• Review retention, access-control and data-sharing policies before operationalizing the dataset.

Support

Use the Issues area on the actor page to ask for help. Include the redacted input, Apify run ID, expected versus actual behavior and a small output sample when useful. For pipeline-related issues, also include the downstream destination or export format and whether nested or nullable fields were transformed.