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:- Retrieve the search schema from a previous run and load the original enrichment request payloads from your own storage
- Create a new run using that schema, with an exclude list of previously discovered candidates
- Reapply enrichments using the original saved request payloads through the enrichment endpoint
- 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 itsobjective, entity_type, match_conditions, generator, and match_limit:
The schema response also omits the original run’s
metadata and webhook. Supply new values when creating the refreshed run if you need them.Step 2: Create a New Run and Replay Saved Enrichment Requests
Use the retrieved search criteria to create a new FindAll run, adding anexclude_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
Theexclude_list is an array of candidate objects to exclude. Each object contains:
How exclusions work:
- Candidates matching any entry in the
exclude_listwill be skipped during generation - This prevents those entities from being returned or evaluated in the refreshed run
- FindAll uses both
nameandurlto 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 theexclude_list from previous runs, retrieve candidates and extract their name and url fields:
cURL
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 keepmatch_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
/enrichafter creating the new run match_limit: Adjust based on expected growth rategenerator: 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_limitvalues initially, then extend if needed - Preview first: Test schema changes with preview before running full jobs
- Monitor metrics: Track
generated_candidates_countvsmatched_candidates_countto optimize criteria
Related Topics
- 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