Bruno vs Insomnia

Agent access

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

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

   Insomnia~partialprobed6/10

   Kong's developer docs (which host Insomnia's documentation) expose a working llms.txt at the domain root and individual doc pages are directly fetchable as markdown (.md) files, which is agent-friendly, but this is a shared Kong-wide resource rather than an Insomnia-specific llms.txt, and a probe for an Insomnia-specific markdown index (insomnia/.md) returned 404. Missing for 10: a dedicated Insomnia-specific llms.txt or explicit agent-onboarding docs, and confirmation Insomnia itself (the product) references or promotes this file to agents.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.konghq.com/llms.txt # developer.konghq.com > Kong's developer documentation for Kong Gateway,…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.konghq.com/insomnia/.md”
   • [claimed-docs] “Insomnia provides the ability to chain requests. This means you can extract values from the responses of other requests while also sharing s…”
   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent.”

   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

   Insomnia✓fullprobed8/10

   Insomnia ships the Inso CLI, explicitly documented as designed for CI environments — it disables interactive prompts and returns exit codes to pass/fail builds, and supports test running, spec linting, and collection runs from CI/Git workflows without the GUI. This directly satisfies headless/automated execution for CI pipelines. Missing for 10: independent hands-on CI usage reports/case studies and more detail on advanced automation scenarios (e.g., parallelization, complex environment injection) beyond the docs themselves.

   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

   proof ↗⚑ flag

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

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

   Insomnia✓fullclaimed8/10

   Insomnia has a documented MCP Client feature that connects to external MCP servers to access AI-ready tools, prompts, and resources, discovering and enabling invocation/testing of these elements directly in the app. This directly matches the story of plugging in MCP servers to use their tools. Missing for 10: independent/hands-on corroboration of the MCP client feature beyond first-party docs, and details on limitations or setup friction.

   • [claimed-docs] “Use Insomnia to connect external Model Context Protocol (MCP) Servers to access AI-ready tools, prompts, and resources.”
   • [claimed-docs] “The Insomnia MCP Client discovers these elements, which enables you to invoke, query, or test them directly in the app.”
   • [claimed-docs] “Use MCP clients to connect Insomnia to Konnect for mocking, validating, and protecting requests in real time.”

   proof ↗⚑ flag

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

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

   Insomnia—none0/10

   Evidence shows Insomnia acts as an MCP *client* (docs-14, docs-30, docs-46) that connects to external MCP servers, not as an MCP server that an agent could connect to. No documentation of Insomnia exposing its own official MCP server endpoint was found in the evidence pack.

   • [claimed-docs] “Use MCP clients to connect Insomnia to Konnect for mocking, validating, and protecting requests in real time.”
   • [claimed-docs] “The Insomnia MCP Client discovers these elements, which enables you to invoke, query, or test them directly in the app.”
   • [claimed-docs] “Use Insomnia to connect external Model Context Protocol (MCP) Servers to access AI-ready tools, prompts, and resources.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Insomnia✓fullprobed8/10

   Insomnia ships an official 'Inso CLI' documented for automating collection runs, linting OpenAPI specs, and running in CI pipelines with exit codes for pass/fail, which is exactly the kind of scriptable, agent-friendly interface an AI-native workflow would use. missing for 10: independent/hands-on community confirmation of Inso CLI usage and explicit framing of the CLI as AI/agent-oriented rather than just human CI tooling.

   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

   proof ↗⚑ flag

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

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

   Insomnia~partialprobed4/10

   Insomnia does not publish a documented public REST/programmatic API for driving the app itself (probe found no OpenAPI/swagger spec for the product), but it does offer the Inso CLI for scripted automation of tests, linting, and collection runs, plus an extensibility plugin system — giving AI-native users some programmatic control, just not a true public API surface. missing for 10: a documented HTTP/SDK-style public API for controlling Insomnia, independent confirmation the Inso CLI/plugin surface is used for AI-agent automation.

   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “Unlimited access to plugins or build your own”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

   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

   Insomnia—none0/10

   Insomnia offers RBAC for controlling access to its own resources, external vault integration for retrieving secrets, and environment variables for storing credentials, but there is no evidence of a feature to generate or issue scoped, least-privilege API credentials specifically for an AI agent to use. Given Insomnia's MCP client and AI features, this would be a plausible extension, but it's not documented anywhere in the evidence pack.

   • [claimed-docs] “Use Role-based access control (RBAC) for fine-grain control over who can access which Insomnia resources.”
   • [claimed-docs] “Insomnia supports integrating with external vault service providers to retrieve secret values automatically when sending requests.”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests. For example, you could create variables for base …”
   • [claimed-docs] “Use Insomnia to connect external Model Context Protocol (MCP) Servers to access AI-ready tools, prompts, and resources.”

   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

   Insomnia—none0/10

   Evidence shows Insomnia's automation surface is the Inso CLI and plugin system, plus MCP client support, but no official SDK (e.g., a Node/Python/Go SDK) for programmatically building against Insomnia is documented anywhere in the pack.

   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “Unlimited access to plugins or build your own”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

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

   Insomnia~partialclaimed4/10

   Insomnia has narrow, specific AI features—generating mock servers from prompts/OpenAPI/URL and suggesting Git commit messages—but no evidence of AI analyzing request/response data to surface insights, debugging suggestions, or pattern recognition across a user's API data. Missing for 10: AI-driven analysis of actual request/response payloads, error/anomaly insights, or usage-pattern suggestions beyond mock generation and commit messages.

   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”
   • [claimed-docs] “AI commit message suggestions, which help maintain clear and atomic commit histories.”
   • [claimed-docs] “AI commit message suggestions, which help”

   proof ↗⚑ flag

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

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

   Insomnia—none0/10

   Insomnia offers CI-triggered test automation via Inso CLI and manual Collection Runner runs, but there is no evidence of autonomous, self-scheduling background automations (e.g., cron-like triggers or agents running unattended) — all automation examples require an external CI pipeline or manual invocation.

   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”

   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

   Insomnia~partialclaimed4/10

   Insomnia does ship some built-in AI features—generating mock servers from a natural-language prompt/OpenAPI spec (insomnia-docs-10, insomnia-docs-29, insomnia-docs-51) and AI-generated commit message suggestions (insomnia-docs-35, insomnia-docs-52)—but these are narrow, single-purpose AI helpers rather than a general-purpose assistant to which a user can delegate broader tasks (e.g., writing tests, debugging requests, multi-step workflows). Missing for 10: evidence of a general conversational/agentic AI assistant embedded in the app, ability to delegate arbitrary tasks beyond mock/commit generation, and independent/hands-on confirmation of these AI features' quality.

   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”
   • [claimed-docs] “AI commit message suggestions, which help maintain clear and atomic commit histories.”
   • [claimed-docs] “AI commit message suggestions, which help”

   proof ↗⚑ flag

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

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

   Insomnia~partialclaimed4/10

   Insomnia offers targeted AI/natural-language features—generating a mock server from a natural-language prompt and AI-assisted commit message suggestions—but there is no evidence of broader natural-language command control over core operations like creating/running requests, collections, or environments. Missing for 10: NL-driven request creation/execution, NL-based test/collection running, general chat-style control of the app, and independent verification of the AI features' reliability.

   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “AI commit message suggestions, which help maintain clear and atomic commit histories.”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”
   • [claimed-docs] “AI commit message suggestions, which help”

   proof ↗⚑ flag

Api quality

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

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

   Insomnia~partialclaimed5/10

   Insomnia lets users import OpenAPI/Swagger specs, preview them with linting, auto-generate code snippets in 12+ languages, and directly send/run requests against the spec — effectively turning any imported API spec into an interactive, runnable reference (insomnia-docs-16, insomnia-docs-17, insomnia-docs-18, insomnia-docs-5, insomnia-docs-48). However this requires manually importing a spec rather than offering a built-in, browsable reference experience, and there's no evidence of a dedicated 'try-it-out' documentation portal or AI-native example runner. Missing for 10: a first-party interactive documentation/reference viewer (vs. spec design+testing workflow), and independent/hands-on evidence of this specific 'explore reference with runnable examples' flow.

   • [claimed-docs] “View a generated preview of your spec in the right pane.”
   • [claimed-docs] “Automatically linted. Errors display at the bottom of the center pane and include error type, line number, and error message”
   • [claimed-docs] “Generate code snippets automatically in over 12 different programming languages.”
   • [claimed-docs] “Build and iterate on your OpenAPI specs to design your next API.”
   • [claimed-docs] “Import a Postman collection or OpenAPI spec into Insomnia Method: UI → Import → choose File/Clipboard/URL.”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”

   proof ↗⚑ flag

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

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

   Insomnia✓fullclaimed8/10

   Insomnia's Design Hub lets users build/iterate OpenAPI specs, preview and lint them, and export/import in OpenAPI 3.0/3.1 (plus Swagger, Postman, HAR formats), and the Inso CLI can lint specs in CI (`inso lint spec`). This directly delivers a machine-readable, downloadable spec workflow. Missing for 10: no independent/hands-on confirmation of the export UX or format fidelity, and the Kong docs site itself has no discoverable OpenAPI spec (probe-3), slightly muddying 'AI-native' machine-readability of the docs layer.

   • [claimed-docs] “Build and iterate on your OpenAPI specs to design your next API.”
   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “View a generated preview of your spec in the right pane.”
   • [claimed-docs] “Automatically linted. Errors display at the bottom of the center pane and include error type, line number, and error message”
   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import a Postman collection or OpenAPI spec into Insomnia Method: UI → Import → choose File/Clipboard/URL.”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”

   proof ↗⚑ flag

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

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

   Insomnia~partialclaimed6/10

   Insomnia supports mock servers (including AI-generated ones from a prompt/OpenAPI spec) and environment variables that can separate dev/staging/production configs, letting users test flows without hitting real production endpoints. However, there is no explicit 'sandbox environment' feature or documented guarantee of production-data isolation — it relies on users manually configuring mock servers/environments rather than a dedicated sandboxed testing mode. Missing for 10: an explicit sandbox/staging isolation feature, documentation guaranteeing no production data exposure, and independent evidence of AI agents using this for safe testing.

   • [claimed-docs] “The Insomnia Cloud mock servers allow you to create a mock endpoint in a few steps.”
   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Dynamic mocking renders Liquid templates so responses can include: - Data from the request (headers, query parameters, path, or body). - Ran…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests.”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests. For example, you could create variables for base …”
   • [claimed-docs] “Global environments, which can be accessed by all collections in a project * Collection environments, which can be accessed by all requests …”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”

   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

   Insomnia—none0/10

   The evidence pack shows Insomnia has versioned file/import formats (e.g., Insomnia JSON v4/YAML v5, OpenAPI 3.0/3.1) but there is no documentation of a formal versioning scheme or deprecation policy for any Insomnia-exposed API, plugin API, or CLI interface that an AI agent would rely on for stability guarantees.

   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”

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

   Insomnia~partialclaimed6/10

   Insomnia's Collection Runner and unlimited collection runs let users execute many requests/tests in bulk, and the Inso CLI automates this across CI pipelines, giving solid bulk-execution support (insomnia-docs-4, insomnia-docs-20, insomnia-docs-39, insomnia-docs-53, insomnia-docs-55). However, evidence is limited to running/testing many requests together—there's no documented bulk editing, bulk tagging, or bulk deletion of items, and no independent/hands-on confirmation of this specific bulk workflow. Missing for 10: evidence of bulk editing/management of many items beyond execution, and independent corroboration of the Collection Runner/Inso CLI bulk workflow.

   • [claimed-docs] “Automatically test multiple requests in your collections, with unlimited collection runs.”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “Unlimited collection runs * Unlimited environments”
   • [claimed-docs] “Test complex workflows by chaining the responses from requests together”

   proof ↗⚑ flag

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

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

   Insomnia~partialclaimed5/10

   Insomnia supports pre-request and after-response scripts that automatically execute logic tied to request lifecycle events, plus chained requests and CI-triggered automation via the Inso CLI, which constitutes a form of automatic action-on-event behavior. However, there is no evidence of a general-purpose rule/trigger system for arbitrary events (e.g., webhooks, scheduled triggers, or cross-tool event listeners) beyond the request-send/response lifecycle. missing for 10: evidence of a broader event-trigger/rule engine beyond request scripting, and independent confirmation of automation reliability.

   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent.”
   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent. They can be used to: * Manipulate environment variables or authenti…”
   • [claimed-docs] “Pre-request and after-response scripting to add logic to your requests”
   • [claimed-docs] “Test complex workflows by chaining the responses from requests together”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”

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

   Insomnia—none0/10

   Insomnia offers Inso CLI for CI-triggered test runs and collection runners, but there is no evidence of any built-in scheduler or recurring-job feature (e.g., cron-like monitors) comparable to what competitors offer; scheduling would have to be bolted on via external CI cron jobs, which isn't documented as part of Insomnia itself.

   ⚑ flag

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

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

   Insomnia✓fullclaimed7/10

   Insomnia's Git Sync connects collections/environments directly to a Git repo, offers a merge view to review and resolve conflicts, and lets you convert projects between Local Vault, Cloud Sync, and Git Sync — giving version history and review workflows for automations (collections, scripts, environments). Rollback is implied via standard Git history rather than a dedicated in-app rollback UI. Missing for 10: explicit in-app rollback/versioned-restore feature beyond relying on external Git tooling, and independent hands-on confirmation of the merge/review workflow in practice.

   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Insomnia opens a merge view so you can review and resolve conflicts without leaving the app.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “You can convert a project to: Local Vault, Cloud Sync, Git Sync”
   • [github] “Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.”

   proof ↗⚑ flag

Ci

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

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

   Insomnia✓fullprobed8/10

   Insomnia's docs explicitly describe the Inso CLI as designed for CI environments with disabled prompts and pass/fail exit codes, plus commands like 'inso lint spec' to fail builds on errors, and general CLI automation of test collections tied to Git workflows. missing for 10: independent/hands-on confirmation of CI CLI reliability, real-world CI pipeline examples beyond vendor docs

   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

   proof ↗⚑ flag

Monitors

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

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

   Insomnia~partialclaimed4/10

   Insomnia's Inso CLI can run collection tests in CI with exit codes to pass/fail builds, and can lint OpenAPI specs to fail builds on errors, which developers could wire into a scheduled CI job to approximate a monitor. However, there is no evidence of a native scheduling feature or built-in alerting mechanism (email/Slack/webhook) for failed runs, unlike a dedicated Monitors product — the burden of scheduling and alerting falls on external CI tooling. missing for 10: native monitor scheduling UI, built-in alert/notification channel on failure, and any hands-on confirmation this workflow is used for uptime-style monitoring.

   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”
   • [claimed-docs] “Unlimited collection runs * Unlimited environments”

   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

   Insomnia!disputedcontradicted6/10

   Docs clearly document pre-request and after-response scripting, chaining responses across requests, environment variables, and CI automation via Inso CLI (insomnia-docs-2, -21, -37, -38, -39, -53), which directly matches the story. However, a hands-on community comment contradicts this, calling Insomnia's scripting/glue-code support 'garbage-tier' compared to Postman (insomnia-comm-15), indicating the scripting capability may be weaker or less mature in practice than the docs suggest. Missing for 10: independent verification of scripting robustness/parity with competitors, and more recent hands-on confirmation resolving the community critique.

   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent.”
   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent. They can be used to: * Manipulate environment variables or authenti…”
   • [claimed-docs] “Pre-request and after-response scripting to add logic to your requests”
   • [claimed-docs] “Test complex workflows by chaining the responses from requests together”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [community] “'Even insomnia had garbage-tier glue code support, something that was very much missing coming from Postman,' notes a user comparing scripti…”

   proof ↗⚑ flag

Access control

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

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

   Insomnia~partialclaimed6/10

   Insomnia documents RBAC for fine-grained control over Insomnia resources and organizations for secure collaboration/sharing, plus SAML 2.0 SSO for identity, directly matching the platform-engineer's need to control who can view/edit APIs and collections. However, there's no detail on granularity (e.g., per-collection vs per-project roles), no independent/hands-on validation of RBAC in practice, and it's gated behind paid tiers per pricing page rather than shown in a workflow. Missing for 10: detailed documentation on role granularity/permission scopes for collections specifically, independent or community validation that RBAC works as described, and any hands-on walkthrough of setting collection-level permissions.

   • [claimed-docs] “Use Role-based access control (RBAC) for fine-grain control over who can access which Insomnia resources.”
   • [claimed-docs] “Role-based access control (RBAC)”
   • [claimed-docs] “Insomnia organizations allows users to share collections and environments safely and securely with their colleagues.”
   • [claimed-docs] “You can use any identity provider (IdP) that supports SAML 2.0.”

   proof ↗⚑ flag

Api catalog

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

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

   Insomnia—none0/10

   Insomnia's evidence covers request collaboration, organizations, Git sync, and RBAC for sharing collections among teammates inside the app, but nothing describes a published catalog or developer portal for broader API discovery/consumption by other teams. missing for 10: any mention of a public/internal API catalog, developer portal, or discovery UI outside the Insomnia app itself.

   • [claimed-docs] “Insomnia organizations allows users to share collections and environments safely and securely with their colleagues.”
   • [claimed-docs] “Use Role-based access control (RBAC) for fine-grain control over who can access which Insomnia resources.”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”

   proof ↗⚑ flag

Team workspaces

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

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

   Insomnia✓fullclaimed8/10

   Insomnia organizations support sharing collections/environments securely with colleagues, with RBAC, Cloud Sync, and Git Sync as alternate sync backends, plus merge conflict resolution for team workflows. missing for 10: independent/hands-on evidence of team sync experience (community comments focus on rug-pull login requirement and lightweight vs bloat, not team sync workflow specifics), and no detail on real-time collaboration limits or seat/team size constraints.

   • [claimed-docs] “Insomnia organizations allows users to share collections and environments safely and securely with their colleagues.”
   • [claimed-docs] “Use Role-based access control (RBAC) for fine-grain control over who can access which Insomnia resources.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Insomnia opens a merge view so you can review and resolve conflicts without leaving the app.”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”
   • [claimed-docs] “At no point in the sync process can the Insomnia servers read or access sensitive application project data.”

   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

   Insomnia✓fullclaimed8/10

   Insomnia's Git Sync feature explicitly stores project/collection data directly in a user's own Git repository as files (not on Insomnia's servers), supports merge conflict resolution, and can be toggled per-project alongside Cloud/Local storage — directly matching the story. Documentation also confirms this is a longstanding, git-native workflow (git version control mentioned for collaborative API design) and the GitHub README corroborates 'Git Sync: for Git storage using any 3rd party Git repository.' Missing for 10: independent hands-on confirmation of the exact plain-text file format on disk and no community verification of git-diff friendliness.

   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Insomnia opens a merge view so you can review and resolve conflicts without leaving the app.”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [claimed-docs] “You can convert a project to: Local Vault, Cloud Sync, Git Sync”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”
   • [github] “Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.”

   proof ↗⚑ flag

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

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

   Insomnia✓fullclaimed9/10

   Docs explicitly detail import/export in multiple portable formats (Insomnia JSON/YAML, Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, cURL) with UI import methods and Inso CLI support for automation/CI, plus Git Sync for version-controlled portability across tools. Missing for 10: no independent hands-on verification of round-trip fidelity between tools beyond vendor docs.

   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import a Postman collection or OpenAPI spec into Insomnia Method: UI → Import → choose File/Clipboard/URL.”
   • [claimed-docs] “Import your tests from Postman”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”

   proof ↗⚑ flag

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

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

   Insomnia✓fullcommunity9/10

   Insomnia's docs clearly show organizing requests into collections/folders, with Collection Runner to rerun multiple requests in order, unlimited collection runs, environments scoped to collections/folders, and persistent storage via Git Sync/Cloud Sync for rerunning anytime. Community evidence corroborates long-term real-world use of saved/frequently-used requests. Missing for 10: independent hands-on verification specifically of folder-nesting UX and rerun reliability at scale beyond vendor docs.

   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”
   • [claimed-docs] “Automatically test multiple requests in your collections, with unlimited collection runs.”
   • [claimed-docs] “Unlimited collection runs * Unlimited environments”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests.”
   • [claimed-docs] “Global environments, which can be accessed by all collections in a project * Collection environments, which can be accessed by all requests …”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [community] “I've been using [cocoa-rest-client] for a couple of years, I just tried Insomnia and I think I'll be switching: having the ability to call f…”

   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

   Insomnia!disputedcontradicted5/10

   Insomnia's docs describe offline-friendly options — Scratch Pad requires 'No login ever required' (insomnia-docs-31), a 'Local Vault' project-storage mode (insomnia-docs-32/45), and Git Sync that keeps data in the user's own repo without touching Insomnia's cloud (insomnia-gh-1, insomnia-docs-22/44). However, a first-hand community report states the main Insomnia REST client 'now requires an account,' prompting users to call it a 'rug pull' and switch to fully offline-first alternatives like Bruno (insomnia-comm-14), directly contradicting the no-account claim for general (non-Scratch-Pad) usage. missing for 10: clear vendor confirmation that the main workspace (not just Scratch Pad) can be used indefinitely without ever creating a cloud account, and independent hands-on verification resolving the community complaint.

   • [claimed-docs] “No login ever required for Scratch Pad”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “You can convert a project to: Local Vault, Cloud Sync, Git Sync”
   • [github] “Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [community] “Insomnia REST client now requires an account, prompting users to seek alternatives; one commenter says 'Tired of these rug pulls' and lists …”

   proof ↗⚑ flag

Protocols

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

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

   Insomnia✓fullclaimed8/10

   Docs explicitly confirm HTTP, gRPC, GraphQL, and WebSocket request support (insomnia-docs-15, insomnia-docs-7/43, insomnia-docs-26), with GraphQL type-aware autocomplete and gRPC protobuf upload support. SSE is not explicitly named in the docs, though WebSocket/streaming support is documented. missing for 10: explicit SSE (Server-Sent Events) documentation, independent hands-on corroboration of multi-protocol usage.

   • [claimed-docs] “With Insomnia, you can send requests via HTTP, gRPC, GraphQL, and WebSockets.”
   • [claimed-docs] “Insomnia supports making gRPC requests.”
   • [claimed-docs] “Insomnia supports making gRPC requests. You can create one by clicking the + button on the left panel of a collection and selecting gRPC Req…”
   • [claimed-docs] “Insomnia uses this type system to provide auto-completion and linting of GraphQL queries.”
   • [claimed-docs] “Insomnia allows you to upload Protobuf files to a request. You can upload a single file or a directory containing multiple files.”
   • [github] “Debug APIs using the most popular protocols and formats.”

   proof ↗⚑ flag

Environments

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

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

   Insomnia✓fullclaimed9/10

   Insomnia explicitly supports environments as groups of variables (base URLs, tokens, credentials) with global, collection, and folder-level scoping, enabling switching between dev/staging/prod configurations; unlimited environments are confirmed in pricing docs. Missing for 10: no explicit hands-on/community example of a dev/staging/prod switching workflow, only first-party docs.

   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests.”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests. For example, you could create variables for base …”
   • [claimed-docs] “Global environments, which can be accessed by all collections in a project * Collection environments, which can be accessed by all requests …”
   • [claimed-docs] “Unlimited collection runs * Unlimited environments”

   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

   Insomnia✓fullclaimed7/10

   Insomnia explicitly documents external vault integration to retrieve secret values automatically when sending requests, and environments are described as a way to store credentials/tokens without hardcoding them in shared collection files. RBAC and organization-level sharing controls further support keeping secrets scoped safely. Missing for 10: explicit documentation of a 'masked' or obfuscated secret display feature in the UI, and independent/hands-on confirmation that vault integration works reliably in practice.

   • [claimed-docs] “Insomnia supports integrating with external vault service providers to retrieve secret values automatically when sending requests.”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests. For example, you could create variables for base …”
   • [claimed-docs] “Use environments to define groups of variables that Insomnia applies across your requests.”
   • [claimed-docs] “Use Role-based access control (RBAC) for fine-grain control over who can access which Insomnia resources.”

   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

   Insomnia~partialprobed5/10

   Insomnia ships an official CLI (Inso CLI) that can run collections, lint OpenAPI specs, and automate tests in CI (insomnia-docs-3, -39, -49, -53, insomnia-probe-4), giving CLI/automation parity for a meaningful subset of workflows. However, there's no evidence of a full programmatic/API surface covering all UI capabilities (e.g., AI-assisted mock server creation, GraphQL design/linting, gRPC/Protobuf uploads, environment/Git-sync management, RBAC) — these remain UI-only per the docs. A community comment even flags weak scripting/glue-code support relative to competitors (insomnia-comm-15). missing for 10: CLI/API coverage for mock servers, GraphQL/gRPC workflows, environment & Git sync management, and independent confirmation that Inso CLI matches full UI functionality.

   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”
   • [community] “'Even insomnia had garbage-tier glue code support, something that was very much missing coming from Postman,' notes a user comparing scripti…”

   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

   Insomnia~partialclaimed7/10

   Insomnia supports export in multiple open formats (Postman v2, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, cURL, plus its own JSON/YAML) and Git Sync keeps project data in a user-controlled repository rather than locked in a proprietary cloud, giving strong data portability. However, there's no explicit 'export everything' bulk/full-account export guarantee (e.g., all environments, secrets, RBAC configs, org settings) and no independent verification that exported data is fully lossless/complete outside vendor docs. missing for 10: evidence of a comprehensive full-account/workspace export (not just collections), independent/hands-on confirmation of lossless round-trip export, and documentation on exporting non-collection data like vault secrets or org settings.

   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [github] “Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “You can convert a project to: Local Vault, Cloud Sync, Git Sync”

   proof ↗⚑ flag

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

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

   Insomnia✓fullclaimed8/10

   The official GitHub repository explicitly ships an Apache-2.0 LICENSE file, confirming Insomnia's source code is available under a recognized open-source license for anyone (including AI-native users) to read. Missing for 10: independent scrutiny of whether all components (e.g., cloud sync backend) are covered by the same license, and no third-party audit confirming license accuracy beyond the repo itself.

   • [github] “Apache License Version 2.0, January 2004 — repository LICENSE file; the README's License section states: [Apache-2.0](LICENSE) (c) Insomnia …”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   Insomnia~partialclaimed5/10

   Insomnia's core client is Apache-2.0 licensed and open source, and Git Sync explicitly keeps all project data in the user's own Git repo with 'Insomnia does not host or manage it,' letting AI-native users avoid the vendor's cloud entirely. However, there is no documented self-hosted server/backend package (e.g., a self-hosted sync or collaboration server) analogous to on-prem deployments some competitors offer—self-hosting here is effectively 'run the open-source desktop client + your own git remote,' not a full self-hosted service stack. Missing for 10: an official self-hosted server/Docker deployment guide, and independent confirmation that self-built/self-hosted setups work end-to-end.

   • [github] “Apache License Version 2.0, January 2004 — repository LICENSE file; the README's License section states: [Apache-2.0](LICENSE) (c) Insomnia …”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [claimed-docs] “At no point in the sync process can the Insomnia servers read or access sensitive application project data.”
   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”

   proof ↗⚑ flag

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

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

   Insomnia~partialclaimed4/10

   Insomnia lets users choose storage mode—Local Vault, Cloud Sync, or Git Sync to a self-hosted/3rd-party repo—giving some control over where data physically resides, and Kong states its cloud servers cannot read synced project data. However there is no evidence of selectable geographic region/data-residency options within Insomnia's cloud offering itself. Missing for 10: explicit region selection for cloud-hosted data, documented data-residency/compliance zones, independent confirmation of storage location guarantees.

   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “At no point in the sync process can the Insomnia servers read or access sensitive application project data.”

   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

   Insomnia—none0/10

   Insomnia's docs describe AI features (mock generation, commit suggestions) and data-security claims about sync servers not reading project data, but there is no evidence of any control or policy letting users opt out of their data being used for AI model training.

   • [claimed-docs] “At no point in the sync process can the Insomnia servers read or access sensitive application project data.”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”
   • [claimed-docs] “AI commit message suggestions, which help”

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

   Insomnia~partialclaimed5/10

   Insomnia lets users choose where data lives (Local Vault, Git Sync, Cloud Sync) and states its servers cannot read synced project data, plus a no-login Scratch Pad mode, which gives meaningful control over data storage/retention posture. However there is no explicit documentation of account/data deletion mechanisms, retention periods, or GDPR-style data export/erasure workflows. Missing for 10: explicit data deletion/retention policy documentation, account/data purge controls, independent confirmation of these claims.

   • [claimed-docs] “You can convert a project to: - Local Vault - Cloud Sync - Git Sync”
   • [claimed-docs] “You can convert a project to: Local Vault, Cloud Sync, Git Sync”
   • [claimed-docs] “At no point in the sync process can the Insomnia servers read or access sensitive application project data.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository.”
   • [claimed-docs] “Git Sync connects Insomnia directly to your Git repository. Your project data stays in your repository. Insomnia does not host or manage it.”
   • [claimed-docs] “No login ever required for Scratch Pad”

   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

   Insomnia—none0/10

   No evidence pack item discusses telemetry, analytics, or usage-tracking settings, nor any opt-out mechanism, despite this being a reasonable capability for a desktop app to document.

   ⚑ 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

   Insomnia~partialclaimed4/10

   Insomnia's design mode lets you build/iterate on OpenAPI specs, view a generated preview, get linting and auto-generated code snippets in 12+ languages, which serves as a form of documentation generation from specs (insomnia-docs-5, insomnia-docs-16, insomnia-docs-17, insomnia-docs-18). However, there is no evidence of a dedicated 'publish' feature (e.g., hosting a documentation site or public API reference) — only in-app preview and collaborative editing via Git are documented. Missing for 10: a documented publish/export-to-hosted-docs capability, evidence of turning collections (not just specs) into shareable documentation, and any independent confirmation of a publishing workflow.

   • [claimed-docs] “Build and iterate on your OpenAPI specs to design your next API.”
   • [claimed-docs] “View a generated preview of your spec in the right pane.”
   • [claimed-docs] “Automatically linted. Errors display at the bottom of the center pane and include error type, line number, and error message”
   • [claimed-docs] “Generate code snippets automatically in over 12 different programming languages.”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”

   proof ↗⚑ flag

Spec import export

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

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

   Insomnia✓fullprobed8/10

   Insomnia has a dedicated 'Design' feature for building OpenAPI specs with live preview, automatic linting, and code-snippet generation, and it supports full import/export of OpenAPI 3.0/3.1 specs (including via the inso CLI for CI linting), directly matching a spec-first workflow with OpenAPI export. missing for 10: independent hands-on validation of the spec-design workflow specifically (community evidence only discusses general client usage, not OpenAPI spec-first design).

   • [claimed-docs] “Build and iterate on your OpenAPI specs to design your next API.”
   • [claimed-docs] “View a generated preview of your spec in the right pane.”
   • [claimed-docs] “Automatically linted. Errors display at the bottom of the center pane and include error type, line number, and error message”
   • [claimed-docs] “Generate code snippets automatically in over 12 different programming languages.”
   • [claimed-docs] “Collaboratively create APIs with an unlimited number of contributors (free accounts allow unlimited contributors on one project) and git ver…”
   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”
   • [probe] “official CLI documented at https://developer.konghq.com/inso-cli/”

   proof ↗⚑ flag

2. developerImport an OpenAPI spec to generate requests and collections

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

   Insomnia✓fullclaimed8/10

   Insomnia's docs explicitly list OpenAPI 3.0/3.1 (and Swagger) as supported import formats and describe the UI flow (Import → File/Clipboard/URL) to bring specs into collections, with CI-side linting via `inso lint spec`. missing for 10: independent/hands-on confirmation that OpenAPI import correctly generates requests/collections without manual fixes.

   • [claimed-docs] “Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import formats: Insomnia JSON (v4), Insomnia YAML (v5), Postman v2.0/v2.1, HAR, OpenAPI 3.0/3.1, Swagger, WSDL, and cURL”
   • [claimed-docs] “Import a Postman collection or OpenAPI spec into Insomnia Method: UI → Import → choose File/Clipboard/URL.”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”

   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

   Insomnia—none0/10

   Insomnia's AI features documented are limited to mock server generation from prompts/specs and AI commit message suggestions; there is no evidence of AI generating test cases or assertions from an endpoint's spec or responses. Testing capabilities (collection runner, pre-request scripts, chaining) are manual, not AI-driven.

   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”
   • [claimed-docs] “AI commit message suggestions, which help”
   • [claimed-docs] “Automatically test multiple requests in your collections, with unlimited collection runs.”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”

   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

   Insomnia—none0/10

   Insomnia's docs describe general request/response testing, chaining, and OpenAPI spec linting (via 'inso lint spec') for validating the spec file itself, but there is no evidence of a feature that validates live API responses at runtime against an OpenAPI/schema contract to detect drift.

   ⚑ flag

Mocking

1. developerSpin up a mock server from saved examples or a spec so consumers can build before the API exists

   weight 3 · round to Insomnia
   Bruno~partialclaimed3/10

   Bruno's marketing site claims it can 'serve realistic mock responses while you build' (bruno-docs-4), which directly supports a mock-server capability, but there is no further documentation on how mocks are configured (from saved examples, specs, or otherwise), no CLI/spec-based generation details, and no community corroboration of this feature in practice. missing for 10: detailed docs on mock configuration/spec-driven generation, independent/hands-on validation of the mocking feature, examples of using saved request examples as mock responses.

   • [claimed-docs] “Serve realistic mock responses while you build.”

   proof ↗⚑ flag

   Insomnia✓fullclaimed8/10

   Insomnia Cloud mock servers can be created directly from OpenAPI definitions, prompts, or live URL responses, auto-scaffolding routes/responses so consumers can build against the API before it's complete, and dynamic mocking supports realistic templated/fake data responses. missing for 10: independent/hands-on verification of mock server reliability and no evidence of generating mocks directly from saved request 'examples' (only prompt/spec/URL inputs documented).

   • [claimed-docs] “The Insomnia Cloud mock servers allow you to create a mock endpoint in a few steps.”
   • [claimed-docs] “Creates a mock server from a prompt, OpenAPI definition, or live URL response. Automatically scaffolds routes, responses, and configurations…”
   • [claimed-docs] “Auto-generate a mock server from a natural language prompt and one of the following input types: URL, OpenAPI, or JSON.”
   • [claimed-docs] “Dynamic mocking renders Liquid templates so responses can include: - Data from the request (headers, query parameters, path, or body). - Ran…”
   • [claimed-docs] “Dynamic mocking renders Liquid templates so responses can include: Data from the request (headers, query parameters, path, or body).”
   • [claimed-docs] “AI-assisted mock server generation, which transforms prompts or API definitions into mock APIs.”

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

   Insomnia✓fullclaimed8/10

   Insomnia supports collection runs (Collection Runner, unlimited collection runs), chaining requests, pre/post-request scripts, and the Inso CLI which 'disables prompts and provides exit codes to pass or fail the CI workflow,' enabling automated test suites with pass/fail reporting in CI. Docs also show lint commands failing builds on errors, reinforcing pass/fail semantics. missing for 10: no independent/hands-on report confirming the CLI pass/fail report format or reliability in practice, and no detail on report output formatting (e.g., JUnit/HTML report generation).

   • [claimed-docs] “Use the Insomnia CLI to automate the execution of your API tests using your existing Git workflows.”
   • [claimed-docs] “Automatically test multiple requests in your collections, with unlimited collection runs.”
   • [claimed-docs] “Use the Collection Runner to send multiple requests in a specific order”
   • [claimed-docs] “Test complex workflows by chaining the responses from requests together”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Inso CLI is designed to run in a Continuous Integration (CI) environment. It disables prompts and provides exit codes to pass or fail the CI…”
   • [claimed-docs] “In CI, use inso lint spec <identifier> to lint OpenAPI and fail builds on errors.”

   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

   Insomnia~partialclaimed6/10

   Insomnia's docs describe a dedicated testing feature set—chaining requests, pre-/after-response scripting to add logic, automatic cookie handling, and CLI-driven automated test runs across collections—strongly implying support for assertions on response status/body/headers, but no evidence pack item shows explicit assertion syntax or examples asserting on status codes, body content, or headers specifically. Missing for 10: explicit assertion API/examples (e.g., expect(response.status).to.equal), documented header/body matcher functions, and independent hands-on confirmation of assertion authoring.

   • [claimed-docs] “Pre-request and after-response scripting to add logic to your requests”
   • [claimed-docs] “Test complex workflows by chaining the responses from requests together”
   • [claimed-docs] “Automate your tests with Inso CLI”
   • [claimed-docs] “Insomnia automatically stores cookies from every response and sends them with future requests”
   • [claimed-docs] “Automatically test multiple requests in your collections, with unlimited collection runs.”
   • [claimed-docs] “Pre-request scripts allow you to execute tasks before a request is sent. They can be used to: * Manipulate environment variables or authenti…”

   proof ↗⚑ flag