Bruno vs Hoppscotch

Agent access

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

   weight 2 · round to Hoppscotch
   Bruno✓fullprobed8/10

   Direct probe evidence confirms Bruno docs serve a working llms.txt at docs.usebruno.com/llms.txt with structured links to docs pages, which is exactly the agent-oriented docs entry point the story asks for. Missing for 10: no independent/community confirmation of agents actually consuming it, and no broader agent-specific documentation format beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed9/10

   A direct probe confirms llms.txt is live at docs.hoppscotch.io/llms.txt returning HTTP 200 with structured documentation content, and the docs also expose agent-oriented resources like an official MCP server and CLI overview pages that an agent could consume. Missing for 10: no independent/community confirmation of an agent actually consuming llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hoppscotch.io/llms.txt # Hoppscotch Documentation > Find user guides, quickstarts, tutorials, use …”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”

   proof ↗⚑ flag

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

   weight 2 · round to Bruno
   Bruno✓fullprobed9/10

   Bruno CLI is well-documented for running collections headlessly with JSON/JUnit/HTML reports, explicit CI/CD integration, official Docker images, and GitHub Actions support — directly enabling headless/CI automation. Missing for 10: independent hands-on CI pipeline reports beyond vendor docs.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed8/10

   Hoppscotch ships an official CLI (hopp) explicitly designed to run API tests, automate monitoring, and manage collections from the terminal or automated systems, including CI-friendly JUnit report generation for collection runs — directly enabling headless/CI automation. missing for 10: independent third-party CI pipeline examples/case studies confirming real-world CI usage beyond vendor docs.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Bruno—none0/10

   Bruno's docs describe AI features (BYOK script generation, AI chat sidebar) but no evidence anywhere mentions MCP server support or plugging in MCP tools for Bruno to use.

   ⚑ flag

   Hoppscotch—none0/10

   Evidence only shows Hoppscotch exposing itself AS an MCP server (agents can connect to Hoppscotch to read/change collections, requests, etc.), which is the reverse of the story — Hoppscotch acting as an MCP client that consumes other servers' tools. No evidence of Hoppscotch connecting to or ingesting external MCP servers to use their tools.

   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”

   proof ↗⚑ flag

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

   weight 3 · round to Hoppscotch
   Bruno—none0/10

   Bruno is an API client/CLI product where an official MCP server is a plausible feature (e.g., for AI agents to run collections), but no evidence pack item mentions an MCP server, MCP protocol, or agent-connection endpoint — only AI-assisted scripting/chat features (BYOK) are documented, which is a different capability.

   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
   • [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed7/10

   Hoppscotch documents an official MCP server (docs-10, docs-22, probe-3) that exposes collections, requests, environments, and teams to an agent and can execute real HTTP requests, directly matching the story. Missing for 10: independent/hands-on community verification of the MCP server's behavior and any deeper docs on setup/auth scopes beyond the overview page.

   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Hoppscotch
   Bruno✓fullprobed7/10

   Bruno ships an official CLI (`bru`) documented for running collections via simple commands, generating JSON/JUnit/HTML reports, and integrating into CI/CD and Docker pipelines — all features an AI agent or automated workflow could invoke non-interactively. Missing for 10: explicit documentation or examples of AI agents/automation frameworks directly invoking the CLI, and independent hands-on validation of its scripting robustness.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed8/10

   Hoppscotch ships an official CLI (hopp) documented for running API tests, automating monitoring, managing collections from the terminal, and generating JUnit reports, corroborated by a probe confirming the official docs page. missing for 10: independent/hands-on community confirmation of CLI usage and more detail on full command coverage.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”

   proof ↗⚑ flag

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

   weight 3 · round to Hoppscotch
   Bruno~partialprobed5/10

   Bruno ships a well-documented CLI (bru) that lets automation/AI agents run collections, generate reports, and integrate into CI/CD pipelines, and there is a docs llms.txt for AI consumption, but there is no true public HTTP/REST API or OpenAPI spec (probe confirms 404 on all openapi endpoints) that an AI agent could call directly. missing for 10: a documented HTTP/REST API or SDK beyond the CLI, official OpenAPI/swagger spec, and evidence of programmatic access outside the CLI wrapper.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed8/10

   Hoppscotch documents a first-party MCP server that lets an agent read and modify collections, requests, environments, and teams and send real HTTP requests, plus a CLI for terminal/automated interaction (running tests, managing collections) — both are officially documented programmatic interfaces suited to AI-native/agentic use. Missing for 10: a general public REST/OpenAPI API for the platform itself (probe found openapi.json/swagger.json all 404), so agentic access is limited to the MCP/CLI surface rather than a broader documented API.

   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hoppscotch.io/openapi.json, https://docs.hoppscotch.io/swagger.json, https://docs.hopps…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Bruno—none0/10

   Bruno documents secret management (vaults, GCP/Azure Key Vault integration) and a BYOK model for its own AI assistant, but there is no evidence of a feature to mint or scope least-privilege API credentials/tokens specifically for an external AI agent's use. missing for 10: any credential-issuance or scoping mechanism aimed at agents, documentation of granular permission scopes, or evidence of restricting an agent's API access via generated tokens.

   • [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”
   • [claimed-docs] “Azure CLI authentication feature allows you to authenticate with Azure Key Vault using your existing Azure CLI session, without requiring ma…”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Hoppscotch's MCP server docs describe granting an agent full read/write access to all collections, requests, environments, and teams, with no mention of scoped, least-privileged, or permission-limited credentials for agents. No evidence describes issuing restricted API keys/tokens specifically for AI agent use.

   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Bruno—none0/10

   Evidence shows Bruno offers a CLI (bru-cli), Docker images, and a Bru markup format, but no official SDKs (e.g., client libraries in Python/JS/Go) for programmatic integration are documented anywhere in the pack.

   ⚑ flag

   Hoppscotch—none0/10

   Evidence shows Hoppscotch offers a CLI, an MCP server, and AI-assisted scripting features, but there is no mention of official client SDKs (e.g., language libraries for programmatically building or extending Hoppscotch) anywhere in the docs or GitHub feature list.

   ⚑ flag

Agentic features

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

   weight 2 · round to Bruno
   Bruno~partialclaimed7/10

   Bruno's docs describe multiple in-product AI features: ghost-text script suggestions, an AI icon that generates scripts from descriptions, an AI chat sidebar for workspace-wide questions, and AI generation of collections from backend code or full apps — all clearly 'AI-generated insights/suggestions inside the product'. However, all evidence is first-party documentation with no independent/hands-on corroboration of quality or reliability, and it's a BYOK add-on rather than a fully vetted core capability. Missing for 10: independent/community validation of AI feature quality, and evidence of AI 'insights on data' (e.g., response analysis) beyond scripting/chat/generation use cases.

   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
   • [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
   • [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
   • [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Hoppscotch docs explicitly reference AI features including renaming API requests, generating structured request payloads, and scripting for pre-request/test logic, which count as AI-generated suggestions inside the product. However, evidence does not show deeper 'insights' from data (e.g., analyzing response data, anomaly detection, test result summarization) beyond these request-authoring helpers, and there's no independent/hands-on corroboration of these AI features' quality. missing for 10: evidence of AI-generated insights from response/test data (not just request scaffolding), independent user validation of AI feature usefulness.

   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Bruno~partialclaimed4/10

   Bruno's CLI and CI/CD integration (bruno-docs-1,3,18,30) let you run collections unattended in pipelines like GitHub Actions or Docker, which is a form of background automation, but this is traditional scripted/CI automation rather than an AI-native agent autonomously deciding and scheduling actions. Bruno AI features (bruno-docs-37 to 42) are interactive, BYOK assistants for generating scripts/collections, not autonomous background agents. Missing for 10: evidence of scheduled/triggered autonomous runs initiated by AI, agent-driven decision loops, or any 'set it and forget it' automation beyond manual CI/CD wiring.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”

   proof ↗⚑ flag

   Hoppscotch~partialprobed4/10

   Hoppscotch's CLI supports running API tests/monitoring from the terminal, which can be scheduled via external cron/CI systems, but this requires an external scheduler rather than a native autonomous background automation/trigger system built into the product. There's no evidence of built-in schedulers, webhooks-triggered runs, or agent-orchestrated autonomous workflows. missing for 10: native scheduling/trigger engine, evidence of autonomous background execution without external cron/CI, monitoring automation details, independent confirmation of unattended runs.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”

   proof ↗⚑ flag

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

   weight 3 · round to Bruno
   Bruno~partialclaimed6/10

   Bruno AI offers in-app AI assistance: script generation, ghost-text suggestions, an AI chat sidebar, and generating collections/apps from context, all documented first-party (bruno-docs-37 to 42). However this is BYOK-only, largely scoped to scripts/collections/UI generation rather than broad task delegation, and there is no independent/hands-on corroboration of its effectiveness. missing for 10: independent verification of AI assistant quality, evidence of broader agentic task delegation beyond scripting/UI generation, and confirmation this isn't a limited/beta feature.

   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
   • [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
   • [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
   • [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Docs mention built-in AI features (auto-renaming requests, generating structured request payloads, and scripting for pre-request/test logic), showing some in-product AI delegation of specific tasks, but there's no evidence of a general-purpose conversational AI assistant that a user can delegate broader tasks to. Missing for 10: detailed documentation of assistant scope/UI, examples of multi-step task delegation, and independent/hands-on corroboration of these AI features in use.

   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Bruno~partialclaimed6/10

   Bruno AI lets users describe what they need in natural language to generate scripts, chat with an AI sidebar, and generate full collections/apps from descriptions, which is genuine natural-language operation of parts of the product. However this is scoped to scripts/collections/app generation rather than full natural-language control of all core workflows (running requests, git operations, environment management still require GUI/CLI, not NL commands). missing for 10: evidence of natural-language control over core request execution/CLI operations, independent hands-on validation of Bruno AI's NL features, and confirmation this isn't limited to a paid/BYOK tier.

   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
   • [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
   • [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”

   proof ↗⚑ flag

   Hoppscotch~partialprobed6/10

   Hoppscotch ships an official MCP server that hands an AI agent read/write access to collections, requests, environments and teams and lets it send real HTTP requests, effectively letting a natural-language-driven agent operate the product (hoppscotch-docs-10, hoppscotch-docs-22, hoppscotch-probe-3). There's also a docs page on in-app 'AI features' covering request renaming, payload generation, and script generation, suggesting some native NL-assisted actions (hoppscotch-docs-23). However, the MCP path requires an external AI client/agent rather than a built-in chat interface, and the AI-features doc is only a single thin line with no concrete examples or independent corroboration. Missing for 10: a first-party in-app natural-language command bar/chat demonstrated end-to-end, richer documentation/examples of the AI features, and independent/hands-on confirmation that these NL capabilities work as described.

   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Hoppscotch
   Bruno~partialprobed4/10

   Bruno lets users write documentation alongside their collections and publish it as shareable HTML, and requests/collections are inherently runnable examples (bruno-docs-20, bruno-docs-27), which is the closest match to an 'interactive reference with runnable examples.' However, there is no evidence of an actual interactive API explorer (e.g., OpenAPI/Swagger-style try-it-out UI) — a probe for OpenAPI/Swagger endpoints on Bruno's own docs returned 404s (bruno-probe-2), and no community or hands-on evidence confirms the published HTML docs are truly interactive/executable rather than static. Missing for 10: evidence of a live interactive reference UI, independent confirmation that published docs are runnable (not just readable), and AI-specific tooling around this reference.

   • [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
   • [claimed-docs] “Embed a button in your README so anyone can open your workspace or collection in Bruno.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Hoppscotch's Embed feature lets users create a mini-version of Hoppscotch embeddable in HTML pages so an audience can interact with API requests, which is a form of interactive, runnable API reference, and OpenAPI import can seed collections for such a reference. However there is no evidence of a dedicated 'API reference/documentation' generator with narrative docs plus embedded runnable examples (like Swagger UI or Postman's published docs), nor independent corroboration of the Embed feature in practice. Missing for 10: auto-generated narrative API reference pages, publishing/sharing workflow for such references, hands-on validation of the Embed feature.

   • [claimed-docs] “Embed: Create a mini-version of Hoppscotch that you can embed in an HTML page, allowing your audience to interact with your API request.”
   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”
   • [claimed-docs] “You can enter the API endpoint and choose the HTTP method according to your needs from the dropdown menu. Once it is configured, click on th…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Bruno—none0/10

   Bruno is a desktop/CLI API client with no public web API of its own, but the axis is still fair to ask (e.g., an OpenAPI export/spec for AI agents to consume). Direct probing found no OpenAPI/Swagger spec (all candidate paths 404) — only an llms.txt docs index exists, which is not a machine-readable API spec. Missing for 10: any OpenAPI/Swagger JSON or equivalent structured spec, first-party docs describing one, and community confirmation of its existence.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   A direct probe for OpenAPI/Swagger specs at the Hoppscotch docs domain returned 404 on all candidate paths, and no other evidence shows a downloadable machine-readable spec of Hoppscotch's own API surface (the only OpenAPI-related mention is about importing external OpenAPI specs into Hoppscotch, not exposing one).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hoppscotch.io/openapi.json, https://docs.hoppscotch.io/swagger.json, https://docs.hopps…”
   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”

   proof ↗⚑ flag

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

   weight 1 · round to Bruno
   Bruno~partialclaimed5/10

   Bruno supports environment variables, global env overrides, and mock responses, which let users point requests at different (e.g. sandbox) environments and separate them from production, and its offline-first, no-cloud-sync design (bruno-docs-8, bruno-docs-9) keeps data local rather than sent to a vendor. However, there is no explicit documentation of a dedicated 'sandbox mode' or built-in safeguards preventing accidental production calls, and no AI-agent-specific sandbox testing workflow is described. Missing for 10: explicit sandbox/staging environment isolation feature, guardrails against hitting production endpoints, and AI-agent-specific evidence of sandboxed test execution.

   • [claimed-docs] “Serve realistic mock responses while you build.”
   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “add --global-env-var to override global environment variables at runtime”

   proof ↗⚑ flag

   Hoppscotch~partialprobed3/10

   Hoppscotch supports environment/variable management (including secret variables) and the MCP server exposes environments/collections to agents so a sandbox environment could in principle be selected, but there is no explicit feature or documentation describing isolation, safety checks, or a dedicated 'sandbox vs production' mode that prevents an agent from touching production data — the MCP docs even note it 'sends real HTTP requests.' Missing for 10: explicit sandbox-environment safeguard/isolation feature, documentation of environment-scoped access control for agents, and independent evidence confirming this prevents production impact.

   • [claimed-docs] “Secret variables in environments.”
   • [claimed-docs] “Request variables.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Bruno—none0/10

   Evidence shows Bruno ships versioned releases/changelogs (e.g., CLI v4.1.0, release notes) but nothing documents an explicit API/CLI deprecation policy or versioning guarantees that an AI-native user could rely on.

   ⚑ flag

   Hoppscotch—none0/10

   No evidence of API versioning scheme or documented deprecation policy for Hoppscotch's own APIs/products; changelog shows feature releases but no version numbers or deprecation notices. Missing for 10: versioning scheme documentation, deprecation policy, migration guides, version support timeline.

   ⚑ flag

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

   weight 2 · round to Bruno
   Bruno✓fullprobed7/10

   Bruno CLI lets you run entire collections (many requests) from the command line with data-driven testing, generate consolidated reports, and integrate into CI/CD pipelines or Docker/GitHub Actions, which is a clear bulk-automation workflow across many API items at once. Missing for 10: independent/hands-on evidence of bulk operations at scale (e.g., large collection performance) and explicit documentation of bulk editing/manipulation of items beyond running them.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed6/10

   The CLI can execute an entire collection of requests in one command with JUnit reporting, and the MCP server lets an agent read/change collections, requests, environments, and teams programmatically, both of which support automation-style bulk actions across many items. However, there's no explicit documentation of a dedicated bulk-edit/bulk-delete/bulk-update operation spanning many items at once (e.g. batch renaming, batch parameter changes) beyond running/exporting collections. missing for 10: explicit bulk edit/update/delete API or UI across many requests/items simultaneously, independent hands-on confirmation of large-scale automation runs.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”

   proof ↗⚑ flag

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

   weight 3 · round to Bruno
   Bruno~partialclaimed4/10

   Bruno supports pre-request and post-response JavaScript that runs automatically on those request lifecycle events, and CI/CD integration lets test suites run automatically on pipeline events, but there is no general-purpose rule/trigger engine for arbitrary events. missing for 10: a configurable rules/event system beyond request/response scripts, support for custom triggers or webhooks, and any evidence of broader automation orchestration.

   • [claimed-docs] “Pre-request and post-response JavaScript — the `bru` API, request chaining, and libraries.”
   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Hoppscotch offers pre-request/test scripts (gh-5) and a CLI for scheduled/automated test runs (docs-8, docs-21), but there is no evidence of a rules engine or event-triggered automation (e.g., 'when X happens, do Y') as described in the story.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Bruno
   Bruno~partialclaimed3/10

   Bruno CLI can be run inside CI/CD pipelines (GitHub Actions, Docker) which could be scheduled externally via cron/CI triggers, but there is no evidence of a native scheduler or built-in recurring-job feature within Bruno itself. missing for 10: any built-in scheduling UI/feature, documentation of cron-like triggers within Bruno, independent confirmation of scheduled runs.

   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Hoppscotch offers a CLI for running tests/monitoring and an MCP server for agent access, but there is no evidence of any scheduler, cron-like trigger, or recurring workflow orchestration feature — automation still requires an external scheduler (e.g., cron, CI) to invoke the CLI repeatedly. missing for 10: any built-in scheduling/recurrence mechanism, workflow chaining across multiple requests, or trigger-based automation.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”

   proof ↗⚑ flag

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

   weight 1 · round to Bruno
   Bruno✓fullcommunity7/10

   Bruno stores collections/scripts as plain-text files and ships a native Git UI (init, diff, pull, clone, commit) letting users version and review changes to their API automations like code, with community confirmation of the git-collaboration workflow. Explicit rollback is implied via standard git operations (checkout/revert) rather than a dedicated in-app 'rollback' feature. Missing for 10: explicit documented rollback/undo UI beyond generic git commands, independent evidence of reviewing/rolling back script changes specifically.

   • [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
   • [claimed-docs] “Core Git UI features (init, view diffs, check for updates, pull, clone) are now available in the free version.”
   • [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
   • [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
   • [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
   • [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   No evidence Hoppscotch offers versioning, review workflows, or rollback for automations/scripts/collections; a GitHub issue explicitly requests git-friendly storage/sync as an unmet feature, indicating this capability doesn't exist today.

   • [community] “Would be nice to sync storage over git. My team runs into this problem with Postman and any other web request UI out there - that the web re…”

   proof ↗⚑ flag

Ci

1. developerRun my API test collections in CI with a CLI and fail the build on regressions

   weight 3 · round to Bruno
   Bruno✓fullprobed8/10

   Bruno CLI is well documented for running collections headlessly, generating JUnit/JSON/HTML reports for CI analysis, and integrating with CI/CD pipelines (Docker, GitHub Actions), which directly supports failing builds on test regressions. missing for 10: explicit documentation/example of exit-code-based build failure and independent hands-on CI usage report beyond vendor docs.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch~partialprobed7/10

   Hoppscotch ships an official CLI (hopp) explicitly documented for running API test collections and automated monitoring from the terminal, with JUnit report generation for CI integration (hoppscotch-docs-8, hoppscotch-docs-9, hoppscotch-docs-21, hoppscotch-probe-4). However, the evidence never explicitly documents exit-code/fail-on-regression behavior or shows independent hands-on CI pipeline examples. Missing for 10: explicit documentation of non-zero exit codes on test failure, and independent/community confirmation of CI usage.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”

   proof ↗⚑ flag

Monitors

1. developerSchedule collection runs as monitors that alert me when an API breaks

   weight 2 · round to Hoppscotch
   Bruno—none0/10

   Bruno's docs show CLI runs, CI/CD pipeline integration, and JUnit/HTML/JSON reports, but there is no evidence of a built-in monitor/scheduler feature that runs collections on a schedule and alerts on failures — that requires wiring Bruno CLI into an external scheduler (e.g. cron/CI cron jobs) rather than a native monitoring product feature. missing for 10: a documented native scheduling/monitor feature, built-in alerting (email/Slack/webhook) on failed runs, any dashboard for monitor history.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed4/10

   Hoppscotch's CLI docs mention the ability to 'automate monitoring' and 'manage automated API monitoring' via collection runs, implying it can be scripted/scheduled externally (e.g., via cron/CI) to catch API failures, and can output JUnit reports for CI integration. However, there is no evidence of a built-in monitor scheduler or native alerting/notification mechanism (email, Slack, webhook) when a run fails. Missing for 10: dedicated 'Monitors' feature with scheduling UI, built-in alert/notification delivery on failure, independent confirmation of this workflow.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”

   proof ↗⚑ flag

Scripting

1. developerScript pre-request and post-response logic to chain requests and massage data

   weight 2 · round to Bruno
   Bruno✓fullclaimed8/10

   Bruno documents pre-request and post-response JavaScript scripting with a `bru` API for request chaining and data manipulation, plus test suites and data-driven testing to automate runs. Missing for 10: independent hands-on community corroboration specifically validating scripting/chaining behavior (community evidence focuses on other features like git/cookies) and more detail on complex chaining edge cases.

   • [claimed-docs] “Pre-request and post-response JavaScript — the `bru` API, request chaining, and libraries.”
   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed6/10

   GitHub feature list explicitly confirms pre-request scripting ('Snippets of code... executed before the request is sent'), and the AI-features doc mentions 'scripting capabilities for pre-request logic and test cases', implying post-response test scripts exist too. However, no dedicated documentation details post-response script syntax, variable-setting APIs, or examples of chaining/massaging data across requests. missing for 10: explicit post-response/test-script documentation, examples of setting/reading environment variables between chained requests, independent hands-on confirmation of scripting workflow.

   • [github] “Snippets of code associated with a request that is executed before the request is sent.”
   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”

   proof ↗⚑ flag

Access control

1. platform-engineerControl who can view or edit APIs and collections with roles and permissions

   weight 2 · round to Hoppscotch
   Bruno—none0/10

   Bruno relies on git-based collaboration and filesystem storage rather than any documented role-based access control or permissions system for collections; no evidence pack item mentions roles, permission levels, or access control for viewing/editing collections.

   ⚑ flag

   Hoppscotch~partialclaimed4/10

   Hoppscotch has team collaboration features and an admin dashboard with 'enhanced user management' plus enterprise SSO/audit logs, implying some access-control capability, but there is no explicit documentation of granular roles/permissions for viewing vs editing specific APIs or collections. missing for 10: explicit role/permission model docs (e.g. viewer vs editor roles per collection), evidence of enforcement, independent confirmation of granular access control.

   • [github] “Helps you collaborate across your teams to design, develop, and test APIs faster.”
   • [claimed-docs] “Enhanced user management in admin dashboard.”
   • [claimed-docs] “You can manage your server configurations directly from the self-host admin dashboard.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”

   proof ↗⚑ flag

Api catalog

1. platform-engineerPublish an internal catalog or portal where teams discover and consume our APIs

   weight 2 · round drawn
   Bruno~partialclaimed4/10

   Bruno lets teams write and publish collection docs as shareable HTML and embed 'open in Bruno' buttons in READMEs, and its Git-native storage enables shared, discoverable collections across a repo/monorepo — a lightweight substitute for a catalog. However there is no dedicated internal developer-portal, no searchable catalog UI, and no cloud-hosted discovery surface (explicitly no cloud sync/account). missing for 10: a true portal/catalog UI, cross-team search/discovery beyond Git repos, hosted publishing beyond static HTML docs.

   • [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
   • [claimed-docs] “Embed a button in your README so anyone can open your workspace or collection in Bruno.”
   • [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
   • [claimed-docs] “open multiple collections from a monorepo”
   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed4/10

   Hoppscotch offers an 'Embed' feature to expose a mini API-interaction UI in a page and team/collection sharing for collaboration, which can serve as a lightweight internal portal, but there is no dedicated catalog/discovery portal product (no API marketplace, search, or documentation-portal feature) documented. missing for 10: a dedicated API catalog/portal product, discovery/search across published APIs, and evidence of teams actually using it as an internal developer portal.

   • [claimed-docs] “Embed: Create a mini-version of Hoppscotch that you can embed in an HTML page, allowing your audience to interact with your API request.”
   • [github] “Helps you collaborate across your teams to design, develop, and test APIs faster.”
   • [claimed-docs] “You can add multiple requests to a collection and even create subfolders inside a collection to further organize your requests.”

   proof ↗⚑ flag

Team workspaces

1. developerShare collections with my team in a synced shared workspace

   weight 3 · round to Hoppscotch
   Bruno~partialcommunity5/10

   Bruno enables team sharing of collections via native Git integration (plain-text files, built-in Git UI, init/diff/pull/commit) rather than a cloud-synced workspace, and community reports confirm this works well in practice (bruno-comm-2, bruno-comm-7). However, Bruno explicitly states it has no cloud sync and never will, requiring git know-how instead of a true synced shared workspace experience. Missing for 10: real-time/automatic cloud sync, a dedicated shared-workspace UI independent of git, and conflict resolution beyond git merges.

   • [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
   • [claimed-docs] “Core Git UI features (init, view diffs, check for updates, pull, clone) are now available in the free version.”
   • [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
   • [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
   • [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”

   proof ↗⚑ flag

   Hoppscotch~partialcommunity6/10

   Hoppscotch documents Teams/workspace collaboration features (shared collections, headers/auth applied at collection level, admin dashboard, SSO) and GitHub explicitly claims it 'helps you collaborate across your teams to design, develop, and test APIs faster,' with community evidence confirming easy collection sharing. However, evidence also surfaces real gaps: a feature request shows syncing/storage across teams (e.g., git-based sync) is unmet, self-hosted login/workspace sync in the desktop app is limited, and some enterprise-grade sync features (SSO, audit logs) are gated behind paid tiers. Missing for 10: independent verification of real-time sync fidelity across team members, clarity on offline/desktop workspace sync limitations, and confirmation that core sharing works without hitting paywalled features.

   • [github] “Helps you collaborate across your teams to design, develop, and test APIs faster.”
   • [claimed-docs] “When you add a header or auth to a collection, it will be applied to all requests in that collection.”
   • [community] “Love hoppscotch! Moved to it from postman back in the postwoman days. They really cleaned up the UI recently, made saving and sharing collec…”
   • [community] “It has a clean UI and can be self-hosted. The downside is - Only one workspace is available when offline. You can't point your Workspace dat…”
   • [community] “Would be nice to sync storage over git. My team runs into this problem with Postman and any other web request UI out there - that the web re…”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”

   proof ↗⚑ flag

Collections

1. developerStore collections as plain text files in my repo and version them with git

   weight 3 · round to Bruno
   Bruno✓fullcommunity10/10

   Bruno stores collections as plain-text .bru files on the filesystem, explicitly designed for git versioning, with native Git UI support and CLI/terminal workflows; this is strongly corroborated by first-party docs and independent community testimonials confirming real-world use.

   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
   • [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
   • [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
   • [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
   • [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”
   • [claimed-docs] “Switched from Postman to @use_bruno and I'm not going back. Collections are plain text files in Git.”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   There is no evidence Hoppscotch stores collections as plain-text files suitable for git version control; instead, community evidence explicitly shows this is a requested-but-unimplemented feature (an open GitHub issue asking Hoppscotch to make storage git-friendly) and a comparison noting Bruno supports directory-based storage while Hoppscotch does not let you point a workspace to a specific directory.

   • [community] “Would be nice to sync storage over git. My team runs into this problem with Postman and any other web request UI out there - that the web re…”
   • [community] “It has a clean UI and can be self-hosted. The downside is - Only one workspace is available when offline. You can't point your Workspace dat…”

   proof ↗⚑ flag

2. developerImport and export collections in portable formats to move between tools

   weight 2 · round to Bruno
   Bruno~partialclaimed7/10

   Bruno documents importing existing Postman collections and even a 'preserve scripts' option for Postman import/export, plus its own portable plain-text .bru format that lives on the filesystem for easy sharing/versioning. However, evidence only covers Postman interoperability and lacks documentation of exporting to other formats (e.g., OpenAPI, Insomnia) or independent confirmation of import fidelity. Missing for 10: explicit export-to-Postman/OpenAPI support, broader multi-tool interoperability, and hands-on community verification of import/export accuracy.

   • [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
   • [claimed-docs] “feat: add preserve scripts option for Postman import/export”
   • [claimed-docs] “add preserve scripts option for Postman import/export”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”

   proof ↗⚑ flag

   Hoppscotch~partialcommunity5/10

   Docs and GitHub evidence show robust import support (cURL import, OpenAPI import with tag-based folder organization, collections/folders organization) but there is no explicit documentation of exporting collections to portable formats, and a community feature request (git-friendly storage sync) suggests export/interop is limited. missing for 10: explicit export-to-file/format documentation, independent confirmation of round-trip export/import between tools like Postman.

   • [github] “Import cURL”
   • [github] “Import `cURL`”
   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”
   • [github] “Keep your API requests organized with collections and folders. Reuse them with a single click.”
   • [community] “Love hoppscotch! Moved to it from postman back in the postwoman days. They really cleaned up the UI recently, made saving and sharing collec…”
   • [community] “Would be nice to sync storage over git. My team runs into this problem with Postman and any other web request UI out there - that the web re…”

   proof ↗⚑ flag

3. developerOrganize API requests into collections and folders and rerun them anytime

   weight 3 · round to Hoppscotch
   Bruno✓fullcommunity8/10

   Bruno stores collections as plain-text files/folders on the filesystem (supporting folder-based organization), integrates with Git for versioning, and provides a CLI plus GUI to rerun collections anytime, corroborated by community testimonials praising collection organization and git-based rerun workflows. missing for 10: explicit documentation of nested folder hierarchies/UI screenshots and independent hands-on verification of large/complex folder structures.

   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
   • [claimed-docs] “you can run your API collections with ease using simple command line commands”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
   • [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”

   proof ↗⚑ flag

   Hoppscotch✓fullcommunity9/10

   Hoppscotch explicitly documents organizing requests into collections and subfolders, reusing them with a single click, and applying shared headers/auth at the collection level, backed by both first-party docs and GitHub feature list; community reviews corroborate collections/saving as a core, easy-to-use feature. Missing for 10: deeper independent hands-on evidence of long-term rerun workflows across large collections.

   • [claimed-docs] “You can add multiple requests to a collection and even create subfolders inside a collection to further organize your requests.”
   • [claimed-docs] “When you add a header or auth to a collection, it will be applied to all requests in that collection.”
   • [github] “Keep your API requests organized with collections and folders. Reuse them with a single click.”
   • [community] “Love hoppscotch! Moved to it from postman back in the postwoman days. They really cleaned up the UI recently, made saving and sharing collec…”

   proof ↗⚑ flag

Offline

1. developerWork fully offline in a local workspace without a cloud account

   weight 2 · round to Bruno
   Bruno✓fullcommunity9/10

   Bruno explicitly markets itself as offline-only with no account/cloud sync required, storing collections as plain text on the local filesystem, corroborated by community users praising the offline-first design after moving from cloud-first tools like Postman/Insomnia. missing for 10: independent audit confirming zero network calls beyond user-initiated ones.

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”

   proof ↗⚑ flag

   Hoppscotch~partialcommunity6/10

   Hoppscotch offers a desktop app, installable PWA, and self-hosted deployment with login clearly optional (hoppscotch-docs-29, hoppscotch-docs-13, hoppscotch-comm-9), supporting local/offline use without a cloud account. However, hands-on community evidence shows real limits: 'Only one workspace is available when offline. You can't point your Workspace data to a specific directory like bruno does. Self-hosting login is not possible in the desktop app' (hoppscotch-comm-10), and installing self-hosted locally was reported as unclear/undocumented at one point (hoppscotch-comm-2, hoppscotch-comm-3). Missing for 10: multi-workspace offline support, directory-based local workspace storage, and clearer first-party docs/independent confirmation of a fully-featured offline-only workflow.

   • [claimed-docs] “Hoppscotch Desktop App is a cross-platform desktop application that helps you create and manage API requests.”
   • [claimed-docs] “No installation is required.”
   • [community] “Nice. Downloaded and installed. Clean UI (almost bordering on a rip-off of Postman.. but I guess familiarity helps users get going faster). …”
   • [community] “It has a clean UI and can be self-hosted. The downside is - Only one workspace is available when offline. You can't point your Workspace dat…”
   • [community] “Am I going crazy or is there no way to install this locally apart from a 'development' setup with git clone or docker?”

   proof ↗⚑ flag

Protocols

1. developerSend GraphQL, gRPC, WebSocket, and SSE requests, not just REST

   weight 2 · round to Hoppscotch
   Bruno—none0/10

   No documentation in the evidence pack mentions GraphQL, gRPC, WebSocket, or SSE support; community feedback explicitly states Bruno lacks GraphQL, gRPC, and WebSocket support ('Only missing Websockets functionality', 'Doesn't seem to support advanced stuff like GraphQL, gRPC, WebSockets').

   • [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
   • [community] “Doesn't seem to support advanced stuff like GraphQL, gRPC, WebSockets...”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed6/10

   GitHub evidence explicitly confirms GraphQL support and full-duplex (WebSocket-like) communication over a single TCP connection, but there's no direct evidence for gRPC or SSE support, and no independent/hands-on corroboration of actually sending requests via these protocols. missing for 10: explicit gRPC support evidence, SSE support evidence, hands-on confirmation of sending GraphQL/WebSocket requests.

   • [github] “GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.”
   • [github] “Establish full-duplex communication channels over a single TCP connection.”

   proof ↗⚑ flag

Environments

1. developerSwitch requests between dev, staging, and prod using environment variable sets

   weight 3 · round to Bruno
   Bruno~partialclaimed6/10

   Docs confirm Bruno has an environment selector with search filtering, drag-and-drop variable management, and CLI overrides via --global-env-var, all indicating a working environment/variable-set system for switching contexts. However, no evidence explicitly documents a dev/staging/prod workflow or environment creation/management UI in depth. Missing for 10: explicit documentation of creating and switching between multiple named environments (e.g. dev/staging/prod), and independent hands-on confirmation of environment-switching UX.

   • [claimed-docs] “add --global-env-var to override global environment variables at runtime”
   • [claimed-docs] “adding search filter to environment selector dropdown”
   • [claimed-docs] “support drag-and-drop and alphabetical sorting for variables”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Docs confirm the existence of an environments system (with secret variables and request variables that resolve within environments), implying multiple environment sets can be defined and swapped, but no direct evidence describes selecting/switching between dev/staging/prod environments or a dropdown UI for env selection. missing for 10: explicit documentation or screenshot of environment switcher UI, workflow for maintaining separate dev/staging/prod variable sets, and independent/community confirmation of this specific switching behavior.

   • [claimed-docs] “Secret variables in environments.”
   • [claimed-docs] “Request variables.”

   proof ↗⚑ flag

Secrets

1. platform-engineerKeep credentials out of shared files with masked secrets or an external vault integration

   weight 2 · round to Bruno
   Bruno✓fullclaimed8/10

   Bruno docs explicitly state you can 'keep credentials out of version control with secret variables and vaults' and detail concrete external vault integrations (GCP Secret Manager, Azure Key Vault CLI authentication), directly matching the platform-engineer story on masked secrets and vault integration. missing for 10: independent/hands-on confirmation that masked secrets actually hide values in the UI and broader vault provider coverage beyond GCP/Azure.

   • [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”
   • [claimed-docs] “feat(secrets): add GCP Secret Manager support”
   • [claimed-docs] “add GCP Secret Manager support”
   • [claimed-docs] “Azure CLI authentication feature allows you to authenticate with Azure Key Vault using your existing Azure CLI session, without requiring ma…”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed6/10

   Hoppscotch docs explicitly list 'Secret variables in environments' as a changelog feature, directly matching the masked-secrets need, and self-host docs mention on-prem deployment and audit logs for enterprise-grade control. However, there is no evidence of an external vault integration (e.g., Vault, AWS Secrets Manager) or independent/hands-on confirmation of how secret variables are masked in shared collection files. Missing for 10: external vault/secret-manager integration, hands-on verification that secrets are excluded from exported/shared collection files, and independent corroboration beyond the vendor changelog.

   • [claimed-docs] “Secret variables in environments.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”
   • [claimed-docs] “Self-host Hoppscotch on your own infrastructure with full data ownership.”

   proof ↗⚑ flag

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

   weight 2 · round to Bruno
   Bruno~partialprobed6/10

   Bruno ships a genuine CLI (bru) that can run collections, generate JSON/JUnit/HTML reports, and integrate into CI/CD/Docker pipelines, and collections are stored as plain text files that can be edited/versioned outside the UI — a solid API-like automation path. However, there is no true HTTP/REST API (openapi probe returned only 404s) and many UI-only capabilities (AI script generation/chat, drag-and-drop editing, GUI-based Git diff/commit workflow, app-building) have no documented CLI/API equivalent, so full UI parity is not evidenced. missing for 10: a first-class programmatic API beyond the CLI, CLI equivalents for AI features and collection editing/Git UI actions, independent confirmation of CLI/UI feature parity.

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch~partialprobed5/10

   Hoppscotch offers a CLI for running tests/monitoring/collection management and an MCP server that lets an agent read and modify collections, requests, environments, and teams and send real HTTP requests, giving substantial programmatic parity with core UI actions. However, there is no documented general-purpose REST/GraphQL API (probe found no OpenAPI/swagger spec), and features like team collaboration, SSO/admin settings, or UI-specific extras (themes, PWA, client certs) aren't shown as scriptable. Missing for 10: a documented public API covering full UI feature parity, evidence for automating admin/enterprise/team-collab features, and independent confirmation of CLI/MCP completeness.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [probe] “official MCP server documented at https://docs.hoppscotch.io/documentation/clients/mcp-server/overview”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hoppscotch.io/openapi.json, https://docs.hoppscotch.io/swagger.json, https://docs.hopps…”

   proof ↗⚑ flag

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

   weight 3 · round to Bruno
   Bruno✓fullcommunity8/10

   Bruno stores collections as plain-text .bru files directly on the local filesystem with no cloud lock-in, no account required, and offline-only by design, making export trivial — data is already in an open, human-readable format under user control and versionable via Git. Postman import/export is also supported for migration. missing for 10: no explicit one-click 'export all data' bulk command/tool is documented, and no independent hands-on confirmation of full data portability beyond community praise for the plain-text/git model.

   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
   • [claimed-docs] “Switched from Postman to @use_bruno and I'm not going back. Collections are plain text files in Git.”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Hoppscotch is fully open-source (MIT) and can be self-hosted with 'full data ownership' (hoppscotch-docs-11, hoppscotch-docs-14, hoppscotch-docs-24), and its CLI/MCP server can read and manage collections, environments and requests in structured form (hoppscotch-docs-8, hoppscotch-docs-10, hoppscotch-docs-22), implying data is accessible outside the UI. However, there is no explicit documentation of a dedicated 'export' feature or open file format (e.g. JSON export of collections) for a user to take their data and leave, only import (cURL, OpenAPI) is explicitly evidenced. missing for 10: explicit export/download-my-data feature documentation, confirmation of an open interchange format for collections/environments, independent confirmation that self-hosted data is fully portable without vendor lock-in.

   • [claimed-docs] “Hoppscotch Community Edition is free and open-source. It is licensed under the MIT License.”
   • [claimed-docs] “Self-host Hoppscotch on your own infrastructure with full data ownership.”
   • [claimed-docs] “For full data ownership and control over your API development and testing, you can self-host Hoppscotch on your infrastructure.”
   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you.”
   • [claimed-docs] “It hands the host your collections, requests, environments, and teams, so an agent can read and change them for you. It also sends real HTTP…”
   • [github] “Import cURL”

   proof ↗⚑ flag

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

   weight 2 · round to Hoppscotch
   Bruno~partialclaimed4/10

   Evidence repeatedly references the public GitHub repo (usebruno/bruno) and its release history, implying the source is publicly readable, but no citation explicitly states an open-source license (e.g., MIT) or points to a LICENSE file. Missing for 10: explicit license statement/citation, confirmation of license type, and any independent corroboration of licensing terms.

   • [claimed-docs] “feat: add preserve scripts option for Postman import/export”
   • [claimed-docs] “add preserve scripts option for Postman import/export”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”

   proof ↗⚑ flag

   Hoppscotch✓fullcommunity8/10

   Hoppscotch's Community Edition source is publicly hosted on GitHub and documented as MIT-licensed, satisfying the 'read source under open license' story with an active, browsable repo (hoppscotch-docs-11, hoppscotch-gh-1..11). Missing for 10: no explicit clarification of licensing for the separate enterprise/self-host admin features, and community commentary notes it is 'open core' with some contributed functionality restricted (hoppscotch-comm-7, hoppscotch-comm-8), which is a scope caveat rather than a contradiction of the core MIT-licensed repo.

   • [claimed-docs] “Hoppscotch Community Edition is free and open-source. It is licensed under the MIT License.”
   • [github] “Import cURL”
   • [community] “I believe both Bruno and Hoppscotch are 'open core' with expensive paid plans for additional/enterprise functionality, and they limit commun…”
   • [community] “Going to leave this here for shady practices. A pull request was declined by the CEO since they were planning to build an OIDC feature into …”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Bruno✓fullcommunity8/10

   Bruno is explicitly offline-first with no cloud sync, no account/login, and collections stored as plain text files on the local filesystem, and the CLI even ships as an official Docker image for local/CI use — meaning the entire core product runs under user control with no vendor-hosted dependency (bruno-docs-8, bruno-docs-9, bruno-docs-48, bruno-docs-18). Community reports corroborate the offline-first, git-based self-managed workflow. missing for 10: no explicit multi-user self-hosted 'server/sync' deployment guide since the product is architected as a local-only client rather than a hosted service, so there's nothing analogous to a self-hosted backend to document beyond what's given.

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Available for Windows, macOS and Linux.”
   • [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
   • [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”

   proof ↗⚑ flag

   Hoppscotch✓fullcommunity8/10

   Hoppscotch documents a full self-host path (open-source MIT Community Edition, dedicated self-host getting-started guide, admin dashboard for server config, full data ownership) confirming the core product can run on a user's own infrastructure. Some older community comments note friction in the self-host setup process, but they don't contradict the current documented capability. Missing for 10: independent hands-on verification of a smooth current self-host deployment and more detail on infra requirements/scaling.

   • [claimed-docs] “Hoppscotch Community Edition is free and open-source. It is licensed under the MIT License.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”
   • [claimed-docs] “Self-host Hoppscotch on your own infrastructure with full data ownership.”
   • [claimed-docs] “For full data ownership and control over your API development and testing, you can self-host Hoppscotch on your infrastructure.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more. Hoppscotch Enterprise Edition is a self-hosted version of Hoppscotch Cloud with en…”
   • [claimed-docs] “You can manage your server configurations directly from the self-host admin dashboard.”
   • [community] “Am I going crazy or is there no way to install this locally apart from a 'development' setup with git clone or docker?”
   • [community] “I only wish they can provide a self-hosting step.”

   proof ↗⚑ flag

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

   weight 2 · round to Hoppscotch
   Bruno~partialclaimed5/10

   Bruno's local-first architecture ("No cloud sync... stores your collections directly in a folder on your filesystem", "offline-only... no plans to add cloud-sync, ever") means data effectively stays wherever the user's machine/filesystem is located, giving implicit control over data location rather than an explicit region/residency selector. There is no documented feature letting users choose a specific cloud region or residency zone since no cloud storage exists at all. Missing for 10: explicit region-selection UI/settings, enterprise data-residency controls, or documentation addressing multi-region compliance for any hosted/team features.

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed6/10

   Hoppscotch supports self-hosting on your own infrastructure with 'full data ownership' and on-prem deployment (Enterprise), which indirectly lets users control where their data resides by choosing their own hosting location, rather than offering explicit region-selection within a managed cloud service. missing for 10: an explicit region/residency selector in the hosted Hoppscotch Cloud offering, and independent confirmation of data-location controls.

   • [claimed-docs] “Self-host Hoppscotch on your own infrastructure with full data ownership.”
   • [claimed-docs] “For full data ownership and control over your API development and testing, you can self-host Hoppscotch on your infrastructure.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more. Hoppscotch Enterprise Edition is a self-hosted version of Hoppscotch Cloud with en…”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”

   proof ↗⚑ flag

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

   weight 3 · round to Bruno
   Bruno✓fullcommunity9/10

   Bruno explicitly states it does not train AI models on user data, has no cloud sync/account, and its AI features use a Bring-Your-Own-Key model where no data is routed through Bruno servers, giving clear first-party assurance against AI training use. missing for 10: independent/hands-on confirmation specifically verifying the no-AI-training claim (community evidence corroborates offline/git-first posture but not this specific claim).

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   No evidence in the pack addresses AI-training data usage, opt-out settings, or a privacy policy statement about model training; self-hosting for data ownership is documented but does not speak to whether cloud/AI features use data for training.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Bruno
   Bruno~partialclaimed6/10

   Bruno's offline-first, no-cloud, no-account architecture (local filesystem storage, no telemetry on requests, no AI training on data, BYOK for AI features) inherently gives users full control over data retention since nothing is stored or synced by Bruno servers by default. However, there's no explicit deletion/retention control feature or policy documentation for cases like secret managers, sync features, or team/cloud add-ons. missing for 10: explicit data retention/deletion controls or settings, documentation on how synced/team-tier data (if any) is retained or purged, independent verification of the 'zero visibility' claim.

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed4/10

   Hoppscotch offers self-hosting with 'full data ownership' and is open-source (MIT), which lets an organization control where data lives and effectively manage retention/deletion by owning the infrastructure. However, there is no explicit documentation of account/data deletion tools, configurable retention periods, or export/erasure APIs for the cloud-hosted version. Missing for 10: explicit data retention/deletion controls or APIs, documented GDPR-style erasure workflow, and independent confirmation that self-hosting alone satisfies deletion requirements.

   • [claimed-docs] “Self-host Hoppscotch on your own infrastructure with full data ownership.”
   • [claimed-docs] “Hoppscotch Community Edition is free and open-source. It is licensed under the MIT License.”
   • [claimed-docs] “SAML-based SSO, on-prem deployment, audit logs, and more.”

   proof ↗⚑ flag

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

   weight 2 · round to Bruno
   Bruno~partialclaimed6/10

   Bruno's marketing emphasizes an offline-first, no-account, no-cloud-sync design with 'zero visibility into your requests' and no AI training on user data, implying no telemetry on API usage by design (bruno-docs-8, bruno-docs-48, bruno-docs-9). However, there is no explicit documentation of a telemetry/analytics toggle or opt-out setting for app-level usage tracking (e.g., crash reporting, feature analytics), so the claim is inferred from architecture rather than an explicit privacy control. missing for 10: explicit telemetry/analytics opt-out setting or documentation, independent verification of no background usage tracking.

   • [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
   • [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   No evidence pack item addresses telemetry, analytics, or opt-out settings for Hoppscotch; self-hosting is mentioned as giving 'full data ownership' but that is distinct from an explicit telemetry opt-out control.

   ⚑ flag

Docs generation

1. developerGenerate and publish API documentation from my collections or specs

   weight 2 · round to Bruno
   Bruno~partialclaimed6/10

   Bruno docs explicitly state you can 'Write docs with your collections; publish as shareable HTML' plus a rich text docs editor, directly matching the story of generating/publishing API documentation from collections. However this is a single doc-feature mention with no independent/community corroboration, no detail on hosting/sharing workflow, and no support for generating docs from external specs (e.g. OpenAPI import/export to docs). missing for 10: independent verification of the publish-as-HTML feature, detail on doc customization/publishing workflow, and spec-based (OpenAPI) doc generation.

   • [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
   • [claimed-docs] “feat(docs): Rich text docs editor”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Hoppscotch offers OpenAPI import and an 'Embed' feature to share interactive requests, but there is no evidence of an actual documentation-generation/publishing feature from collections or specs; a community review explicitly notes 'Can't create documentation for a folder/request', directly indicating this capability is absent.

   • [claimed-docs] “Embed: Create a mini-version of Hoppscotch that you can embed in an HTML page, allowing your audience to interact with your API request.”
   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”
   • [community] “It has a clean UI and can be self-hosted. The downside is - Only one workspace is available when offline. You can't point your Workspace dat…”

   proof ↗⚑ flag

Spec import export

1. developerDesign an API spec-first and export it as OpenAPI

   weight 2 · round drawn
   Bruno—none0/10

   Evidence pack shows Bruno's collections are stored as plain-text .bru files, supports Postman import/export, CLI runs, and Git integration—but nothing about spec-first design workflows or generating/exporting OpenAPI specifications. The probe explicitly found no OpenAPI schema/documentation endpoints exposed.

   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
   • [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
   • [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Evidence shows Hoppscotch can import OpenAPI specs (e.g., using tags as folders when importing) but there is no mention of designing an API spec-first and exporting it as OpenAPI; the only OpenAPI-related capability documented is import, not export.

   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”

   proof ↗⚑ flag

2. developerImport an OpenAPI spec to generate requests and collections

   weight 3 · round to Hoppscotch
   Bruno—none0/10

   The evidence pack documents Postman collection import (bruno-docs-24, bruno-docs-25, bruno-docs-7) but contains no mention of importing OpenAPI/Swagger specs to generate requests or collections. This is a fair axis for an API client tool, but no supporting evidence exists in the pack.

   ⚑ flag

   Hoppscotch~partialclaimed6/10

   Docs explicitly mention OpenAPI import ('Use tags as folders when importing from OpenAPI') implying native OpenAPI import into collections, alongside cURL import and collection/folder organization features. However, there's no detailed documentation on the full import workflow (e.g., generating requests from spec, handling auth/schemas) or independent/hands-on confirmation of fidelity. missing for 10: detailed OpenAPI import workflow docs, independent/hands-on validation of spec-to-collection accuracy.

   • [claimed-docs] “Use tags as folders when importing from OpenAPI.”
   • [github] “Keep your API requests organized with collections and folders. Reuse them with a single click.”
   • [github] “Import cURL”

   proof ↗⚑ flag

Ai assist

1. ai-native userHave AI generate test cases or assertions for an endpoint from its spec or responses

   weight 2 · round to Bruno
   Bruno~partialclaimed7/10

   Bruno AI can generate test/assertion scripts via the AI icon in a request's Scripts tab (bruno-docs-38) and can auto-generate whole collections—including tests—from backend source code (bruno-docs-41), which covers 'from spec' generation. However, there's no explicit documentation of generating assertions directly from example responses, and no independent/hands-on confirmation of this AI feature's real-world reliability. Missing for 10: evidence of generating tests specifically from response bodies/OpenAPI specs, and independent verification of output quality.

   • [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
   • [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
   • [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
   • [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Docs mention AI features that include "scripting capabilities for pre-request logic and test cases," implying AI can help generate test/assertion scripts, but there's no detail on generating tests specifically from an endpoint's spec or response data, nor independent corroboration of this feature in use. Missing for 10: detailed documentation on spec/response-driven test generation, examples of AI-generated assertions, and community/hands-on validation of this specific capability.

   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”

   proof ↗⚑ flag

Contract testing

1. platform-engineerValidate live responses against the API contract to catch drift

   weight 2 · round to Bruno
   Bruno~partialclaimed4/10

   Bruno documents general test assertions, data-driven test suites, and CI/CD integration for automated runs (bruno-docs-32, bruno-docs-3, bruno-docs-30), which teams could use to assert response shape/status manually, but there is no evidence of a dedicated schema/contract validation feature (e.g., importing/validating against an OpenAPI spec) to explicitly catch API drift. Missing for 10: explicit OpenAPI/contract schema validation capability, documented drift-detection workflow, and any first-party or community evidence of contract testing use.

   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [claimed-docs] “create reports in multiple formats, including JSON, JUnit, and HTML”

   proof ↗⚑ flag

   Hoppscotch—none0/10

   Evidence shows Hoppscotch supports API testing scripts, CLI test runs with JUnit reports, and OpenAPI import for building requests/collections, but nothing describes validating live responses against an API contract (e.g., OpenAPI schema) to detect drift.

   ⚑ flag

Testing

1. developerRun an entire collection as an automated test suite with a pass/fail report

   weight 3 · round to Bruno
   Bruno✓fullprobed9/10

   Bruno CLI documented to run entire collections from command line, generate pass/fail-style test reports in JSON/JUnit/HTML formats, and integrate into CI/CD pipelines (Docker, GitHub Actions), plus native assertions/test suites with data-driven testing support. Missing for 10: independent hands-on report specifically confirming CLI test-run reporting in practice (community evidence focuses on desktop app, not CLI runs).

   • [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
   • [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
   • [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
   • [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”

   proof ↗⚑ flag

   Hoppscotch✓fullprobed8/10

   Hoppscotch's official CLI (hopp test) runs entire collections from the terminal and generates JUnit reports for collection runs, which is a standard pass/fail CI test report format; docs also describe running API tests and automated monitoring via CLI. Missing for 10: no independent/hands-on community corroboration of the CLI test-runner experience or assertion/scripting depth was found in the pack.

   • [claimed-docs] “Use the Hoppscotch CLI to run API tests, automate monitoring, and manage collections from your terminal.”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [probe] “official CLI documented at https://docs.hoppscotch.io/documentation/clients/cli/overview”

   proof ↗⚑ flag

2. developerWrite test assertions against response status, body, and headers

   weight 3 · round to Bruno
   Bruno✓fullclaimed7/10

   Bruno's official docs state you can 'Write assertions and test suites, and automate runs with data-driven testing' and generate JSON/JUnit/HTML test reports, confirming built-in test/assertion functionality against API responses. However, the evidence never explicitly breaks down assertions by status code, body, and headers separately. missing for 10: explicit doc examples of status-code/body/header assertion syntax, independent hands-on confirmation of assertion granularity.

   • [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
   • [claimed-docs] “create reports in multiple formats, including JSON, JUnit, and HTML”
   • [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”

   proof ↗⚑ flag

   Hoppscotch~partialclaimed5/10

   Hoppscotch docs reference scripting capabilities for 'pre-request logic and test cases' and a CLI 'hopp test' command that can generate JUnit reports for collection runs, implying support for test assertions, but no evidence details how assertions target response status, body, or headers specifically. missing for 10: explicit documentation/examples of assertion syntax (pw.expect-style) for status/body/headers, independent hands-on confirmation of test script execution.

   • [claimed-docs] “These include renaming of API requests, generation of structured request payloads, and scripting capabilities for pre-request logic and test…”
   • [claimed-docs] “The hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI.”
   • [claimed-docs] “With the command-line interface (CLI) you can interact with the Hoppscotch platform using a terminal, or through an automated system. This e…”
   • [github] “Snippets of code associated with a request that is executed before the request is sent.”

   proof ↗⚑ flag