Skip to main content
For AI agents: a documentation index is available at https://docs.parallel.ai/llms.txt. The full text of all docs is at https://docs.parallel.ai/llms-full.txt. You may also fetch any page as Markdown by appending .md to its URL or sending Accept: text/markdown.

Overview

Scheduled jobs allow you to run the same FindAll query on a regular basis to discover newly emerging entities. This is useful for ongoing discovery workflows such as market intelligence, lead generation, and competitive tracking. Rather than manually re-running queries, you can programmatically create new FindAll runs using a previous run’s schema, while excluding candidates you’ve already discovered.

Use Cases

Scheduled FindAll jobs are particularly useful for:
  • Market monitoring: Track new companies entering a market space over time
  • Lead generation: Continuously discover new potential customers matching your criteria
  • Competitive intelligence: Discover emerging competitors
  • Investment research: Track new companies meeting specific investment criteria
  • Regulatory compliance: Discover new entities that may require compliance review

How It Works

Creating a scheduled FindAll job involves three steps:
  1. Retrieve the search schema from a previous run and load the original enrichment request payloads from your own storage
  2. Create a new run using that schema, with an exclude list of previously discovered candidates
  3. Reapply enrichments using the original saved request payloads through the enrichment endpoint
This approach ensures:
  • Consistent criteria: Reuse the same objective, entity type, and match conditions across runs
  • Fewer repeats: Exclude candidates returned by earlier runs
  • Focused discovery: Direct each new run toward candidates that are not already in your saved exclusion set

Step 1: Retrieve the Search Schema

Get the schema from an existing FindAll run to reuse its objective, entity_type, match_conditions, generator, and match_limit:
The schema response is not a lossless store of the original /enrich requests. In particular, MCP server configuration can be omitted or redacted. When you first call /enrich, persist the exact request payload in secure application storage and replay that saved payload for refresh runs. Do not treat schema.enrichments as the source of truth for requests that may contain mcp_servers or other sensitive configuration.
The schema response also omits the original run’s metadata and webhook. Supply new values when creating the refreshed run if you need them.
Response:

Step 2: Create a New Run and Replay Saved Enrichment Requests

Use the retrieved search criteria to create a new FindAll run, adding an exclude_list parameter to skip candidates you’ve already discovered. The create endpoint does not accept enrichments; after creation, send each original enrichment request that you persisted in your application.

Exclude List Parameters

The exclude_list is an array of candidate objects to exclude. Each object contains: How exclusions work:
  • Candidates matching any entry in the exclude_list will be skipped during generation
  • This prevents those entities from being returned or evaluated in the refreshed run
  • FindAll uses both name and url to deduplicate and disambiguate exclusions; use the entity’s official name and canonical URL for best results
  • A request can contain at most 10,000 exclusion entries

Building Your Exclude List

To construct the exclude_list from previous runs, retrieve candidates and extract their name and url fields:
cURL
The example below shows matched candidates:
Store these candidates and pass them as the exclude_list array in subsequent runs. Excluding only matched candidates prevents previous matches from being returned again while allowing earlier nonmatches to be reconsidered as web data changes. If you want the refreshed run to consider only entities that have never reached evaluation, save and exclude every candidate returned by /result instead. Deduplicate the accumulated list before each request and fail explicitly if it exceeds 10,000 entries. Do not silently truncate it: truncation makes the refresh policy dependent on list order and can reintroduce older entities.

Example: Weekly Scheduled Job

Here’s a complete example showing how to set up a weekly FindAll job:

Best Practices

Schema Modifications

While you should keep match_conditions consistent across runs, you can adjust:
  • objective: Update to reflect the current time period (e.g., “founded in 2024” → “founded in 2025”)
  • Enrichment requests: Replay the original request payloads from secure application storage—or add new enrichments—through /enrich after creating the new run
  • match_limit: Adjust based on expected growth rate
  • generator: Change generators if needed (though this may affect result quality)

Exclude List Management

  • Persist candidates: Store discovered candidate objects (name and URL) in a database or file for long-term tracking
  • Deduplicate before sending: Remove repeated name-and-URL pairs before building each request
  • Normalize URLs: Ensure consistent URL formatting (trailing slashes, protocols, etc.) across runs
  • Periodic resets: Consider occasionally running without exclusions to catch entities that may have changed
  • Respect the limit: An exclude list can contain at most 10,000 candidates; define a rotation or reset policy before the saved set reaches that size

Scheduling

  • Frequency: Choose intervals based on your domain’s update rate (daily, weekly, monthly)
  • Off-peak hours: Schedule jobs during low-traffic periods if possible
  • Durable state: Use transactional database storage rather than a local file when multiple scheduler instances may run concurrently
  • Webhooks: Use webhooks to get notified when jobs complete
  • Error handling: Implement retry logic for failed runs

Cost Optimization

  • Start small: Use lower match_limit values initially, then extend if needed
  • Preview first: Test schema changes with preview before running full jobs
  • Monitor metrics: Track generated_candidates_count vs matched_candidates_count to optimize criteria
  • Preview: Test queries with 5–10 evaluated candidates before running full searches
  • Generators and Pricing: Understand generator options and pricing
  • Enrichments: Extract additional structured data for matched candidates
  • Extend Runs: Increase match limits without paying new fixed costs
  • Webhooks: Configure HTTP callbacks for run completion and matches
  • Streaming Events: Receive real-time updates via Server-Sent Events
  • Run Lifecycle: Understand run statuses and how to cancel runs
  • API Reference: Complete endpoint documentation