Choose an Apify Actor by the data contract your workflow needs: source, entity, geography, freshness, input controls, output fields, pricing event, and failure behavior. Popularity is useful evidence, but a narrower Actor with the right fields is often a better production dependency than the most-used general tool.
What should be defined before searching the Store?
Define the output row before choosing the scraper. “We need LinkedIn data” is not specific enough. A workflow might need a company, person, job, post, or video, and each entity requires a different contract.
Write down:
- the source platform;
- the entity type;
- required fields;
- country, language, or location;
- maximum acceptable age;
- expected volume per run and per month;
- source URL retention;
- storage and downstream format;
- compliance or access constraints.
That short specification prevents a common failure: selecting an Actor because its title matches the platform while its output does not match the workflow.
When is a multi-source Actor the right choice?
Use a multi-source Actor when schema consistency and geographic breadth matter more than source-specific depth. The main advantage is not simply “more sites.” It is one normalized output contract across multiple routes.
AgentX currently offers broad orchestrators for several data families:
- All Jobs Scraper for standardized hiring data across job platforms.
- All Property Scraper for real estate discovery across regional listing sources.
- All Shopping Scraper for marketplace and retail product search.
- All Vehicle Scraper for country-aware vehicle marketplaces.
- All Video Scraper for mixed-platform video downloads and metadata.
A focused Actor is better when one source has fields or controls that the normalized schema cannot preserve. For example, Glassdoor Jobs Scraper is the more direct starting point when the workflow specifically depends on Glassdoor salary and company context.
Which parts of the Actor page are contractual?
Treat the live Actor page, input schema, README, pricing configuration, and sample output as one contract. If those surfaces disagree, validate before integration.
Apify’s own guidance explains how Actor documentation should describe the use case, inputs, outputs, limits, and examples. Review the official Actor README guidance and SEO guidance for Actors when evaluating how clearly a product explains itself.
Check these details:
- Input types: keywords, URLs, IDs, locations, dates, or authenticated sessions.
- Bounds: minimum and maximum results, comments, profiles, or files.
- Output shape: top-level fields, nested arrays, nullable fields, and failure rows.
- Pricing: compute usage, per-result events, one-time events, and tier differences.
- Storage: Dataset rows, key-value files, and retention assumptions.
- Status semantics: whether partial work returns data, fails the run, or reports item-level errors.
Do not copy a price from an editorial article into production code. Read the live pricing panel when approving a run budget.
How should an Actor be tested?
Run the smallest realistic sample and inspect the Dataset, not only the run status. A successful status proves that the process ended normally; it does not prove that the returned entity, fields, dates, and source URLs meet the requirement.
For the first test:
- use one real source or a narrow query;
- set a small result limit;
- capture the exact input;
- inspect every returned field;
- verify source URLs independently;
- record missing and nullable values;
- compare estimated and actual charge events;
- repeat once with a known edge case.
Only increase volume after the sample passes the downstream contract.
How many Actors belong in one workflow?
Use the fewest Actors that cover distinct source families. Multiple Actors can return the same underlying source through different wrappers, so counting tools is not the same as counting independent evidence.
For research, record a source-family key with each result. For automation, define which Actor owns each source and how duplicates are resolved. This prevents a “five-Actor pipeline” from charging five times for near-identical records.
A clear pipeline record includes:
| Field | Purpose |
|---|---|
sourceFamily | The original platform or dataset family |
originEntityUrl | The page that supports the record |
retrievedAt | The actual collection time |
actorName | The Actor version of the collection route |
inputHash | A key for repeatability and caching |
estimatedCost / actualCost | Budget control and comparison |
Where should a team start in the AgentX catalog?
Start with the domain filter, then compare one orchestrator with one focused Actor. BestCrawler’s complete Actor catalog renders every public AgentX Store entry and links directly to the live product page.
For common workflows:
- hiring data: compare All Jobs with the relevant job-board Actor;
- social research: begin with the exact profile, post, community, or member entity;
- video knowledge: compare Video Transcript with the platform-specific transcript Actor;
- commerce or property: use a broad orchestrator for discovery and a dedicated source for deeper validation;
- agent workflows: confirm the current MCP or API integration on the Actor page.
Selection is complete only when the live contract and a real Dataset row both satisfy the original requirement.
Continue in the directory
Turn the guide into a real sample run.
Open the current AgentX contract, check pricing and fields, then validate a narrow output.