Jina Reader vs Apify

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Apify
   Jina Reader~partialprobed5/10

   Jina Reader's core function—converting any URL to LLM-friendly markdown (r.jina.ai/<url>)—technically lets an agent fetch llms.txt or agent-oriented docs pages and get clean text, and the 'research' preset is explicitly aimed at AI research agents needing structured, citable output. But there is no evidence of llms.txt-specific parsing/discovery, sitemap-style agent doc crawling, or first-party guidance for this workflow, and a probe shows Jina's own site lacks an llms.txt (404), undercutting any implied endorsement of the convention. missing for 10: explicit llms.txt/agent-doc support or examples, first-party documentation naming this use case, evidence Jina practices llms.txt on its own docs.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”

   proof ↗⚑ flag

   Apify✓fullprobed9/10

   A direct probe confirms llms.txt is live at docs.apify.com/llms.txt returning HTTP 200 with structured agent-oriented documentation content, and the docs also expose an OpenAPI spec and dedicated MCP integration docs for agent discovery. Missing for 10: independent third-party confirmation that agents successfully consume/parse the llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”
   • [claimed-docs] “Discover and use Actors with AI agents and LLMs via Apify MCP server.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Apify
   Jina Reader~partialcommunity6/10

   Jina Reader is a plain HTTP endpoint and also ships a self-hostable Docker image bundling headless Chrome/LibreOffice, making it straightforward to script and run in CI pipelines (curl, headers for output control). However, community reports show real-world automation attempts hitting 401/404 errors, and there is no first-party CI/automation guide or examples. missing for 10: explicit CI/CD documentation or examples, rate-limit/reliability guarantees for unattended use, and resolution of the reported auth/404 failures in automated contexts.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   proof ↗⚑ flag

   Apify✓fullprobed8/10

   Apify provides a CLI for scripting/terminal control (apify-docs-3, apify-probe-4), scheduling for automated runs (apify-docs-6), an OpenAPI-backed REST API (apify-probe-2), and Actors designed as headless automation units runnable via SDKs/CLI, all consistent with CI/headless automation use. missing for 10: explicit CI/CD pipeline integration examples (e.g., GitHub Actions) or independent hands-on confirmation of CI usage.

   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [claimed-docs] “Develop your own Actor”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Apify
   Jina Reader✓fullprobed7/10

   Jina explicitly documents an official MCP server repository (jina-ai/MCP) that would expose Reader's capabilities to agents, but the evidence pack lacks first-party details on setup, tool list, or hands-on/independent corroboration of its use. missing for 10: detailed MCP server docs/tool schema, hands-on or community verification of the MCP server working end-to-end.

   • [probe] “official MCP server documented at https://github.com/jina-ai/MCP”

   proof ↗⚑ flag

   Apify✓fullprobed8/10

   Apify documents an official MCP server enabling AI agents/LLMs to discover and use Actors, confirmed both in docs and a direct probe of the dedicated MCP integration page. Missing for 10: independent/hands-on third-party corroboration of the MCP server working in practice.

   • [claimed-docs] “Discover and use Actors with AI agents and LLMs via Apify MCP server.”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Apify
   Jina Reader—none0/10

   The evidence pack shows Jina Reader as an HTTP API/service (curl-based usage, headers like x-respond-with, x-preset) and a self-hostable Docker image, but there is no mention of an official dedicated CLI tool for interacting with Reader. No evidence names a packaged command-line binary or npm/pip CLI client.

   ⚑ flag

   Apify✓fullprobed8/10

   Apify ships an official CLI (apify-cli) documented at docs.apify.com/cli, explicitly described as a tool to "Control the Apify platform from terminal or shell scripts," covering Actor development, deployment, and automation workflows relevant to AI-native/agentic use. missing for 10: independent hands-on community validation specifically of CLI usage (comments reference SDK/product broadly, not CLI specifics).

   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Develop your own Actor”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Apify
   Jina Reader✓fullprobed8/10

   Jina Reader ships an extensively documented public HTTP API (r.jina.ai) with numerous header-controlled options (output format, presets, chunking, cookies, JSON schema extraction, proxy routing) all detailed in first-party GitHub docs, directly enabling programmatic/agentic use. Missing for 10: a discoverable machine-readable spec (OpenAPI/swagger probes returned 404, llms.txt 404), and independent confirmation beyond community auth-error reports which reflect expected key requirements rather than API failure.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify✓fullprobed9/10

   Apify provides a documented public REST API with an OpenAPI spec (verified live at docs.apify.com/api/openapi.json), plus a CLI for scripting the platform and official docs describing programmatic control, giving AI-native users clear, verifiable ways to drive the product via API. Missing for 10: independent third-party corroboration of API robustness/completeness beyond Apify's own docs and probes.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [claimed-docs] “Develop your own Actor”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of scoped or least-privilege API key/credential issuance for agents; the pack only shows a single API key auth requirement and no mention of scoped tokens, permissions, or credential management.

   ⚑ flag

   Apify—none0/10

   No evidence of scoped or least-privilege API token/credential issuance for agents—docs mention permissions management for organizations and MCP integration but nothing about granular/scoped API keys or credential minimization for agent use.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Apify
   Jina Reader—none0/10

   The evidence pack documents Jina Reader purely as an HTTP endpoint (curl-style requests with custom headers like x-respond-with, x-preset, x-json-schema) and an OpenAPI/llms.txt probe that both 404'd — there is no mention of an official Python/JS/other SDK package for building against it.

   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify✓fullprobed8/10

   Apify offers official SDKs for JavaScript/Python plus Crawlee, documented developer toolkits, a CLI, an OpenAPI spec, and an MCP server enabling AI agents to build against official interfaces, with community corroboration of SDK adoption. Missing for 10: deeper independent benchmarking of SDK quality/completeness beyond community praise and more explicit versioned SDK reference docs in the pack.

   • [claimed-docs] “Software toolkits for developing new Actors.”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [community] “I'm a huge fan of Apify and look forward to exploring this new SDK. Thanks y'all.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence anywhere in the pack of Jina Reader supporting webhooks or event subscriptions; it's a synchronous URL-to-text conversion API with no mention of push/callback mechanisms.

   ⚑ flag

   Apify—none0/10

   The evidence pack never mentions webhooks explicitly; only vague references to alerts and monitoring (apify-docs-7) exist, with no documentation of webhook subscription or event triggers. Missing for 10: any docs on webhook creation, event types, subscription API, or delivery guarantees.

   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify—none0/10

   Evidence covers Actor development, monitoring/alerts, MCP server for AI agents to use Actors, and CLI/API access — but nothing shows the product itself generating AI insights or suggestions from a user's scraped/collected data. Missing for 10: any feature describing AI-generated summaries, insights, or recommendations derived from data collected in Apify.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify✓fullprobed8/10

   Apify supports scheduling Actors/tasks to run automatically at specific times, plus monitoring and alerting for background runs, and a CLI/API for orchestration—covering autonomous background automation. Missing for 10: independent hands-on validation of scheduling reliability and no explicit mention of event/webhook-triggered (vs. time-triggered) autonomous runs.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify—none0/10

   Evidence shows Apify exposes an MCP server so external AI agents can call Apify's Actors, but there is no mention of a built-in AI assistant inside the Apify product itself that users can delegate tasks to.

   • [claimed-docs] “Discover and use Actors with AI agents and LLMs via Apify MCP server.”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Jina Reader~partialclaimed6/10

   The `x-instruction` header lets users give natural-language instructions to extract specific fields (via ReaderLM-v2), and the `x-preset: research` bundle is tailored for AI agents, showing some natural-language-driven operation. However, this is limited to extraction/formatting rather than full natural-language control of the whole reading/search pipeline, and there's no independent corroboration of reliability. Missing for 10: broader NL control across all Reader operations (search, fetch, formatting) and third-party validation that x-instruction works robustly.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”

   proof ↗⚑ flag

   Apify~partialprobed6/10

   Apify documents an official MCP server enabling AI agents/LLMs to discover and invoke Actors via natural-language-driven agent tooling, which is the core mechanism for natural-language operation, plus an llms.txt for AI discoverability. However, there's no direct evidence of a natural-language interface within Apify's own console/CLI itself (the CLI is a traditional command-line tool, not NL-driven), so operation relies on pairing with an external agent. Missing for 10: first-party natural-language chat/assistant interface in the platform itself, hands-on demonstration of NL commands working end-to-end via MCP, independent corroboration of MCP usability.

   • [claimed-docs] “Discover and use Actors with AI agents and LLMs via Apify MCP server.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

5. ai-native userApply a preset configuration tuned for research agents that returns structured, citable output

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   The `x-preset: research` option is explicitly documented as being 'for AI research agents needing structured, citable output,' directly matching the story, and complements related features like frontmatter/YAML output and JSON schema extraction for structured data. Missing for 10: independent or hands-on verification that the research preset's output quality/citability holds up in practice beyond the first-party docs.

   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence of a preset configuration tuned for research agents that yields structured, citable output; Apify's evidence covers general Actor development, MCP server access, CLI, and marketplace but nothing about a research-agent-specific preset or citation-formatted output.

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Apify
   Jina Reader—none0/10

   There is no evidence of an interactive API reference or runnable examples; probes explicitly found no OpenAPI/swagger spec (404s) and no llms.txt, and the documentation snippets only describe headers/params in prose form, not an interactive playground.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify~partialprobed6/10

   Apify publishes an OpenAPI spec (confirmed live at docs.apify.com/api/openapi.json) which underlies an API reference, and general docs exist, but there's no direct evidence of an interactive reference UI with runnable/try-it examples (e.g., a Swagger/Redoc try-it console) being confirmed. Missing for 10: explicit evidence of an interactive 'try it out' console, runnable code snippets in the API reference, or community confirmation of using such a feature.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [claimed-docs] “Develop your own Actor”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Apify
   Jina Reader—none0/10

   Direct probes for OpenAPI/Swagger spec files and llms.txt all returned 404, and no evidence pack item shows a downloadable machine-readable API spec being published.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify✓fullprobed9/10

   A probe confirms a valid OpenAPI spec is publicly downloadable at docs.apify.com/api/openapi.json, and this is complemented by official CLI and MCP integration docs enabling machine-driven access. Missing for 10: independent third-party confirmation of spec completeness/versioning beyond the probe.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify—none0/10

   No evidence pack items mention a sandbox environment, staging mode, or separation from production data for testing Actors; docs cover development, CLI, MCP, scheduling, monitoring but nothing about a sandbox/test environment isolated from production data.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Jina Reader—none0/10

   There is no evidence of API versioning (e.g., /v1/ paths) or a published deprecation policy; probes for OpenAPI spec and llms.txt both 404, and no docs mention version lifecycle commitments. missing for 10: versioned endpoint scheme, documented deprecation/sunset policy, changelog or migration guide.

   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify—none0/10

   Evidence shows Apify has an OpenAPI spec, docs, CLI, and MCP server, but nothing indicates a documented API versioning scheme or a deprecation policy for breaking changes. Missing for 10: explicit API version numbers/paths, a published deprecation/sunset policy, changelog or migration guidance for breaking changes.

   ⚑ flag

5. data-engineerThe documented rate limit (requests per second or minute) enforced on my API key before throttling kicks in

   weight 3 · round drawn
   Jina Reader—none0/10

   Community evidence explicitly states the website does not mention an API rate limit, and probes for API spec/docs (openapi, llms.txt) return 404s, so no documented RPS/RPM throttling threshold is available.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”
   • [probe] “PROBE llms.txt: HTTP 404 at https://jina.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://jina.ai/openapi.json, https://jina.ai/swagger.json, https://jina.ai/api/openapi.json, https:…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack item documents specific rate-limit numbers (requests per second/minute) for the Apify API; only general docs, CLI, MCP, and community sentiment are present, with no mention of throttling thresholds per API key.

   ⚑ flag

Block evasion

1. ai-native userHave an agent automatically get past a CAPTCHA, login, or form wall without my manual intervention

   weight 2 · round to Jina Reader
   Jina Reader~partialclaimed3/10

   Reader's SaaS proxy claims to 'handle common anti-bot challenges automatically' and supports forwarding session cookies via X-Set-Cookie for login-walled pages, but neither is documented as solving CAPTCHAs, and cookie-based login still requires the user to manually obtain and supply valid session cookies beforehand. Missing for 10: explicit CAPTCHA-solving capability, fully automatic login/form-wall traversal without any pre-supplied credentials, and independent evidence confirming these anti-bot claims work in practice.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”

   proof ↗⚑ flag

   Apify—none0/10

   Apify's evidence covers proxy rotation to avoid IP-based blocking (apify-docs-8) and general Actor/browser automation tooling, but nothing documents automatic CAPTCHA solving, login handling, or form-wall bypass as a built-in capability. Missing for 10: any explicit CAPTCHA-solving feature, documented login/session automation, or evidence of autonomous form-wall bypass without user intervention.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”

   proof ↗⚑ flag

2. data-engineerAutomatically retry through a chain of different proxies when anti-bot detection blocks a request

   weight 2 · round to Apify
   Jina Reader~partialclaimed4/10

   Jina Reader offers a single hosted proxy option (`x-proxy: auto`) that rotates residential/datacenter IPs and handles common anti-bot challenges, but there is no evidence of an automatic retry mechanism chaining through multiple distinct proxy providers/configs on failure. missing for 10: documented retry/fallback logic across a chain of different proxies, evidence of automatic re-attempt after a block, independent confirmation of anti-bot bypass success.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify~partialclaimed5/10

   Apify documents smart proxy rotation across datacenter and residential IPs to avoid blocking, which supports proxy chaining, but there's no explicit evidence of an automated retry mechanism that specifically triggers on anti-bot detection and cycles through proxies as a chain. missing for 10: documented automatic retry logic tied to anti-bot/block detection, evidence of configurable retry chains, independent confirmation of this workflow in practice.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”

   proof ↗⚑ flag

3. developerUse an undetected browser mode to bypass sophisticated bot detection systems

   weight 3 · round drawn
   Jina Reader—none0/10

   Evidence shows a rotating IP proxy pool that 'handles common anti-bot challenges automatically' (x-proxy: auto), but there is no mention of an undetected/stealth browser mode, fingerprint spoofing, or bypassing sophisticated bot detection like Cloudflare/Datadome-style challenges. This is a distinct, more specific capability than generic proxy rotation and is unevidenced.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify—none0/10

   Evidence shows IP rotation/proxy features and browser automation library support (Playwright, Puppeteer, Selenium), but no mention of a specific 'undetected browser' mode or stealth fingerprinting/anti-bot-detection bypass capability.

   ⚑ flag

Proxy rotation

1. developerRequest a proxy from a specific country to get geolocation-appropriate content

   weight 2 · round to Apify
   Jina Reader—none0/10

   Evidence shows a proxy toggle (x-proxy: auto) that rotates residential/datacenter IPs and bypasses anti-bot challenges, but no capability to select or request a proxy from a specific country/geolocation.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify~partialclaimed5/10

   Apify's docs mention proxy rotation to avoid blocking (datacenter and residential IPs) but the evidence pack does not explicitly confirm country-specific/geolocation targeting for proxies. missing for 10: explicit documentation of country-level proxy selection parameters, independent confirmation of geo-targeting accuracy.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”

   proof ↗⚑ flag

2. developerUse premium residential or datacenter proxies to bypass sites that are hard to scrape

   weight 3 · round to Apify
   Jina Reader✓fullclaimed7/10

   Jina Reader offers a hosted SaaS proxy pool (`x-proxy: auto`) that rotates residential/datacenter IPs and auto-handles anti-bot challenges, directly matching the story. Missing for 10: independent/hands-on confirmation of proxy effectiveness against hard-to-scrape sites, and detail on choosing specific proxy types/locations rather than just 'auto'.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify✓fullclaimed8/10

   Apify docs explicitly describe smart rotation of datacenter and residential IP addresses to avoid blocking, directly matching the anti-bot proxy use case, and the platform's marketplace/integration docs corroborate a mature proxy infrastructure. missing for 10: no independent hands-on benchmark or third-party report validating residential proxy success rates against specific hard-to-scrape sites.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Marketplace of 64,279 Actors”

   proof ↗⚑ flag

3. developerRoute requests through a rotating pool of proxy IPs to avoid blocks

   weight 3 · round to Apify
   Jina Reader✓fullclaimed7/10

   Reader documents a hosted proxy feature (`x-proxy: auto`) that rotates residential/datacenter IPs and auto-handles anti-bot challenges, directly matching the story. missing for 10: no independent/hands-on confirmation of rotation behavior or effectiveness against blocks, and no detail on pool size or geographic control.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify✓fullclaimed8/10

   Apify explicitly documents proxy rotation across datacenter and residential IPs to avoid blocking, directly matching the story. Missing for 10: independent/hands-on corroboration of proxy rotation effectiveness and details on configuration/pricing tiers.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”

   proof ↗⚑ flag

4. developerRoute multiple requests through the same proxy IP using a session identifier to maintain a consistent identity

   weight 2 · round drawn
   Jina Reader—none0/10

   Evidence shows a proxy rotation feature (x-proxy: auto) that rotates IPs for anti-bot handling, but there is no mention of a session identifier or sticky-IP mechanism to keep the same proxy IP across multiple requests for a consistent identity.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify—none0/10

   The evidence only shows generic proxy IP rotation (apify-docs-8) but contains no mention of session identifiers, sticky sessions, or maintaining a consistent IP across multiple requests, which is the specific capability the story requires.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Apify
   Jina Reader~partialclaimed4/10

   The search endpoint fetches and converts the top 5 results in one call (jina-reader-gh-2), showing some multi-item processing, but there's no documented bulk/batch API for submitting many arbitrary URLs or files at once beyond single-item POST endpoints (jina-reader-gh-1, jina-reader-gh-3). missing for 10: a dedicated batch/bulk endpoint accepting arbitrary lists of URLs, documented concurrency/rate limits for bulk jobs, and evidence of large-scale automation use.

   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”

   proof ↗⚑ flag

   Apify~partialprobed6/10

   Apify's platform supports running Actors at scale (marketplace of 64k Actors, CLI/API/SDK for scripting, scheduling, proxy rotation), which implies bulk automation across many items/tasks, and the API/OpenAPI + CLI enable programmatic bulk control. However, there's no explicit documentation or example of a bulk-operations API (e.g., batch-running many Actors/items in one call) or dataset-level bulk processing tailored for AI-native usage. missing for 10: explicit bulk/batch API documentation, dataset-scale bulk operation examples, independent verification of bulk performance at scale.

   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify~partialclaimed5/10

   Apify docs show automatic scheduling of Actors/tasks at specific times and performance alerts, which are limited forms of automated triggers, but the evidence pack lacks explicit documentation of a general event-driven rule/webhook system that fires actions on arbitrary platform events (e.g., dataset changes, run status) as an AI-native user would define. Missing for 10: explicit webhook/event-trigger API docs, examples of custom event-condition-action rules, and independent confirmation of event-based (not just time-based) automation.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Apify
   Jina Reader—none0/10

   Jina Reader is a URL-to-text/API conversion service with no evidence of a scheduler, cron-like trigger, or recurring workflow feature; nothing in the evidence pack describes recurring jobs or workflow automation beyond single-shot fetch requests.

   ⚑ flag

   Apify✓fullprobed8/10

   Apify's docs explicitly support scheduling Actors and saved tasks to run automatically at specific times (recurring jobs), plus CLI and API access for programmatic control, fitting AI-native automation workflows. missing for 10: independent hands-on confirmation of scheduling reliability and richer detail on cron-like configuration options.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

Collaboration

1. developerShare scrapers with teammates and manage organizations and role-based permissions

   weight 2 · round to Apify
   Jina Reader—none0/10

   No evidence of team/organization management, shared scraper libraries, or role-based access control features; Jina Reader is a URL-to-text API product with no collaboration or RBAC layer mentioned anywhere in the evidence pack.

   ⚑ flag

   Apify~partialclaimed6/10

   Apify's official docs explicitly mention sharing Actors and managing organizations/permissions, directly matching the story, but the evidence pack only has a single doc title with no detail on role granularity or workflow, and no independent/hands-on corroboration of this feature. Missing for 10: detailed documentation of role-based permission levels, screenshots/hands-on walkthrough, and community confirmation that org/permission management works well in practice.

   • [claimed-docs] “Share Actors with other people, manage your organizations and permissions.”

   proof ↗⚑ flag

Deployment flexibility

1. developerBuild and deploy custom serverless scraping scripts on the platform without managing my own infrastructure

   weight 2 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify✓fullprobed8/10

   Apify's core value proposition is building 'Actors' (custom scraping scripts) deployed serverlessly on their platform, with docs covering development toolkits, SDKs (JS/Python), CLI for terminal control, scheduling, monitoring, and migration guides for existing projects. Community feedback corroborates real-world usage of the platform for custom scraping projects without infrastructure management. Missing for 10: independent hands-on benchmarks of deployment ease/scaling limits, and more recent community validation beyond older HN threads.

   • [claimed-docs] “Develop your own Actor”
   • [claimed-docs] “Software toolkits for developing new Actors.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Learn how to easily move your existing projects to the Apify platform.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [community] “I've used Apifier a lot of times and is the best of all the similar products in the market (or at least the other 4 (?) I've tried).”
   • [community] “I'm a huge fan of Apify and look forward to exploring this new SDK. Thanks y'all.”

   proof ↗⚑ flag

2. developerDeploy the scraping service via a Docker container for production use

   weight 2 · round to Jina Reader
   Jina Reader~partialclaimed6/10

   A prebuilt GitHub Container Registry image bundling headless Chrome, LibreOffice, and CJK fonts is documented, enabling self-hosted Docker deployment without building from source. However, missing for 10: no production deployment guidance (scaling, orchestration, resource sizing), no independent hands-on confirmation of running the container in production, and no docs on configuration/env vars for the containerized service.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   proof ↗⚑ flag

   Apify—none0/10

   None of the evidence explicitly mentions Docker or containerized deployment for Apify Actors; docs reference generic Actor development, toolkits, CLI, and migration guides but never state Docker-based deployment. Missing for 10: explicit Docker/Dockerfile documentation, container registry or image-based deployment workflow, and any hands-on confirmation of Docker usage for production scraping.

   ⚑ flag

3. developerSelf-host an open-source version of the scraper instead of relying on a hosted cloud service

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   GitHub repo explicitly documents an open-source branch with a prebuilt image on GitHub Container Registry bundling headless Chrome, LibreOffice, and CJK fonts so developers can self-host without building from scratch. Missing for 10: independent hands-on report confirming self-hosted deployment works smoothly and details on feature parity vs. the hosted proxy (e.g., anti-bot/x-proxy features noted as SaaS-only).

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”

   proof ↗⚑ flag

   Apify—none0/10

   Apify's evidence shows CLI tooling and local Actor development (apify-docs-3, apify-probe-4), but nothing indicates a fully self-hostable open-source version of the platform as an alternative to the hosted cloud service — Apify's core value proposition remains the managed cloud platform and marketplace. missing for 10: evidence of an open-source self-hosted runtime/platform replacing the cloud service, docs on self-hosting infrastructure, community confirmation of running Apify independently of apify.com.

   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

Integrations

1. developerConnect the scraping API to no-code automation platforms like n8n or Zapier through a prebuilt connector

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of a prebuilt n8n or Zapier connector; the evidence only covers the REST API, headers, self-hosting, and an MCP server, none of which constitute a no-code automation platform connector.

   ⚑ flag

   Apify—none0/10

   No evidence in the pack mentions n8n, Zapier, or any prebuilt no-code automation connector; the docs reference MCP server, CLI, SDKs, and Actor Store but nothing about a no-code platform integration.

   ⚑ flag

Library compatibility

1. developerBuild scrapers using popular open-source automation libraries like Playwright, Puppeteer, Selenium, or Scrapy

   weight 2 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify✓fullclaimed8/10

   Apify explicitly states it works with Playwright, Puppeteer, Selenium, and Scrapy alongside its own Crawlee library, and docs cover Actor development toolkits and migrating existing projects onto the platform. Missing for 10: hands-on independent verification/tutorials specifically showing Selenium or Scrapy actors running end-to-end, and community evidence is thin/tangential on this specific capability.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Develop your own Actor”
   • [claimed-docs] “Software toolkits for developing new Actors.”
   • [claimed-docs] “Learn how to easily move your existing projects to the Apify platform.”

   proof ↗⚑ flag

Migration lock in

1. developerExport my scraped data and job configurations in a portable format to migrate to another provider without lock-in

   weight 3 · round drawn
   Jina Reader—none0/10

   Jina Reader outputs markdown/JSON per request but there is no evidence of exportable job configuration bundles, batch export tooling, or any portability/migration feature; the evidence pack never mentions exporting data or configs for migration. missing for 10: export/download of scraped data sets, job configuration export, migration tooling or documentation.

   ⚑ flag

   Apify—none0/10

   Evidence shows Apify's CLI, API, and docs for migrating projects INTO Apify (apify-docs-11) but nothing about exporting scraped data or job configurations in a portable format to move AWAY from Apify to another provider; Actors/tasks are platform-specific constructs with no documented export-for-migration path.

   • [claimed-docs] “Learn how to easily move your existing projects to the Apify platform.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Quickstart

1. developerPublish my custom scraper to a public marketplace and earn revenue when others use it

   weight 1 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify✓fullclaimed8/10

   Apify explicitly documents publishing Actors to the public Apify Store for 'regular passive income' and has a marketplace of 64k+ Actors, directly matching the story. Missing for 10: independent third-party confirmation of actual developer earnings/payouts and details on revenue-share terms.

   • [claimed-docs] “Publish your Actors on Apify Store and earn regular passive income.”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [claimed-docs] “Share Actors with other people, manage your organizations and permissions.”

   proof ↗⚑ flag

2. developerRun a ready-made scraper from a marketplace instead of building one from scratch

   weight 2 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify✓fullprobed8/10

   Apify Store offers a marketplace of 64,279 ready-made Actors (scrapers) that developers can run directly instead of building from scratch, backed by docs on publishing/sharing Actors and the llms.txt description confirming it as 'the largest marketplace of tools for AI' with 'thousands of ready-made Actors'. Community reviews corroborate real-world usage of pre-built scrapers as a core value proposition. Missing for 10: no hands-on walkthrough evidence of actually running a marketplace Actor end-to-end or independent review specifically praising the marketplace-run experience.

   • [claimed-docs] “Publish your Actors on Apify Store and earn regular passive income.”
   • [claimed-docs] “Share Actors with other people, manage your organizations and permissions.”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”
   • [community] “I've used Apifier a lot of times and is the best of all the similar products in the market (or at least the other 4 (?) I've tried).”

   proof ↗⚑ flag

3. developerStart building immediately using a library of ready-made project templates

   weight 1 · round to Apify
   Jina Reader—none0/10

   Jina Reader is a URL-to-text/API service with usage flags and headers, but there is no evidence of any ready-made project templates or starter kits for developers to bootstrap projects with.

   ⚑ flag

   Apify~partialprobed5/10

   Apify provides a CLI and 'software toolkits for developing new Actors' plus a large marketplace of 64,279 pre-built Actors, which functionally lets developers start from existing building blocks, but the evidence never explicitly documents a curated 'project template' gallery or scaffolding command with named starter templates. Missing for 10: explicit template gallery/documentation, CLI scaffolding command details (e.g., 'apify create' template list), independent confirmation of ease-of-start experience.

   • [claimed-docs] “Software toolkits for developing new Actors.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

Ai extraction

1. developerExtract structured data from a page using natural language instructions instead of writing selectors

   weight 3 · round to Jina Reader
   Jina Reader~partialclaimed6/10

   Jina Reader's docs describe an `x-instruction` header that accepts natural-language extraction instructions (alongside a JSON-schema alternative), directly matching the story of skipping selectors, and this is paired with ReaderLM-v2 for field extraction. However, this is a single first-party doc mention with no independent hands-on validation, extraction accuracy examples, or benchmark, and community threads focus on unrelated auth/JS issues rather than confirming this feature's real-world quality. Missing for 10: independent verification of extraction accuracy, example outputs, and confirmation the feature works reliably outside vendor docs.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence of a natural-language-to-extraction feature; Apify's documented capabilities center on Actors, crawlers, CLI, MCP integration and marketplace, not AI-driven selector-free extraction from prompts.

   ⚑ flag

2. developerPass a JSON schema so the API returns structured data matching that schema

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   Docs explicitly describe an x-json-schema header for passing a JSON schema definition that works with ReaderLM-v2 to extract specific fields, directly matching the story. Missing for 10: independent/hands-on verification of schema-conformant output and no worked example showing exact schema-to-output mapping.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack item describes passing a JSON schema to constrain/validate API output structure for extraction; docs cover Actor development, CLI, MCP server, and general platform features but nothing about schema-guided structured output.

   ⚑ flag

3. ai-native userHave an LLM read a page and decide what structured fields to pull out without pre-written selectors

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed7/10

   Reader explicitly supports `x-instruction` (natural language) and `x-json-schema` headers feeding ReaderLM-v2 to extract specific fields, meaning an LLM/instruction can decide what to pull without pre-written CSS/XPath selectors — directly matching the story. Missing for 10: independent/hands-on verification of extraction quality/accuracy beyond the single first-party doc claim, and no community corroboration of this specific feature working reliably.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   proof ↗⚑ flag

   Apify—none0/10

   Evidence shows Apify's marketplace, CLI, MCP server, and Actor platform, but nothing about an LLM-driven extraction mode that reads a page and decides structured fields without pre-written selectors — no AI-extraction Actor or feature is documented.

   ⚑ flag

4. developerPlug in a local or self-hosted LLM as the extraction backend instead of a cloud-only model

   weight 2 · round drawn
   Jina Reader—none0/10

   Evidence shows Jina Reader uses fixed VLM captioning and ReaderLM-v2 for structured extraction, with no mention of configuring a local/self-hosted LLM as an alternative extraction backend; the open-source self-hosted image runs Reader's own pipeline (Chrome, LibreOffice) rather than letting users swap in their own LLM.

   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence that Apify supports plugging in a local or self-hosted LLM as the extraction backend; documentation covers Actors, CLI, MCP server, and marketplace but nothing about swapping in self-hosted/local models for extraction tasks.

   ⚑ flag

Basic scraping

1. developerScrape a web page with a single API call and get its raw HTML back

   weight 3 · round to Apify
   Jina Reader—none0/10

   Jina Reader's entire design purpose is to convert pages into LLM-friendly Markdown/JSON/frontmatter output (jina-reader-docs-2, jina-reader-gh-5), not raw HTML; no evidence pack item shows an option to return unprocessed raw HTML, and the docs explicitly frame raw scraping as the problem being solved rather than the deliverable.

   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”

   proof ↗⚑ flag

   Apify~partialprobed4/10

   Apify's Actor marketplace and public REST API (openapi.json) mean a developer could run a scraping Actor and retrieve HTML via one API call, but no evidence item explicitly documents a single-call 'get raw HTML' endpoint or a specific ready-made scraper Actor's output format. Missing for 10: explicit docs/example showing an API call that returns raw HTML, and any hands-on confirmation of extraction quality/fidelity for that use case.

   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”

   proof ↗⚑ flag

Data safety

1. data-engineerAutomatically detect and filter personally identifiable information out of scraped content before it reaches storage

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of any PII detection or redaction/filtering feature; Jina Reader's documented capabilities focus on content extraction, formatting, chunking, and structured extraction via schemas, not privacy/PII filtering.

   ⚑ flag

   Apify—none0/10

   No evidence of any built-in PII detection or filtering capability before data reaches storage; docs cover Actor development, CLI, scheduling, monitoring, proxies, and MCP integration but nothing about PII redaction or compliance filtering.

   ⚑ flag

Document extraction

1. data-engineerExtract text content from PDFs, Word, Excel, and PowerPoint files without hosting them myself

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly supports POSTing PDFs and MS Office (Word, Excel, PowerPoint) files directly via the `file` body field without needing to host them, and the self-hosted image bundles LibreOffice to process these office formats. Community evidence shows some auth/404 issues but none specifically contradict document-extraction functionality. Missing for 10: independent hands-on verification of extraction quality/fidelity across all four file types and no detail on limits (file size, complex formatting).

   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack items mention PDF/Word/Excel/PowerPoint text extraction capability or any document-parsing Actor; the pack only covers general Actor development, CLI, MCP, scraping/web crawling tooling.

   ⚑ flag

Multimodal extraction

1. ai-native userGet automatic captions for images on a page so a text-only model can reason about visual content

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly auto-captions images lacking alt tags using a VLM and formats them inline as markdown, directly enabling text-only models to reason about visual content. Missing for 10: independent/hands-on verification of caption quality and no mention of configurability or coverage for images with existing (but poor) alt text.

   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence of any image captioning, alt-text generation, or vision-to-text capability in Apify's docs or community mentions; the evidence pack covers Actors, scraping, CLI, MCP, and proxying but nothing about generating captions for images to aid text-only model reasoning.

   ⚑ flag

Search integration

1. developerSearch the web and get full page content from results in a single call instead of just links and snippets

   weight 3 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader's documented behavior explicitly performs a web search, fetches the top 5 results, and converts each to LLM-friendly full text in one call (s.jina.ai flow), with a 'research' preset tailored for citable agent output. Missing for 10: independent hands-on verification specifically of the search+fetch endpoint (the community evidence cited relates to a different third-party wrapper's auth/404 issues, not this feature directly).

   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   proof ↗⚑ flag

   Apify—none0/10

   The evidence pack shows only generic Apify platform docs (Actors, CLI, MCP server, marketplace) with no mention of a specific search-plus-full-content extraction capability or actor (e.g., a RAG/web-search actor) that returns full page content alongside search results in one call.

   ⚑ flag

Selector extraction

1. developerExtract specific fields from a page using CSS or XPath selector rules

   weight 3 · round to Jina Reader
   Jina Reader~partialclaimed4/10

   Jina Reader offers structured field extraction via `x-json-schema` and `x-instruction` headers (backed by ReaderLM-v2), which lets developers pull specific fields, but the evidence never mentions CSS or XPath selector syntax as the extraction mechanism. Missing for 10: explicit CSS selector support, explicit XPath selector support, documentation showing selector-based (not just schema/instruction-based) targeting.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   proof ↗⚑ flag

   Apify~partialclaimed3/10

   Apify's ecosystem integrates with Playwright, Puppeteer, Selenium, Scrapy, and Crawlee (apify-docs-4), all of which support CSS/XPath selector-based extraction, implying the capability exists, but the evidence pack contains no direct documentation of a selector-based extraction feature (e.g., Web Scraper Actor page-function/selector config) or examples showing CSS/XPath rule usage. missing for 10: explicit docs or examples of CSS/XPath selector extraction features, independent confirmation of selector-based scraping workflows.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”

   proof ↗⚑ flag

Structured data handling

1. data-engineerExtract data from very large tables using intelligent chunking so it fits within processing limits

   weight 1 · round to Jina Reader
   Jina Reader~partialclaimed4/10

   Reader offers an opt-in `x-markdown-chunking` feature that splits markdown output into semantic chunks, which could help fit large content (including tables) within processing limits, but there is no evidence it specifically preserves table structure or handles very large tables intelligently. missing for 10: table-aware chunking logic, evidence of table structure preservation across chunks, benchmarks on large-table extraction accuracy.

   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack items address extracting data from large tables or intelligent chunking to fit processing limits; docs cover Actors, scheduling, proxies, MCP, CLI, but nothing about table-size chunking strategies.

   ⚑ flag

Headless rendering

1. developerRender JavaScript-heavy single-page applications and get the fully rendered HTML

   weight 3 · round drawn
   Jina Reader~partialcommunity6/10

   The self-hosted Reader image bundles headless Chrome (gh-8), and docs claim clean output even for 'complex or dynamic pages' (docs-2), implying SPA/JS rendering support. However, a community commenter explicitly notes the website doesn't clearly document dynamic JS support, and no first-party doc or hands-on test explicitly confirms full SPA rendering works end-to-end. Missing for 10: explicit documentation stating JS/SPA rendering is supported, a hands-on demonstration of a JS-heavy site being fully rendered, and resolution of the community's noted uncertainty about dynamic JS handling.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   proof ↗⚑ flag

   Apify~partialcommunity6/10

   Apify supports Playwright, Puppeteer, and Crawlee for browser automation, which are standard tools for rendering JS-heavy SPAs and extracting fully rendered HTML, and its Actor marketplace includes ready-made scrapers for this purpose. However, the evidence pack lacks explicit first-party documentation or examples demonstrating headless-browser rendering output or a dedicated 'render HTML' API/endpoint, relying instead on general framework compatibility claims. Missing for 10: explicit docs/tutorial on rendering SPAs and returning full HTML, hands-on/independent verification of rendering fidelity, and a dedicated rendering API example.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [community] “Currently I use phantomjs via selenium hub for a product and would like to migrate to chrome but couldn't [find] much information on how to …”

   proof ↗⚑ flag

2. developerHave the API wait for a specific selector to appear before returning the rendered page

   weight 2 · round drawn
   Jina Reader—none0/10

   The evidence shows Reader has timing controls (x-respond-timing to trade latency vs completeness) and general JS-rendering via headless Chrome, but there's no mention of a selector-wait mechanism (e.g., waiting for a specific CSS/XPath selector before returning). Community feedback even notes it's unclear whether/how dynamic JS support works.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack mentions waiting for a specific selector before returning rendered page; only generic mentions of Playwright/Puppeteer/Crawlee support are given, without documenting a wait-for-selector API parameter or option.

   ⚑ flag

Interactive automation

1. developerAccess a managed remote browser sandbox for interactive, manual browsing workflows

   weight 2 · round drawn
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify—none0/10

   Apify's evidence covers Actors, SDKs, CLI, MCP server, and browser automation libraries for building automated scraping/crawling workflows, but there is no mention of an interactive, manual remote browser sandbox (like a live browser session a developer can control interactively for manual browsing). This is a distinct capability (e.g., live view/remote debugging is not documented here) rather than automated headless browser execution.

   ⚑ flag

2. developerKeep interacting with an already-scraped page, clicking and filling forms to reach content behind a login wall

   weight 2 · round to Apify
   Jina Reader—none0/10

   Jina Reader is a stateless URL-to-markdown converter; there's no evidence of interactive session persistence, clicking, or form-filling to navigate behind a login wall. Cookie forwarding (X-Set-Cookie) only supports pre-authenticated single fetches, not interactive multi-step navigation.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   proof ↗⚑ flag

   Apify~partialclaimed5/10

   Apify supports Playwright/Puppeteer/Selenium/Crawlee for building Actors that could interact with pages (clicking, filling forms, navigating login walls) via browser automation, but the evidence pack contains no direct documentation or example describing session persistence, interactive multi-step navigation through login walls, or maintaining state across scraped pages. Missing for 10: explicit documentation/example of stateful interaction with an already-loaded page (form-fill, click-through, login-wall bypass), session/cookie persistence guidance, and independent confirmation of this workflow.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Develop your own Actor”
   • [claimed-docs] “Software toolkits for developing new Actors.”

   proof ↗⚑ flag

3. developerScript page interactions like clicking, filling inputs, and scrolling before content is returned

   weight 3 · round to Apify
   Jina Reader—none0/10

   Jina Reader offers cookie forwarding, proxy rotation, timing/format controls, and extraction schemas, but no evidence shows any mechanism to script page interactions like clicking, filling inputs, or scrolling before content extraction; community comments explicitly note uncertainty about dynamic JS handling.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [community] “I don't find their website mentioning whether they support dynamic JS”

   proof ↗⚑ flag

   Apify~partialclaimed6/10

   Apify supports building Actors with Playwright, Puppeteer, Selenium, and Crawlee, which are libraries capable of scripting clicks, filling inputs, and scrolling before content extraction, but the evidence pack only asserts library compatibility rather than showing documented examples or tutorials of interaction scripting within Apify Actors. Missing for 10: dedicated docs/tutorials demonstrating click/fill/scroll interaction patterns within an Actor, and independent hands-on confirmation of this workflow.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Develop your own Actor”
   • [claimed-docs] “Software toolkits for developing new Actors.”

   proof ↗⚑ flag

Render configuration

1. developerControl the browser viewport width and height when rendering a page

   weight 1 · round drawn
   Jina Reader—none0/10

   No evidence pack item mentions viewport width/height control, browser window sizing, or any device-emulation/viewport configuration options for Jina Reader's rendering.

   ⚑ flag

   Apify—none0/10

   No evidence pack item mentions viewport width/height control or browser rendering configuration; while Apify supports Playwright/Puppeteer/Crawlee generically, no specific documentation of viewport control is cited. Missing for 10: any docs or examples showing viewport/window size configuration in Apify Actors or SDK.

   ⚑ flag

Session persistence

1. developerPass my own session cookies so the API fetches pages requiring authentication

   weight 2 · round to Jina Reader
   Jina Reader~partialcommunity6/10

   Jina Reader's docs describe an X-Set-Cookie header that forwards developer-supplied session cookies when fetching a URL, directly matching the story. However this is a single claimed-docs citation with no independent/hands-on corroboration, and community evidence shows unrelated auth/reliability issues (401 errors, 404s) that raise doubts about robustness. Missing for 10: independent verification that cookie-based authenticated fetches actually work end-to-end, and documentation depth (e.g., examples, session persistence details).

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack item mentions passing custom session cookies or authentication headers for fetching pages behind login; docs listed cover general Actor development, CLI, MCP, and marketplace features but nothing about cookie/session injection.

   ⚑ flag

2. developerReuse a persistent browser profile with saved cookies and login state across multiple requests

   weight 2 · round drawn
   Jina Reader—none0/10

   Jina Reader supports passing session cookies per-request via the X-Set-Cookie header, but there is no evidence of a persistent browser profile that maintains login/cookie state across multiple requests automatically — each request appears stateless, requiring cookies to be re-supplied manually.

   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack mentions persistent browser profiles, cookie storage, or session/login state reuse across requests; docs only cover general Actor development, CLI, SDKs, proxies, and scheduling.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Apify
   Jina Reader✓fullclaimed7/10

   Jina Reader is fundamentally an API-first product where nearly all functionality (URL-to-markdown conversion, web search, PDF/Office ingestion, VLM image captioning, JSON schema/instruction-based extraction, chunking, proxy routing, cookie forwarding, output presets) is exposed entirely through API endpoints and headers, with no evidence of a richer separate UI holding back features. This suggests the API is the primary and complete interface, matching the AI-native openness story well. Missing for 10: no explicit documentation stating 'everything the UI can do the API can also do' or comparison against a dashboard/UI feature set, and no independent corroboration confirming full parity.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “PDFs and MS Office documents (Word, Excel, PowerPoint) can now be POSTed directly via the `file` body field — no need to host them first.”
   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”

   proof ↗⚑ flag

   Apify✓fullprobed8/10

   Apify documents a full OpenAPI-based API (apify-probe-2), a CLI to control the platform from terminal/scripts (apify-docs-3, apify-probe-4), and docs explicitly covering scheduling, monitoring, sharing, proxy, and Actor management—core UI functions all exposed programmatically. This is corroborated by an official MCP server and llms.txt for AI-native access (apify-probe-3, apify-probe-1). Missing for 10: independent/hands-on confirmation that every single UI feature (e.g., billing, org permissions) has 1:1 API parity, and no explicit statement of complete UI/API feature parity.

   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”
   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Share Actors with other people, manage your organizations and permissions.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Apify
   Jina Reader—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Apify~partialprobed4/10

   Apify provides a CLI and REST/OpenAPI API (apify-docs-3, apify-probe-2, apify-probe-4) that could be used to pull data out of the platform, implying some data portability, but the evidence pack never documents actual dataset export formats (e.g., JSON/CSV/Excel) or an explicit 'export and leave' workflow. missing for 10: explicit documentation of dataset export formats, confirmation of full data portability/deletion, and independent verification that a user can fully migrate data out.

   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Jina Reader
   Jina Reader~partialclaimed6/10

   Jina Reader has an open-source branch on GitHub with a prebuilt image published to GitHub Container Registry, confirming source availability, but the evidence pack never states the license under which the code is released. missing for 10: explicit license file/name (e.g., Apache/MIT) confirming open-license status, independent confirmation of license terms.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   proof ↗⚑ flag

   Apify—none0/10

   Apify is a proprietary SaaS platform; while its SDKs/CLI and Crawlee library have some open-source components, the evidence pack shows no mention of an open license for the core platform's source code, and the product itself (the Apify platform/service) is closed-source.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   The open-source branch is self-hostable via a prebuilt Docker image on GitHub Container Registry bundling headless Chrome, LibreOffice, and CJK fonts, so users can run Reader without building it themselves. Missing for 10: independent hands-on confirmation of a successful self-hosted deployment and details on feature parity between self-hosted and SaaS versions.

   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”

   proof ↗⚑ flag

   Apify—none0/10

   Apify is a cloud SaaS platform; evidence shows Actor development, CLI, MCP server, and marketplace features but no evidence of an open-source self-hostable core platform or on-premise deployment option. The Apify SDK/Crawlee is open source, but the core platform (task scheduling, storage, marketplace) is not shown as self-hostable.

   ⚑ flag

Content formats

1. developerReceive scraped content as clean markdown instead of raw HTML

   weight 3 · round to Jina Reader
   Jina Reader✓fullclaimed9/10

   Jina Reader's core function is converting URLs into clean, LLM-friendly Markdown (r.jina.ai), with additional options like frontmatter YAML, image captioning, and semantic chunking, all well documented in first-party sources. Missing for 10: independent hands-on verification of markdown output quality (community evidence cited focuses on auth/404 issues, not output format fidelity).

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “All images on a page that lack an `alt` tag can be auto-captioned by a VLM (vision-language model) and formatted as `![Image [idx]: [VLM_cap…”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack mentions markdown output or content-format conversion capabilities for scraped data; docs references cover Actors, CLI, MCP, scheduling, proxies, etc., but nothing about clean markdown vs raw HTML output.

   ⚑ flag

2. developerChoose exactly which output format is returned, such as markdown, HTML, text, or frontmatter

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed9/10

   jina-reader-gh-5 documents the `x-respond-with` header explicitly selecting output format including markdown, HTML, text, and frontmatter (Markdown+YAML), directly matching the story; gh-10 adds chunking control as extra format nuance. Missing for 10: independent hands-on confirmation of each format option (community evidence only covers auth errors, not format selection).

   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack shows Apify letting developers select specific output formats like markdown, HTML, text, or frontmatter; the docs cover Actors, CLI, MCP, and platform features but not configurable content-extraction output formats.

   ⚑ flag

3. developerReceive scraped content as structured JSON

   weight 3 · round to Jina Reader
   Jina Reader~partialclaimed6/10

   Jina Reader supports structured output via `x-json-schema` for schema-defined field extraction and `x-markdown-chunking` for JSON array chunk output, plus frontmatter YAML metadata — showing real structured-output capability beyond plain markdown. However, the default/primary output is markdown/LLM-friendly text, not JSON, and there's no evidence of a dedicated full-page-to-JSON endpoint or independent confirmation these structured modes work reliably in practice. Missing for 10: independent/hands-on verification of x-json-schema output quality, a documented default JSON response mode, and confirmation these features aren't limited/beta.

   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”

   proof ↗⚑ flag

   Apify—none0/10

   The evidence pack contains no documentation or claims about dataset/output formats (e.g., JSON, CSV, Excel) delivered from Actors; only generic docs about building/publishing Actors, CLI, MCP, and API schema are present. Missing for 10: explicit mention of dataset export formats, JSON output examples, or API endpoints returning structured scraped data.

   ⚑ flag

Llm ready output

1. ai-native userGet clean LLM-ready text directly instead of dealing with blocking, rendering, and messy HTML myself

   weight 3 · round to Jina Reader
   Jina Reader✓fullcommunity9/10

   Jina Reader's core purpose is converting any URL into clean, LLM-ready Markdown/text, avoiding manual HTML parsing and handling JS rendering, anti-bot blocking, and headless browsing behind the scenes, with configurable output formats (frontmatter, JSON, chunked) tailored to AI agents. Community reports show some auth/404 errors on certain deployments, but the core capability is well documented and corroborated. Missing for 10: broader independent benchmarking of output quality/reliability across diverse sites beyond one HN anecdote of failure.

   • [github] “It converts any URL to an **LLM-friendly** input with `https://r.jina.ai/https://your.url`.”
   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”
   • [github] “`x-respond-with` — select the output format. ... `frontmatter` returns **Markdown with a YAML frontmatter block**”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [claimed-docs] “Pass your session cookies with the `X-Set-Cookie` header and the Reader forwards them when fetching the URL”
   • [claimed-docs] “Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable outp…”
   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”
   • [claimed-docs] “Use the `x-json-schema` header with a JSON schema definition, or use `x-instruction` header with natural language instructions. Both feature…”
   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”

   proof ↗⚑ flag

   Apify~partialprobed6/10

   Apify offers anti-blocking proxy rotation, an MCP server for LLM/agent consumption, and llms.txt documentation support, suggesting some LLM-ready output orientation, but the evidence never explicitly documents a 'clean text/markdown extraction' output mode analogous to dedicated LLM-ready scraping tools. Missing for 10: explicit documentation of automatic HTML-to-clean-text/markdown conversion output format, examples of LLM-ready output from Actors, and independent verification that scraped output is directly consumable without further parsing.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Discover and use Actors with AI agents and LLMs via Apify MCP server.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”
   • [probe] “official MCP server documented at https://docs.apify.com/platform/integrations/mcp”

   proof ↗⚑ flag

2. ai-native userRequest semantically chunked output instead of one large content blob, so it feeds cleanly into a retrieval pipeline

   weight 2 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   Jina Reader explicitly supports `x-markdown-chunking`, an opt-in header returning semantically chunked output as a JSON array or delimited text instead of one blob, directly matching the story. Missing for 10: independent hands-on validation of chunk quality/boundaries and no detail on chunking algorithm robustness across document types.

   • [github] “`x-markdown-chunking` — opt-in semantic chunking of the markdown response. Returns a JSON array (or ``-delimited text) of chunks instead of …”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack indicates Apify offers semantic chunking of output content for retrieval pipelines; docs cover Actor development, CLI, MCP integration, scheduling, and proxy rotation, but nothing about chunked/segmented output formats.

   ⚑ flag

Visual capture

1. developerCapture a screenshot of a full page or a specific selected area

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence in the pack mentions screenshot capture of full pages or selected areas; Jina Reader's documented capabilities focus on converting URLs to Markdown/text, image captioning, and structured extraction, not visual screenshots.

   ⚑ flag

   Apify—none0/10

   The evidence pack contains no mention of screenshot capture functionality (full-page or selector-based) in any Apify docs, community posts, or probes; while Apify supports Playwright/Puppeteer which could enable screenshots, no direct evidence documents this capability.

   ⚑ flag

Cost optimization

1. developerLet the API automatically pick the cheapest configuration that still succeeds

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence Jina Reader has any automatic cost-optimization logic that selects the cheapest configuration guaranteed to succeed; the options exposed (x-preset, x-respond-timing, x-proxy) are manually set by the developer, not auto-selected for cost minimization, and pricing/limits aren't even documented per community reports.

   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence of any automatic cost-optimization or configuration-selection feature; Apify's docs cover Actor development, scheduling, monitoring, proxies, and CLI/API tooling but nothing about automatically choosing the cheapest configuration that still succeeds.

   ⚑ flag

2. developerBlock ads on the target page to speed up scraping requests

   weight 1 · round drawn
   Jina Reader—none0/10

   No evidence of any ad-blocking or content-filtering feature to speed up scraping; Reader's evidence covers output formatting, chunking, proxy rotation, and cookie forwarding, but nothing about blocking ads/trackers on the target page.

   ⚑ flag

   Apify—none0/10

   Evidence pack shows Apify's proxy/IP rotation, Actor development, CLI, MCP, and marketplace features, but no mention of ad-blocking or resource-blocking capabilities for target pages to speed up scraping.

   ⚑ flag

3. developerBlock images and CSS resources by default to reduce bandwidth and speed up requests

   weight 1 · round drawn
   Jina Reader—none0/10

   No evidence of an option to block images or CSS resources by default; Reader's documented features focus on content extraction, VLM image captioning, and output formatting, not resource-blocking for bandwidth savings.

   ⚑ flag

   Apify—none0/10

   No evidence pack item mentions blocking images/CSS resources or any bandwidth-saving resource filtering feature; while Apify's underlying crawlers (Puppeteer/Playwright) could support this, no documentation here confirms a default or built-in option for it.

   ⚑ flag

4. ai-native userSet how much reasoning effort an autonomous agent spends on a data-gathering task (low, medium, high)

   weight 2 · round drawn
   Jina Reader—none0/10

   Jina Reader is a URL-to-text extraction service, not an autonomous reasoning agent; there is no reasoning-effort/low-medium-high control exposed. The closest options (x-respond-timing trading latency vs completeness, x-preset) control fetch behavior, not agentic reasoning depth, so the specific capability is absent.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence Apify exposes a reasoning-effort control (low/medium/high) for agents on data-gathering tasks; the docs cover Actors, CLI, scheduling, proxies, and MCP integration but nothing about configurable reasoning depth or agent 'effort' levels.

   ⚑ flag

Cost transparency

1. developerWhether exceeding my plan's monthly credit or request quota triggers overage charges or a hard cutoff

   weight 3 · round drawn
   Jina Reader—none0/10

   No evidence describes what happens when a plan's monthly credit/request quota is exceeded — no mention of overage billing or hard cutoff behavior; community commentary even notes the site doesn't document API limits at all.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack addresses what happens when a plan's monthly credit or request quota is exceeded—no mention of overage billing, pay-as-you-go charges, or hard cutoffs/service suspension. Missing for 10: any pricing/billing docs on overage policy, quota enforcement behavior, or account throttling upon limit breach.

   ⚑ flag

2. developerWhether failed, blocked, or empty-result requests still consume my billing quota

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence pack item discusses billing behavior for failed, blocked, or empty-result requests, nor any quota-consumption policy; community notes only mention lack of clarity on API limits and unrelated authentication errors.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence in the pack addresses whether failed, blocked, or empty-result runs still consume billing quota/compute units; none of the docs or community items discuss billing treatment of failed or empty results.

   ⚑ flag

3. developerSet a spending cap or usage alert so proxy/credit consumption doesn't silently blow past my budget

   weight 3 · round drawn
   Jina Reader—none0/10

   No evidence of spending caps or usage alerts; community even notes API limits aren't documented on the website (jina-reader-comm-1), and no billing/quota dashboard or alerting feature is mentioned anywhere in the evidence pack.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack item mentions spending caps, budget limits, or usage alerts for proxy/credit consumption; docs snippets cover Actor development, scheduling, monitoring performance/data quality, but not billing/usage limit controls.

   ⚑ flag

Performance tuning

1. developerTrade off latency against completeness by controlling exactly when content is returned

   weight 1 · round to Jina Reader
   Jina Reader✓fullclaimed8/10

   The `x-respond-timing` header is documented explicitly as giving developers explicit control over when Reader returns, directly trading off latency against completeness, which is exactly the story described. Missing for 10: independent/hands-on confirmation of the header's behavior and concrete latency/completeness benchmarks beyond the first-party doc snippet.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack items address configurable latency-vs-completeness tradeoffs (e.g., streaming partial results, timeouts, or synchronous vs async return controls); docs cover scheduling, monitoring, proxies, and Actor development but not this specific control.

   ⚑ flag

Plan scale limits

1. data-engineerThe maximum concurrent sessions or requests allowed on my pricing tier and the cost to raise that cap

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence documents concurrency/request caps per pricing tier or the cost to increase them; community comments explicitly note the website doesn't mention API limits, and authentication errors appear but no rate-limit specifics.

   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence pack item documents concurrent session/request caps per pricing tier or the cost to increase them; nothing addresses concurrency limits or upgrade pricing.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location controls; only self-hosting via a prebuilt container image is mentioned, which is a deployment option not a residency control feature.

   ⚑ flag

   Apify—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location controls for Apify; this is a fair question for a cloud data platform but is unaddressed.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Jina Reader—none0/10

   No evidence found of any data-training opt-out, privacy policy, or no-training guarantee for Jina Reader; the pack covers only functional features (parsing, chunking, proxying) and unrelated auth/probe issues.

   ⚑ flag

   Apify—none0/10

   No evidence pack items mention AI training data opt-out, data usage policies for model training, or privacy controls addressing this specific concern; all citations relate to Actor development, marketplace, CLI, and MCP features unrelated to data-training privacy.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence pack item addresses data retention policies, data deletion controls, or user-facing settings to manage stored data lifecycle; evidence covers scraping features, formats, and proxying but nothing about retention/deletion posture.

   ⚑ flag

   Apify—none0/10

   No evidence pack items address data retention policies, dataset/storage expiration controls, or deletion mechanisms for user data on the Apify platform. Missing for 10: documentation on data retention periods, deletion APIs/controls, GDPR-related data handling, or account/data export-and-delete workflows.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics, or an opt-out mechanism for Jina Reader; the docs focus on API features and scraping, not privacy controls.

   ⚑ flag

   Apify—none0/10

   No evidence pack items mention telemetry, usage tracking, or an opt-out mechanism for Apify's CLI, SDK, or platform; all citations concern unrelated features like Actors, MCP, CLI commands, and marketplace stats.

   ⚑ flag

Ai driven crawling

1. ai-native userRely on adaptive crawling that automatically stops once enough information has been gathered to answer my query

   weight 2 · round to Jina Reader
   Jina Reader~partialclaimed4/10

   Reader offers a related knob (`x-respond-timing` to trade off latency vs completeness) and a `research` preset for agentic use, suggesting some adaptive control over when it returns results, but there is no evidence of true query-driven adaptive crawling that stops once 'enough information' has been gathered to answer a specific question — the search flow simply fetches a fixed top-5 results. Missing for 10: explicit query-aware stopping criteria, evidence of dynamic crawl depth/breadth adjustment based on information sufficiency, and independent validation of this behavior.

   • [github] “`x-respond-timing` — explicit control over *when* Reader is willing to return. Trade off latency against completeness”
   • [github] “`x-preset` — apply a pre-packaged option bundle for common scenarios. ... `research` — for AI research agents needing structured, citable ou…”
   • [github] “Behind the scenes, Reader searches the web, fetches the top 5 results, visits each URL, and applies `r.jina.ai` to it.”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence describes adaptive crawling that dynamically stops once sufficient information is gathered to answer a query; Apify's docs cover Actors, scheduling, proxies, MCP integration, and CLI but nothing about query-driven adaptive stopping logic.

   ⚑ flag

Batch processing

1. data-engineerBatch scrape thousands of URLs asynchronously

   weight 3 · round to Apify
   Jina Reader—none0/10

   Evidence covers single-URL conversion, search-based fetching, proxy rotation, and format options, but nothing documents a batch/bulk endpoint, job queue, or async processing pipeline for thousands of URLs at once.

   ⚑ flag

   Apify~partialprobed6/10

   Apify's platform is built around Actors (scrapers) that run at scale in the cloud, with scheduling, proxy rotation to avoid blocking, monitoring/alerts, and CLI/API control — all consistent with batch-scraping thousands of URLs asynchronously. However, no evidence pack item explicitly documents async batch job queuing, concurrency limits, or dataset-scale benchmarks for 'thousands of URLs' specifically. missing for 10: explicit documentation/benchmarks of large-scale async URL batch scraping, concurrency/queue management details, and independent hands-on validation of scale claims.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”
   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

2. developerApply different crawl configurations to different URL patterns within a single batch job

   weight 1 · round drawn
   Jina Reader—none0/10

   Jina Reader operates per-URL request with headers/options (e.g. x-preset, x-respond-with) applied uniformly to a single fetch; there's no evidence of a batch-job concept or per-URL-pattern configuration mapping within one job. missing for 10: batch job API, URL-pattern-based rule matching, differentiated configs within a single request/job.

   ⚑ flag

   Apify—none0/10

   No evidence in the pack shows per-URL-pattern crawl configuration within a single job; docs mention general Actor development, scheduling, proxy rotation, and CLI/MCP tooling but nothing about applying different crawl rules to different URL patterns in one batch job.

   ⚑ flag

Concurrency

1. data-engineerSpin up many concurrent scraping sessions to gather data at scale

   weight 3 · round to Apify
   Jina Reader~partialcommunity5/10

   Reader offers infrastructure that could support scale (a rotating proxy pool for anti-bot handling, and a self-hostable Docker image bundling headless Chrome so engineers could run many parallel instances), but there is no first-party documentation of concurrency limits, rate limits, or guidance for running many simultaneous scraping sessions. Community commentary explicitly notes the site doesn't mention API limits, adding uncertainty rather than confirmation. missing for 10: documented concurrency/rate limits, guidance or benchmarks for running many parallel sessions, independent evidence of successful large-scale concurrent use.

   • [github] “Route through the SaaS proxy with `-H 'x-proxy: auto'` (key required). Reader's hosted proxy pool rotates residential / datacenter IPs and h…”
   • [github] “A prebuilt image of the open-source branch is published to GitHub Container Registry. It bundles headless Chrome, LibreOffice, and CJK fonts…”
   • [community] “Have you used them? They offer it for free and I don't find their website mentioning API limit”

   proof ↗⚑ flag

   Apify~partialclaimed6/10

   Apify's platform supports running Actors (scrapers) with IP rotation to avoid blocking, scheduling, monitoring, and CLI/API control, which implies infrastructure for scaling scraping jobs, but the evidence pack lacks explicit documentation on concurrency limits, parallel run orchestration, or autoscaling guarantees for many simultaneous sessions. Missing for 10: explicit docs on concurrent run limits/autoscaling, benchmarks or case studies demonstrating large-scale concurrent scraping, and independent verification of scale-reliability under load.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”
   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”

   proof ↗⚑ flag

Crawl compliance

1. data-engineerConfigure the crawler to respect robots.txt rules and target-site rate limits automatically

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence in the pack mentions robots.txt compliance or configurable rate-limiting; features described relate to output formatting, proxying, and anti-bot bypass, not politeness controls.

   ⚑ flag

   Apify—none0/10

   Evidence mentions IP rotation to avoid blocking and general Actor development/scheduling docs, but nothing explicitly addresses automatic robots.txt compliance or configurable rate-limiting to respect target-site limits. missing for 10: robots.txt compliance settings, automatic rate-limit/throttling configuration, documentation or community confirmation of these specific features.

   • [claimed-docs] “Avoid blocking by smartly rotating datacenter and residential IP addresses.”

   proof ↗⚑ flag

Fault tolerance

1. data-engineerResume a crashed deep crawl from a saved checkpoint instead of restarting from scratch

   weight 2 · round drawn
   Jina Reader—none0/10

   Jina Reader is a URL-to-markdown conversion API/tool, not a deep-crawl orchestration system with crawl-state checkpointing; no evidence anywhere in the pack mentions crawl checkpoints, resumable crawls, or job-state persistence.

   ⚑ flag

   Apify—none0/10

   No evidence in the pack mentions checkpointing or resuming a crashed deep crawl; Apify docs cover Actors, scheduling, monitoring, CLI, MCP, etc., but nothing about saving/restoring crawl state after a crash. This is a plausible axis for a scraping platform, so absence of evidence yields 'none'.

   ⚑ flag

Operational transparency

1. data-engineerCheck a public status page showing uptime history and past incident postmortems before committing to the service

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of a public status page, uptime history, or incident postmortems; instead there's community evidence of undocumented failures (404s, auth errors) with no transparency page to check beforehand.

   • [community] “TB – super-fast text-only browser using Jina Reader API: Does not work (404 not found), return to your vibe code session and try again.”
   • [community] “{"code":401,"name":"AuthenticationRequiredError","message":"Authentication is required to use this endpoint. Please provide a valid API key …”
   • [community] “readableMessage: AuthenticationRequiredError: Authentication is required to use this endpoint. Please provide a valid API key via Authorizat…”

   proof ↗⚑ flag

   Apify—none0/10

   No evidence of a public status page, uptime history, or incident postmortems anywhere in the pack; only docs, community sentiment, and API/CLI probes are provided.

   ⚑ flag

Scheduling monitoring

1. data-engineerMonitor target pages for content changes, such as price or listing updates, and get notified as they happen

   weight 2 · round to Apify
   Jina Reader—none0/10

   Jina Reader converts URLs into LLM-ready content on-demand but there is no evidence of scheduled monitoring, diffing, or change-notification features (webhooks, alerts, polling schedules) that would let a data-engineer track content changes over time.

   ⚑ flag

   Apify~partialclaimed5/10

   Apify offers scheduling to run Actors periodically (apify-docs-6) and general Actor monitoring/alerting (apify-docs-7), which together could underpin a page-change-monitoring workflow, and its marketplace likely has ready-made 'content checker' Actors, but no evidence pack item explicitly documents a change-detection/diffing feature or notification-on-change capability for target pages like prices or listings. Missing for 10: explicit docs on content-diff/change-detection Actors, notification channels (email/webhook/Slack) triggered specifically by detected content changes, and independent confirmation of this exact use case.

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”

   proof ↗⚑ flag

2. data-engineerMonitor job performance, validate data quality, and receive alerts when something fails

   weight 2 · round to Apify
   Jina Reader—none0/10

   No evidence of job performance monitoring, data quality validation, or failure alerting features; evidence covers content extraction and formatting only, with community reports even noting undocumented API limits and auth errors rather than monitoring/alerting tooling.

   ⚑ flag

   Apify✓fullclaimed7/10

   Apify docs explicitly state the platform lets users check Actor performance, validate data quality, and receive alerts, directly matching the story. Missing for 10: independent/hands-on corroboration of monitoring/alerting in practice and detail on alert configuration options beyond the single doc line.

   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”

   proof ↗⚑ flag

3. developerMonitor live system metrics and worker/browser pool status through a real-time dashboard

   weight 1 · round to Apify
   Jina Reader—none0/10

   No evidence of any real-time dashboard, metrics UI, or worker/browser pool status monitoring; evidence only covers content extraction features and API options. This is an applicable axis for a scale-reliability story about a self-hostable service with a browser pool, but nothing in the pack shows such a dashboard exists.

   ⚑ flag

   Apify~partialclaimed4/10

   Apify docs mention monitoring Actor performance, data quality checks, and alerts (apify-docs-7), implying some run/status visibility, but there's no concrete evidence of a real-time dashboard showing live system metrics or worker/browser pool status specifically. Missing for 10: explicit dashboard UI showing live resource/worker pool metrics, screenshots or docs describing real-time monitoring views, and independent confirmation of dashboard capabilities.

   • [claimed-docs] “Check the performance of your Actors, validate data quality, and receive alerts.”

   proof ↗⚑ flag

4. developerSchedule scraping jobs to run automatically at specific times

   weight 2 · round to Apify
   Jina Reader—none0/10

   No evidence of any scheduling, cron, or job-queue feature; Jina Reader is a synchronous URL-to-text API with no mention of automated/recurring execution.

   ⚑ flag

   Apify✓fullprobed8/10

   Apify docs explicitly state scheduling functionality: "Automatically start Actors and saved tasks at specific times," directly matching the story of scheduling scraping jobs to run automatically. This is corroborated by CLI/API tooling for platform control, though there's no independent hands-on report specifically validating the scheduler feature. Missing for 10: independent/community confirmation of scheduling reliability, and more detail on schedule configuration options (cron, timezone, etc.).

   • [claimed-docs] “Automatically start Actors and saved tasks at specific times.”
   • [claimed-docs] “Control the Apify platform from terminal or shell scripts.”
   • [probe] “official CLI documented at https://docs.apify.com/cli/”

   proof ↗⚑ flag

Site crawling

1. data-engineerRun a deep crawl using a breadth-first strategy with a configurable maximum page limit

   weight 2 · round drawn
   Jina Reader—none0/10

   No evidence of a deep-crawl feature with breadth-first strategy or configurable page-limit; Jina Reader converts single URLs or performs top-5 search results, not a crawler with BFS/page-limit controls.

   ⚑ flag

   Apify—none0/10

   While Apify's Crawlee library and Actors are built for web crawling, none of the evidence mentions a breadth-first crawl strategy or a configurable maximum page limit specifically; the docs pack only lists generic feature blurbs (Actor development, scheduling, monitoring, proxies) without crawl-strategy specifics.

   ⚑ flag

2. developerCrawl an entire website and get content from all its pages with one request

   weight 3 · round to Apify
   Jina Reader—none0/10

   Jina Reader's evidence describes converting single URLs to LLM-friendly text and a search-then-fetch-top-5 mode, but there is no evidence of a whole-site crawl feature that traverses all pages of a domain in one request.

   ⚑ flag

   Apify~partialprobed6/10

   Apify's ecosystem includes Crawlee and general Actor infrastructure that could power full-site crawling, and marketplace Actors (like website content crawlers) exist implicitly via the Store, but the evidence pack lacks any direct documentation of a single-request 'crawl entire website' Actor, its configuration, or output format. missing for 10: explicit docs/demo of a whole-site crawler Actor invoked via one API call, details on link-following/depth/queue handling, and independent confirmation of successful full-site crawls.

   • [claimed-docs] “Apify works great with both Python and JavaScript, as well as Playwright, Puppeteer, Selenium, Scrapy, and Crawlee - our own web crawling an…”
   • [claimed-docs] “Marketplace of 64,279 Actors”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.apify.com/llms.txt # Apify Documentation > Apify is the largest marketplace of tools for AI. Thous…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.apify.com/api/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. developerInstantly discover all URLs on a website without fully crawling it

   weight 2 · round drawn
   Jina Reader—none0/10

   Jina Reader converts individual URLs into clean text/markdown and can search top results, but there is no evidence of a sitemap/URL-discovery feature that lists all URLs on a site without crawling it.

   ⚑ flag

   Apify—none0/10

   No evidence of a sitemap/URL-discovery feature (e.g., a dedicated sitemap crawler or 'discover URLs without full crawl' Actor); evidence only covers general crawling, Actors, CLI, MCP, and proxy features. Absence of evidence for this specific capability yields 'none'.

   ⚑ flag