Apify vs Riveter

Agent access

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

   weight 2 · round to Apify
   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

   Riveter—none0/10

   Direct probes show llms.txt returns 404 and no OpenAPI spec is discoverable at any standard path, and no evidence pack item claims an agent-oriented docs format exists; while MCP integration is mentioned, that's a separate capability from machine-readable docs for pointing an agent at.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

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

   weight 2 · round to Apify
   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

   Riveter~partialclaimed6/10

   Riveter exposes a full API with SDKs (Go example shown), webhooks for async completion, dry_run/max_credits safety controls, and scheduling for recurring automation — all of which support headless, non-interactive use in a pipeline. However, there is no explicit CI/CD example, GitHub Actions integration, or CLI documentation demonstrating a documented headless workflow. Missing for 10: explicit CI/CD or pipeline integration guide, CLI headless invocation docs, independent confirmation of automated/scripted runs.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Apify—none0/10

   All MCP evidence (apify-docs-10, apify-probe-3) describes Apify exposing its own Actors via an MCP server so external AI agents can use Apify's tools — i.e., Apify acting as an MCP server provider, not as a client that plugs in third-party MCP servers to use their tools. There is no evidence Apify can consume or integrate external MCP servers itself, so the story as stated (product acting as MCP client) is unsupported.

   • [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

   Riveter—none0/10

   All MCP-related evidence describes Riveter acting as an MCP *server* that other AI assistants (Claude, ChatGPT, Cursor) connect to, not Riveter acting as a client that can plug in and consume external MCP servers' tools. No evidence shows Riveter itself importing/connecting to third-party MCP servers to extend its own tool use.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

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

   weight 3 · round to Apify
   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

   Riveter✓fullclaimed7/10

   Docs explicitly describe connecting Riveter to Claude, ChatGPT, Cursor, or any MCP-compatible assistant via two connection methods, including a local Node.js-based server option, indicating an official MCP server offering. Missing for 10: no independent/hands-on corroboration of the MCP server working, and no detail on the remote/hosted connection method's implementation.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Apify
   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

   Riveter—none0/10

   Evidence shows SDKs (Go), a local MCP server requiring Node.js, and REST API features, but no mention of an official CLI tool for running enrichments or managing the product. The docs and probes (llms.txt, openapi) surface no CLI reference, so this applicable axis is unmet.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

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

   weight 3 · round to Apify
   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

   Riveter~partialprobed6/10

   Docs describe concrete API mechanics (webhook_url, dry_run, max_credits, SDK auth/retry/pagination handling, Go SDK code sample) showing a real documented public API surface for driving runs programmatically, and MCP/remote-server integration is documented. However, probes for a formal machine-readable spec (openapi.json/swagger.json) and llms.txt all returned 404, so there's no discoverable canonical API reference, undermining full 'documented public API' claims. missing for 10: a public OpenAPI/swagger spec or llms.txt confirming a fully machine-readable API contract, independent third-party confirmation of API usage.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   Riveter's evidence covers a single API key model, credit caps, and dry-run cost estimation, but there is no mention of scoped or least-privilege credentials, per-agent tokens, or permission scoping for agents. missing for 10: scoped/least-privilege credential issuance, per-agent API key scoping, role/permission-based access control.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Apify
   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

   Riveter✓fullclaimed7/10

   Riveter ships an official Go SDK (riveterhq/riveter-go) with documented client code (riveter.EnrichParams), and docs describe SDK-level handling of auth, retries, long-polling, and pagination, indicating a first-party SDK layer built for AI-native workflows. Missing for 10: confirmation of additional language SDKs (e.g., Python/JS) beyond Go, and independent/hands-on corroboration of SDK reliability.

   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Riveter
   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

   Riveter~partialclaimed6/10

   Riveter supports webhooks by passing a webhook_url when starting a run, with Riveter POSTing results back on run.completed, run.stopped, and run.finished events — a real event-notification mechanism for agentic workflows. However this is scoped to a single run's lifecycle rather than a general subscription model (no persistent webhook registration/management endpoint, no broader event catalog, no signature/security details). Missing for 10: a dedicated webhook subscription/management API, documentation of additional event types beyond run lifecycle, and payload signing/verification details.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Riveter
   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

   Riveter✓fullclaimed7/10

   Riveter's core enrichment feature fills columns using AI agents, web search/scrape, and other tools to generate insights directly on user data, and search_agent provides ad hoc AI-researched answers within the product. missing for 10: independent/hands-on corroboration of insight quality, no example of proactive/unprompted suggestions (only prompt-driven enrichment), and no dashboard-level 'insights' UI evidence beyond API/SDK docs.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

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

   weight 2 · round to Apify
   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

   Riveter~partialclaimed6/10

   Riveter supports scheduling projects to run on a cadence ('every minute' for fast-moving data) and webhook notifications on run completion, which enables autonomous background execution without manual triggering. However, there's no evidence of broader automation orchestration (e.g., conditional triggers, chaining multiple actions, or a dedicated automation/workflow builder) beyond scheduled data refresh. Missing for 10: evidence of multi-step autonomous workflows beyond scheduled enrichment refresh, independent/hands-on confirmation that scheduling works reliably in production, and any automation trigger types beyond time-based schedules.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

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

   weight 3 · round to Riveter
   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

   Riveter~partialclaimed6/10

   Riveter ships an internal 'agent loop' (search_agent, enrichment AI) that autonomously researches, scrapes, and fills data on request, which functions as a built-in AI assistant for delegated research tasks rather than a conversational general-purpose assistant. Missing for 10: evidence of a general chat/task interface for arbitrary delegation, independent hands-on validation, and clarity on how broadly the agent can handle tasks beyond enrichment/search/scrape.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

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

   weight 2 · round to Riveter
   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

   Riveter✓fullclaimed7/10

   Riveter explicitly supports building enrichments from natural-language prompts (riveter-docs-2), offers a search_agent that answers questions in natural language without setup (riveter-docs-5), and can be operated via MCP-compatible AI assistants like Claude, ChatGPT, and Cursor (riveter-docs-9), which is the core mechanism for natural-language control. Missing for 10: independent/hands-on confirmation of NL command reliability, and no evidence of a broader NL command surface beyond enrichment/search (e.g., NL-driven scheduling or config changes).

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   Riveter offers enrichment, search_agent, and scrape tools with structured outputs, but there is no evidence of a preset/template configuration specifically tuned for research agents or citable output formatting; missing for 10: a named preset or template targeting research-agent workflows, citation/source-attribution formatting in outputs, and any documentation referencing 'research agent' presets.

   ⚑ flag

Api quality

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

   weight 2 · round to Apify
   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

   Riveter—none0/10

   No evidence of an interactive API reference or runnable examples; probes for llms.txt and OpenAPI/Swagger specs both returned 404s, and docs snippets are static text/code examples only, not interactive/runnable.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

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

   weight 2 · round to Apify
   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

   Riveter—none0/10

   Probes for llms.txt and OpenAPI/swagger spec files all returned 404s, and no documentation mentions a downloadable machine-readable API spec despite having a REST API and SDKs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

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

   weight 1 · round to Riveter
   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

   Riveter~partialclaimed4/10

   Riveter offers a dry_run mode that validates a request and returns a credit estimate without creating or charging anything, and a max_credits cap that blocks runs before they execute — both function like a lightweight 'test without side effects' capability. However, there's no explicit documentation of a separate sandbox environment or synthetic/test dataset distinct from production data sources (Riveter always operates against live web/data sources when actually run). Missing for 10: a documented sandbox/staging environment, sample or mock datasets, and explicit guidance on testing enrichments without touching real production data sources.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; probes for OpenAPI/spec discovery returned 404s, and docs mention SDKs/features but nothing about version numbers or deprecation guarantees. Missing for 10: versioned endpoint scheme (e.g., /v1/), a published deprecation/sunset policy, changelog or migration guides.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ 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
   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

   Riveter—none0/10

   There is a mention of SDKs handling retries on 429s, implying rate limiting exists, but no documented numeric rate limit (requests per second/minute) is given anywhere in the evidence pack, and probes for API spec/docs return 404s.

   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ 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 drawn
   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

   Riveter—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

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

   weight 2 · round to Apify
   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

   Riveter—none0/10

   No evidence of proxy rotation, IP chaining, or anti-bot-specific retry logic; only generic SDK retries for 429s/transient failures are mentioned, which is unrelated to proxy chaining against anti-bot blocks.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Riveter—none0/10

   No evidence mentions undetected browser mode, bot-detection bypass, proxies, or stealth automation features; Riveter's evidence only covers enrichment, scraping, and search tooling. Missing for 10: any mention of anti-bot/stealth browser capabilities, CAPTCHA handling, or evasion of bot detection.

   ⚑ flag

Proxy rotation

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

   weight 2 · round to Apify
   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

   Riveter—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

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

   weight 3 · round to Apify
   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

   Riveter—none0/10

   No evidence mentions proxy support (residential or datacenter) or IP rotation for anti-bot bypass; the docs describe scraping and AI agent interpretation but never address proxy infrastructure.

   ⚑ flag

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

   weight 3 · round to Apify
   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

   Riveter—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

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

   weight 2 · round drawn
   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

   Riveter—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

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

   weight 2 · round to Riveter
   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

   Riveter✓fullclaimed8/10

   Riveter's core enrichment model operates on many rows at once (bulk input data with AI-filled columns), supports batch generation from a prompt/spec, scheduling for ongoing refresh, and examples like pulling every dentist from every practice in a city in one request. Missing for 10: independent/hands-on verification of large-scale bulk runs and no explicit documentation of per-run item limits or throughput benchmarks.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

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

   weight 3 · round to Apify
   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

   Riveter~partialclaimed4/10

   Riveter supports scheduled refresh of projects (time-based automation) and webhook events (run.completed/stopped/finished) that can notify external systems, giving some automation-on-events capability, but there is no evidence of a rules/condition engine that lets users define arbitrary triggers (e.g., 'if data matches X, then do Y') beyond scheduling and run-completion notifications. missing for 10: conditional rule definitions, event-driven branching logic, multi-condition triggers, and any UI/API for building custom automations beyond schedule+webhook.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Apify
   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

   Riveter~partialclaimed6/10

   Docs state you can 'schedule any project to monitor for changes and keep your data fresh' and refresh as often as every minute, indicating recurring job/workflow scheduling support. However, details are thin — no documentation on schedule configuration (cron-like syntax, timezone, pause/resume), no UI/API endpoint specifics for managing schedules, and no independent or hands-on corroboration. Missing for 10: scheduling API/UI details, configuration options, independent verification of reliability at scale.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Apify—none0/10

   The evidence pack covers Actor development, scheduling, monitoring, and marketplace sharing, but contains no mention of versioning Actor code, review workflows, or rollback to prior automation versions. Axis is applicable to an automation/scraping platform but no supporting evidence is present.

   ⚑ flag

   Riveter—none0/10

   No evidence of version history, review workflows, or rollback capability for automations/enrichments; the pack only covers run execution, credit control, and data enrichment features. Missing for 10: versioning of automation configs, review/approval workflow, rollback/undo mechanism.

   ⚑ flag

Collaboration

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

   weight 2 · round to Apify
   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

   Riveter—none0/10

   No evidence pack items mention team sharing, organizations, workspaces, or role-based access control for Riveter; all evidence covers scraping/enrichment functionality and API mechanics only. Missing for 10: any mention of teams, org management, invites, or RBAC/permissions.

   ⚑ flag

Deployment flexibility

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

   weight 2 · round to Apify
   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

   Riveter~partialclaimed6/10

   Riveter's docs show fully managed, serverless-style capabilities (enrichments, scrapes, quick_search, search_agent) that developers configure via natural-language prompts or structured specs and trigger via API/SDK/webhooks with no server management (riveter-docs-1,2,3,4,5,6,11,12). However, this is closer to configuring built-in AI-driven tools than deploying arbitrary custom scraping code/scripts — there's no evidence of a code-upload or custom-script execution environment. Missing for 10: evidence of arbitrary custom code/script deployment (vs. prompt/spec-based enrichment configuration), and independent confirmation of the serverless execution model.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—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

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   Riveter is presented as a hosted API/service (with a local MCP connector for client access to the remote service), but there is no evidence of an open-source, self-hostable version of the scraper itself; docs only describe running a local MCP bridge that still relies on the remote API key.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   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
   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

   Riveter—none0/10

   No evidence of a prebuilt n8n or Zapier connector; only webhook support and MCP/AI-assistant integrations are documented, which are not no-code automation platform connectors.

   ⚑ flag

Library compatibility

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

   weight 2 · round to Apify
   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

   Riveter—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

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
   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

   Riveter—none0/10

   No evidence of any export/portability feature for scraped data or job configs, nor any mention of migration support or standard/open config formats; API docs focus on running enrichments, webhooks, and SDKs, not data portability.

   ⚑ flag

Quickstart

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

   weight 1 · round to Apify
   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

   Riveter—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

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

   weight 2 · round to Apify
   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

   Riveter—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

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

   weight 1 · round to Apify
   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

   Riveter—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

Ai extraction

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

   weight 3 · round to Riveter
   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

   Riveter✓fullclaimed7/10

   Riveter's core enrichment feature lets developers build extraction jobs from a natural-language prompt with target attributes instead of writing selectors, and AI agents interpret pages semantically so configs survive redesigns, directly matching the story. missing for 10: independent/hands-on verification of extraction accuracy and no live API schema (openapi/llms.txt probes 404) to confirm behavior beyond vendor docs.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ flag

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

   weight 2 · round to Riveter
   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

   Riveter~partialclaimed4/10

   Riveter lets you define enrichments via a natural-language prompt or a 'structured spec' with named attributes/columns (riveter-docs-2, riveter-docs-12), which produces structured output, but there is no documented mechanism for passing an arbitrary JSON Schema that the API validates/returns against. missing for 10: explicit JSON Schema input parameter, schema validation of output, and any example showing schema-conformant responses.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ 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 Riveter
   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

   Riveter✓fullclaimed8/10

   Docs describe enrichments where AI agents interpret pages and fill arbitrary attribute columns from a natural-language prompt or structured spec (no selectors), with scraping/search tools feeding an AI agent loop that adapts to page structure and redesigns. This directly matches the story of an LLM reading a page and deciding what fields to extract without pre-written selectors. Missing for 10: independent hands-on verification of extraction accuracy and no example showing the LLM's field-selection reasoning in practice.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence anywhere in the docs suggests Riveter allows swapping in a local or self-hosted LLM as the extraction engine; the product is presented as a cloud-only enrichment/extraction service with API keys, credits, and hosted agents. Missing for 10: any mention of local model support, self-hosted backend configuration, or BYO-model options.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

Basic scraping

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

   weight 3 · round to Apify
   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

   Riveter—none0/10

   Riveter's scrape endpoint explicitly returns 'easily parseable text' from a URL, not raw HTML — the opposite of what this story asks for, and no evidence shows an option to retrieve unprocessed HTML.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   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
   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

   Riveter—none0/10

   No evidence anywhere in the pack mentions PII detection, filtering, redaction, or compliance controls for scraped/enriched data; Riveter's documented features cover scraping, enrichment, search, and workflow orchestration but nothing about identifying or removing personal data before storage.

   ⚑ flag

Document extraction

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

   weight 2 · round to Riveter
   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

   Riveter~partialclaimed4/10

   Riveter is delivered as a hosted API/SaaS (no self-hosting required) and docs state it 'reads PDFs and images' as part of enrichment workflows, but there is no evidence it extracts text from Word, Excel, or PowerPoint files specifically. missing for 10: explicit support for .docx/.xlsx/.pptx extraction, any extraction-quality benchmarks or examples for Office file formats.

   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ 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 Riveter
   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

   Riveter~partialclaimed3/10

   Riveter's docs mention it 'reads PDFs and images' and combines results with web data (riveter-docs-18), implying some visual-content ingestion, but there is no explicit description of generating captions or text descriptions of images for downstream reasoning by a text-only model. Missing for 10: explicit captioning/description output format, example enrichment showing image-to-text extraction, and any confirmation this text is usable standalone by a text-only model.

   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ 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 drawn
   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

   Riveter—none0/10

   Riveter's quick_search explicitly returns only urls, titles, and snippets (not full page content), and its scrape tool requires a specific URL rather than combining search+content in one call. search_agent returns a single synthesized answer, not full page content per search result, so no evidenced single-call capability matches the story's exact requirement.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”

   proof ↗⚑ flag

Selector extraction

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

   weight 3 · round to Apify
   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

   Riveter—none0/10

   Riveter's docs describe AI-driven page interpretation and scraping (turning URLs into parseable text, agents reading pages 'the way a person would') rather than CSS/XPath selector rules; no evidence pack item mentions selector-based extraction at all, and one item explicitly frames the AI approach as an alternative to fragile configuration that would break on redesign, which is the kind of setup selectors typically require.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”

   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 drawn
   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

   Riveter—none0/10

   Riveter's evidence covers enrichment, scraping, search, and workflow automation, but there is no mention of chunking large tables, row batching, pagination for extraction limits, or handling of very large datasets to fit processing constraints. missing for 10: any mention of chunking strategy, table size limits, batching large extractions, or row-splitting logic.

   ⚑ flag

Headless rendering

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

   weight 3 · round to Apify
   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

   Riveter—none0/10

   Riveter is a data-enrichment/scraping/AI-agent tool focused on turning URLs into text and filling data columns; there is no evidence it renders JS-heavy SPAs into fully rendered HTML (e.g., headless browser rendering, DOM snapshot output). The 'scrape' feature converts URLs to 'easily parseable text', not full rendered HTML, so this capability is unevidenced.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—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

Interactive automation

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

   weight 2 · round drawn
   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

   Riveter—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

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

   weight 2 · round to Apify
   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

   Riveter—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

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

   weight 3 · round to Apify
   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

   Riveter—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

Render configuration

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

   weight 1 · round drawn
   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

   Riveter—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

Session persistence

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence in the pack mentions passing custom session cookies, auth headers, or cookie jars for scraping/enrichment requests; the docs describe scrapes, quick_search, and enrichments but not authenticated-page access via user-supplied cookies.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence Riveter offers persistent browser profiles, saved cookies, or login-state reuse across requests; its scraping is described as AI-agent page interpretation, not a session/profile management feature.

   ⚑ flag

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

   weight 2 · round to Apify
   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

   Riveter~partialprobed5/10

   Docs show many core capabilities (building enrichments via prompt/spec, scraping, quick_search, search_agent, webhooks, dry_run) are all API-accessible, suggesting broad parity, but there is no explicit statement of full UI/API parity and some UI-highlighted features like scheduling refresh (riveter-docs-13, riveter-docs-17) aren't confirmed as API-exposed. Additionally, probes show no discoverable OpenAPI spec (riveter-probe-2) or llms.txt (riveter-probe-1), undermining confidence that the API surface is fully documented/openly specified. missing for 10: explicit parity statement, API access to scheduling/monitoring feature, published OpenAPI spec for verification.

   • [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”

   proof ↗⚑ flag

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

   weight 3 · round to Apify
   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

   Riveter—none0/10

   No evidence of any data export feature or open-format export capability; the evidence only covers enrichment, scraping, search, and API integration features, with no mention of exporting data or portability guarantees. missing for 10: export functionality documentation, supported open formats (CSV/JSON/etc), any data-portability or account-closure workflow.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—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

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   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

   Riveter—none0/10

   Riveter is presented as a hosted API/SaaS product (with local MCP server option only for connecting AI clients, not for self-hosting the core enrichment engine); no evidence of open-source code, self-hosting instructions, or a downloadable core product exists in the pack.

   • [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
   • [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”

   proof ↗⚑ flag

Content formats

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

   weight 3 · round to Riveter
   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

   Riveter~partialclaimed5/10

   Docs state a scrape 'turns a URL into easily parseable text,' implying cleaned output rather than raw HTML, but there's no explicit mention of markdown formatting or output schema. Missing for 10: explicit confirmation that scrape output is markdown-formatted, example output showing markdown structure, independent verification of output cleanliness.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   Riveter's evidence pack covers enrichment, scraping, search, webhooks, and credit controls but never mentions selectable output formats like markdown, HTML, text, or frontmatter for returned data.

   ⚑ flag

3. developerReceive scraped content as structured JSON

   weight 3 · round to Riveter
   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

   Riveter✓fullclaimed7/10

   Riveter's enrichments and scrapes explicitly return structured, parseable data (columns, urls/titles/snippets, webhook payloads of 'full results'), and SDK examples show structured attribute objects returned from calls, indicating outputs are consumable as structured JSON rather than raw text. missing for 10: an explicit statement of JSON schema/response format in docs, and independent/hands-on confirmation of the JSON structure (API docs endpoints 404 in probes).

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”

   proof ↗⚑ 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 Apify
   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

   Riveter~partialclaimed5/10

   Docs claim a scrape converts any URL into 'easily parseable text' and that AI agents interpret pages 'the way a person would', directly addressing the ask for clean, LLM-ready text instead of raw HTML. However, all evidence is vendor documentation with no independent hands-on verification of output cleanliness, no example output shown, and no explicit mention of handling JS rendering/blocking obstacles beyond the general claim. Missing for 10: independent corroboration of scrape text quality, concrete example output, and explicit handling of anti-bot/rendering blockers.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”

   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 drawn
   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

   Riveter—none0/10

   Riveter's evidence describes enrichments, scrapes, searches, and structured row outputs, but nothing indicates a semantic-chunking output mode designed for retrieval pipelines (e.g., configurable chunk size/overlap, chunk metadata). Structured rows/columns are not the same as semantic chunking for RAG ingestion, and no such feature is documented.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”

   proof ↗⚑ flag

Visual capture

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

   weight 2 · round drawn
   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

   Riveter—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

Cost optimization

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   Riveter offers cost controls like dry_run estimates and max_credits caps that refuse overpriced requests, but there is no evidence the API automatically searches for or selects the cheapest configuration that still succeeds — it only estimates/caps, it doesn't auto-optimize. Missing for 10: any documentation of automatic configuration search/optimization for cost, fallback logic that retries cheaper options, or an API parameter that lets Riveter choose the minimal successful config itself.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Riveter—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

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

   weight 1 · round drawn
   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

   Riveter—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

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence anywhere in the pack of a control that lets users set reasoning effort (low/medium/high) for an agent's data-gathering task; only credit caps and dry-run cost estimation are documented, which are cost controls, not reasoning-effort controls.

   ⚑ 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
   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

   Riveter—none0/10

   The evidence describes credit estimation, dry_run, and max_credits cap that refuses requests at 422 before charging, but there is no mention of plan-level monthly credit/request quotas, nor whether exceeding them triggers overage billing or a hard cutoff. missing for 10: any documentation of monthly plan quotas, overage billing policy, or hard-cutoff behavior when a subscription limit is exceeded.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   The docs describe dry_run cost estimation and max_credits caps that prevent overage, but nothing states whether a failed, blocked, or empty-result run still consumes credits. Missing for 10: explicit policy on billing for failed/empty/blocked runs, any refund or non-charge guarantee for zero-result enrichments.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

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

   weight 3 · round to Riveter
   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

   Riveter~partialclaimed6/10

   Riveter offers per-request cost control via dry_run (credit estimate before charging) and max_credits (hard ceiling that returns 422 credit_cap_exceeded with nothing charged), which directly prevents a single run from blowing past a set budget. However, there's no evidence of an account-wide spending cap, recurring usage alerts, or a dashboard/notification system for cumulative consumption across runs. Missing for 10: account/org-level budget cap, proactive usage alerts/notifications, historical spend tracking dashboard.

   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

Performance tuning

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

   weight 1 · round to Riveter
   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

   Riveter✓fullclaimed7/10

   Riveter explicitly exposes multiple latency/completeness tradeoffs: quick_search returns fast synchronous structured snippets, search_agent runs a fuller AI research loop for one question, and full enrichments can be tracked via wait_for_result long-polling or async webhook callbacks — giving a developer direct control over when and how complete the returned content is. missing for 10: no independent/hands-on benchmarks or third-party confirmation of actual latency differences between these modes.

   • [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”

   proof ↗⚑ 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
   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

   Riveter—none0/10

   No evidence pack items mention pricing tiers, concurrency/rate limits, or the cost to raise such caps; only credit-cap controls (max_credits) and dry-run estimates are documented, which address per-request cost, not concurrent session limits or tier-based upgrade pricing.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence in the pack mentions data residency, regional storage options, or compliance controls for where data is stored; the docs focus entirely on enrichment features and API mechanics. Missing for 10: any mention of region selection, data residency options, or storage location controls.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for Riveter's stored enrichment data, run results, or scraped content.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or any opt-out mechanism for Riveter; the docs focus entirely on enrichment, scraping, and API features. Missing for 10: any mention of telemetry practices, privacy policy, or opt-out settings.

   ⚑ 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 Riveter
   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

   Riveter~partialclaimed3/10

   Riveter's search_agent and enrichment agent loop imply some autonomous research process that fills a cell with an AI-researched answer, suggesting the agent decides when it has enough data, but there is no explicit documentation of stopping criteria or adaptive crawling behavior tied to query sufficiency. missing for 10: explicit description of adaptive stopping/crawling logic, evidence of how the agent determines 'enough information', independent confirmation of this behavior in practice.

   • [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”

   proof ↗⚑ flag

Batch processing

1. data-engineerBatch scrape thousands of URLs asynchronously

   weight 3 · round drawn
   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

   Riveter~partialclaimed6/10

   Riveter's enrichment engine explicitly processes rows of URLs with scraping, runs asynchronously (webhook_url on completion), and SDKs handle retries, long-polling, and pagination — all core pieces for async batch scraping. However, there's no explicit documentation of scale limits, concurrency handling, or a tested example at thousands-of-URLs volume. Missing for 10: explicit large-scale (thousands of URLs) benchmarks or case studies, concurrency/rate-limit guidance for very large batches.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Riveter—none0/10

   No evidence describes applying different crawl configurations per URL pattern within one batch/enrichment job; docs mention scraping, searching, and enrichment generally but not per-pattern configuration rules. missing for 10: any mention of per-URL-pattern rules or configuration scoping within a single job, examples or docs showing mixed crawl settings in one batch.

   ⚑ flag

Concurrency

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

   weight 3 · round to Apify
   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

   Riveter~partialclaimed5/10

   Riveter's enrichment engine processes many rows in a single run and can chain scrapes/searches (e.g., finding every dental practice then every dentist in one request), implying built-in batch/bulk scraping at scale, and SDKs handle retries/pagination for large jobs. However, there is no explicit documentation of concurrency limits, parallel session management, or throughput guarantees for scraping specifically. Missing for 10: explicit concurrency/session limits, performance benchmarks, and independent evidence of scaling to many simultaneous scrape sessions.

   • [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”

   proof ↗⚑ flag

Crawl compliance

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence anywhere in the docs mentions robots.txt compliance or rate-limit configuration; the pack only covers scraping features, retries, credits, and MCP integration. This is a fair axis for a web-scraping/crawling product, but absence of evidence means it cannot be credited as delivered.

   ⚑ flag

Fault tolerance

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

   weight 2 · round drawn
   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

   Riveter—none0/10

   No evidence describes checkpointing or resuming a crashed deep crawl; the docs mention webhooks, dry runs, and credit caps but nothing about saving/resuming crawl state after a crash.

   ⚑ 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
   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

   Riveter—none0/10

   No evidence of a public status page, uptime history, or incident postmortems anywhere in the evidence pack; only product feature docs and API references are present.

   ⚑ 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 Riveter
   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

   Riveter~partialclaimed7/10

   Riveter explicitly supports scheduling projects to monitor for changes, refreshing as often as every minute, and can POST results to a webhook_url when a run finishes, which together deliver change-monitoring plus notification. However, the webhook fires on run completion rather than a dedicated 'content changed' diff event, and there's no independent/hands-on evidence of this workflow in production. Missing for 10: independent corroboration of the schedule+webhook pipeline in practice, and explicit diff/change-detection logic distinguishing 'changed' vs 'unchanged' pages.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”

   proof ↗⚑ flag

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

   weight 2 · round to Apify
   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

   Riveter~partialclaimed5/10

   Riveter supports webhook alerts on run completion/stop/finish events and scheduled monitoring for data freshness, giving some job-status alerting and monitoring capability, but there is no explicit data-quality validation feature (e.g., schema/anomaly checks) or job performance dashboards described. missing for 10: explicit data quality validation tooling, job performance metrics/dashboard, and independent confirmation of alerting reliability.

   • [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
   • [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”

   proof ↗⚑ flag

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

   weight 1 · round to Apify
   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

   Riveter—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

4. developerSchedule scraping jobs to run automatically at specific times

   weight 2 · round to Apify
   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

   Riveter~partialclaimed5/10

   Riveter supports scheduling projects to monitor for changes and refresh data as often as every minute, which implies automatic recurring scraping jobs, but there's no detail on specifying exact times/cron-like scheduling, timezone control, or a documented scheduling API/UI. missing for 10: explicit scheduling configuration details (time-of-day, cron syntax, timezone), independent/hands-on confirmation of scheduling reliability, and API endpoint documentation for creating/managing schedules.

   • [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
   • [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”

   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
   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

   Riveter—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

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

   weight 3 · round to Apify
   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

   Riveter~partialclaimed5/10

   Riveter's docs describe single-URL 'scrape' and 'quick_search' calls, but the marketing example of finding every dental practice in a city and pulling data from each one in a single request shows it can aggregate content across multiple pages/sources in one enrichment run, which approximates whole-site crawling. There is no explicit sitemap-style 'crawl entire website' feature or evidence of full-domain page enumeration. missing for 10: explicit full-site/sitemap crawl feature, evidence of automatically discovering and traversing all pages of a single domain, independent confirmation of multi-page crawl behavior.

   • [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
   • [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
   • [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Riveter—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