Kong vs Insomnia

Agent access

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

   weight 2 · round to Kong
   Kong✓fullprobed8/10

   A live probe confirms Kong serves a working llms.txt at developer.konghq.com/llms.txt (HTTP 200) describing its documentation set for Gateway, Konnect, AI Gateway, and Mesh, directly matching the story of pointing an agent at an agent-oriented docs entrypoint. Missing for 10: no evidence of a more extensive llms-full.txt or additional per-product agent-doc indexes, and no independent (non-probe) commentary confirming real-world agent usage of this file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.konghq.com/llms.txt # developer.konghq.com > Kong's developer documentation for Kong Gateway,…”

   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 drawn
   Kong✓fullclaimed8/10

   Kong Gateway supports headless/CI operation via DB-less declarative config, decK and kongctl CLI tools for API Lifecycle Automation (APIOps), a RESTful Admin API, and Docker-based deployment—all enabling fully automated, non-interactive pipelines. missing for 10: independent hands-on CI pipeline example or third-party case study demonstrating actual CI/CD integration in production.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”

   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
   Kong~partialclaimed4/10

   Kong's AI Gateway positions itself as an 'MCP Traffic Gateway' that can govern, secure, and observe traffic to/from MCP servers, and its Catalog can inventory MCP servers alongside APIs and agents (kong-docs-65, kong-docs-22, kong-gh-6). However, the evidence centers on Kong auto-generating/exposing MCP servers from REST APIs and proxying/governing MCP traffic between agents and servers, not on Kong itself acting as an MCP client that plugs in external MCP servers to consume their tools directly. Missing for 10: clear documentation of Kong itself invoking/using tools from a connected MCP server (client-side tool use), independent/hands-on confirmation of this workflow, and detail on how a user 'plugs in' an arbitrary third-party MCP server for Kong's own use.

   • [claimed-docs] “MCP Traffic Gateway”
   • [claimed-docs] “Catalog as one inventory across APIs, API packages, AI Models, MCP servers, and agents”
   • [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
   • [claimed-docs] “Auto-discover APIs and compose endpoints into MCP tools”
   • [claimed-docs] “Auto-generate MCP servers that leverage composed MCP tools. One-click deploy to Kong AI Gateway infrastructure.”
   • [claimed-docs] “AI Gateway acts as a control and observability layer for A2A traffic, enabling you to route agent-to-agent requests, extract task metadata, …”

   proof ↗⚑ 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 to Kong
   Kong✓fullprobed8/10

   Kong documents an official Kong Konnect MCP Server (kong-docs-66, kong-probe-3) plus dedicated MCP gateway docs for connecting agents (kong-docs-3, kong-docs-65) and MCP auto-generation/tool composition (kong-docs-53, kong-docs-54). This is first-party documentation of an official MCP server, not just client-side MCP consumption. missing for 10: independent/hands-on third-party verification of the MCP server working end-to-end, and more detail on setup/connection steps beyond marketing copy.

   • [claimed-docs] “Kong Konnect MCP Server”
   • [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”
   • [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
   • [claimed-docs] “MCP Traffic Gateway”
   • [claimed-docs] “Auto-discover APIs and compose endpoints into MCP tools”
   • [claimed-docs] “Auto-generate MCP servers that leverage composed MCP tools. One-click deploy to Kong AI Gateway infrastructure.”
   • [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”

   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
   Kong~partialprobed6/10

   Kong ships official CLIs (decK for declarative APIOps and kongctl for Konnect/Gateway management) documented at developer.konghq.com/deck and /kongctl, which can be scripted/automated by AI-native or agentic workflows. However, there's no evidence these CLIs are explicitly designed or marketed for AI-native/agentic use (e.g., no agent-specific CLI features, no mention of LLM/agent integration in the CLI docs themselves — that capability is described separately for AI Gateway proxying other tools' CLI traffic, not Kong's own CLI being agent-oriented). missing for 10: explicit agentic/AI-native design goals for decK/kongctl, independent hands-on verification of CLI use by AI agents.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [probe] “official CLI documented at https://developer.konghq.com/deck/”

   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 Kong
   Kong✓fullprobed8/10

   Kong exposes a documented public Admin API for configuring the gateway (kong-gh-5, kong-gh-10), a directory of OpenAPI specs for Kong's APIs (kong-docs-9), and RESTful proxying of any API with extensibility via plugins (kong-docs-44), giving AI-native users a clear, documented programmatic surface to drive the product. missing for 10: a live discoverable OpenAPI/swagger machine-readable spec at the docs root (probe found 404s at common openapi.json paths), and independent/hands-on confirmation of API-driven automation beyond vendor docs.

   • [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [claimed-docs] “Kong Gateway runs in front of any RESTful API and can be extended through modules and plugins.”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”

   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 to Kong
   Kong~partialprobed6/10

   Kong Gateway's core auth plugins (JWT, OAuth2, ACLs, API keys) and Vaults for secret storage provide the building blocks for scoped, least-privilege credentials per consumer, and AI Gateway/Konnect docs mention defining entitlements for agent/MCP/tool consumption, suggesting credential scoping applies to agent traffic too. However, there is no dedicated, documented workflow specifically for 'issuing scoped credentials to an AI agent' — the evidence is generic auth/authz plus general entitlement language rather than a concrete agent-credential-issuance feature or example. missing for 10: a first-party doc/example showing scoped API-key/OAuth-scope issuance specifically for an agent identity, and independent/hands-on confirmation of least-privilege enforcement in agent/MCP contexts.

   • [github] “Authentication and authorization for APIs using methods like JWT, basic auth, OAuth, ACLs and more.”
   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities”
   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
   • [claimed-docs] “Define entitlements, meter, and bill against agent context consumption for everything from the agent to the LLM to the MCP server to MCP too…”
   • [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
   • [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”

   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
   Kong—none0/10

   Evidence shows Kong offers CLIs (decK, kongctl), Admin/OpenAPI API directories, and Kong Manager UI, but no evidence of official client SDKs (e.g., language-specific libraries) for building against Kong Gateway/AI Gateway/Konnect APIs.

   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”

   proof ↗⚑ 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 Insomnia
   Kong—none0/10

   Kong's evidence focuses on AI Gateway/MCP traffic management (routing LLM calls, semantic security, observability plugins) but none of it shows Kong itself analyzing a user's own API/traffic data to generate AI insights or suggestions inside the product (e.g., an AI copilot summarizing gateway usage or recommending config changes). This is a plausible feature for a management platform like Konnect, so the axis applies, but no evidence supports it.

   • [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
   • [claimed-docs] “AI Gateway addresses these challenges with a high-performance control plane that secures, governs, and observes AI-native systems end to end…”
   • [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
   • [claimed-docs] “Konnect lets you catalog, connect to, and monitor the status of all API Gateway control planes (CPs) and data plane nodes (DPs) in one place…”

   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 userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Insomnia
   Kong—none0/10

   Kong's evidence describes AI Gateway/MCP governance features for routing and securing AI traffic, but nothing shows Kong itself embedding a built-in assistant that a user delegates tasks to within the product UI (e.g., Konnect). Missing for 10: any documented in-product AI assistant/chat feature, evidence of task delegation to it, and independent confirmation of its use.

   • [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
   • [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
   • [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”

   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

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

   weight 2 · round to Kong
   Kong~partialprobed6/10

   Kong ships an official Konnect MCP Server (kong-docs-66, kong-probe-3), which lets AI-native users operate Kong Konnect via natural-language commands through an MCP client, and Kong also documents AI Gateway support for AI CLIs/agent traffic (kong-docs-58). However, this NL control is scoped to Konnect cloud management rather than the core Gateway, documentation is thin (a one-line stub), and there's no independent/hands-on evidence of the breadth or reliability of natural-language operation. Missing for 10: detailed docs on supported commands/scope, independent user validation, and NL support for the open-source Gateway itself (not just Konnect).

   • [claimed-docs] “Kong Konnect MCP Server”
   • [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”
   • [claimed-docs] “AI Gateway can proxy requests from AI command-line tools to LLM providers. This gives you centralized control over AI traffic: log all reque…”

   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 drawn
   Kong~partialprobed5/10

   Kong provides a Dev Portal that lets users browse/search API documentation and try API operations, and has an OpenAPI directory for its own APIs, which supports interactive exploration with runnable examples; however, the probe for standard OpenAPI/Swagger UI endpoints on the docs site 404'd, and there's no direct evidence of a live 'try it out' interactive console with runnable examples specifically for AI-native users. missing for 10: independent/hands-on confirmation of a runnable 'try it now' console, explicit AI-native tailoring of the interactive reference, and successful OpenAPI/swagger endpoint discovery.

   • [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”

   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
   Kong~partialprobed6/10

   Kong docs explicitly reference a 'Directory of OpenAPI specifications for various Kong APIs' (developer.konghq.com/api/), and Dev Portal supports publishing OpenAPI/AsyncAPI specs, indicating machine-readable specs exist and are downloadable. However, a direct probe for standard OpenAPI file locations (openapi.json, swagger.json, etc.) returned 404s, showing the spec isn't trivially discoverable at conventional endpoints. Missing for 10: a confirmed, directly downloadable OpenAPI/AsyncAPI file link or independent verification that the /api/ directory serves raw machine-readable spec files.

   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”

   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
   Kong—none0/10

   Kong's evidence covers DB-less/declarative deployments, Konnect control-plane/data-plane separation, and a Docker quickstart script, but none of this documents a dedicated 'sandbox environment' or test/staging mode explicitly isolated from production data for AI-native testing — the closest hint is Dev Portal's 'try API operations' feature (kong-docs-21), which is not framed as a sandbox against production. Missing for 10: explicit sandbox/staging environment documentation, mock/test data isolation for AI agent calls, and any first-party guidance on safely testing AI Gateway/MCP flows without touching production traffic.

   • [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
   • [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”
   • [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”

   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
   Kong—none0/10

   While Kong publishes OpenAPI spec directories for its various APIs (kong-docs-9) and has extensive product documentation, no evidence in the pack describes API versioning conventions or any documented deprecation policy for Kong's own APIs (Admin API, Konnect API, AI Gateway API, etc.). The OpenAPI probe even returned 404s, and no changelog/deprecation-notice pages are cited.

   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”

   proof ↗⚑ 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 drawn
   Kong~partialclaimed6/10

   decK and kongctl provide declarative, bulk configuration management (sync entire API/gateway state from files) and the Admin API allows scripted bulk changes, which supports AI-native automation across many entities (routes, services, plugins) at once. However, evidence doesn't show bulk operations specifically framed for AI-native workflows (e.g., bulk operations on AI Models, MCP tools, or catalog entries) beyond general declarative config sync. missing for 10: explicit bulk operation APIs/examples for AI-specific entities (LLMs, MCP servers, agents), independent hands-on validation of bulk operation performance/reliability at scale.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”

   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 drawn
   Kong~partialclaimed5/10

   Kong's plugin architecture (rate-limiting, DLP/safety policies, logging, transformations) lets users define declarative rules that automatically trigger actions on gateway request/response events, and AI Gateway policies (e.g., blocking toxic content) act as automated triggers on AI traffic events. However, there's no evidence of a generic, user-authored event-trigger/automation framework (e.g., 'when X happens do Y' rules across arbitrary events) beyond the fixed set of built-in plugins/policies. Missing for 10: a flexible custom event-trigger rule engine, documentation of arbitrary event types beyond traffic/API-call lifecycle, and independent evidence of this automation working end-to-end.

   • [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
   • [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
   • [claimed-docs] “Rate Limiting - Plugin”
   • [claimed-docs] “The core of AI Gateway is the ability to serve AI Models from various AI Model Providers via a provider-agnostic API.”

   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 userVersion, review, and roll back my automations

   weight 1 · round to Insomnia
   Kong~partialclaimed4/10

   Kong's decK tool is described as enabling 'API Lifecycle Automation (APIOps)' with a toolkit to 'orchestrate and automate' configuration processes, which implies config-as-code that could be version-controlled and reapplied, but the evidence never explicitly describes diffing, review workflows, or rollback of automations. kongctl is also mentioned only by name with no detail. missing for 10: explicit documentation of versioning/diff review, rollback commands or history, and confirmation this applies to AI agent 'automations' rather than just gateway config.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”

   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

Scripting

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

   weight 2 · round to Kong
   Kong~partialclaimed4/10

   Kong's plugin architecture includes request/response transformation plugins (kong-gh-3) that let developers modify ('massage') request and response data, which partially supports the scripting/data-massaging part of the story. However, there is no evidence of an explicit scripting mechanism (e.g., pre-function/post-function or serverless script plugins) or of chaining multiple requests together in sequence. Missing for 10: documented custom-script (pre/post function) plugin capability, explicit request-chaining support, and independent confirmation of these features in practice.

   • [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
   • [claimed-docs] “Rate Limiting - Plugin”

   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
   Kong—none0/10

   The evidence covers Dev Portal visibility settings (public/private), Vaults for secrets, and Catalog for API inventory, but nowhere describes role-based access control or granular view/edit permissions for APIs or collections. No mention of teams, roles, or RBAC constructs in Konnect or Gateway for collaborative access management.

   ⚑ 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 Kong
   Kong✓fullclaimed8/10

   Kong ships a dedicated Dev Portal for publishing API docs (OpenAPI/AsyncAPI, Markdown) with public or authenticated visibility so teams can browse, try operations and self-manage credentials, plus a Catalog feature that acts as a platform-level inventory across APIs, API packages, AI Models, MCP servers and agents for org-wide discovery. This directly matches the platform-engineer story of publishing an internal catalog/portal for API discovery and consumption. missing for 10: independent/hands-on evidence of the Dev Portal or Catalog in real use (only first-party docs), and more detail on cross-team governance/workflow beyond the docs descriptions.

   • [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
   • [claimed-docs] “Catalog as one inventory across APIs, API packages, AI Models, MCP servers, and agents”
   • [claimed-docs] “Catalog gives you a platform-level home for creating, describing, and governing them.”
   • [claimed-docs] “You need to know every API, AI Model, agent, and MCP server your org has built, without checking each team's tools individually”
   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [claimed-docs] “Public visibility without authentication”
   • [claimed-docs] “Private visibility with authentication enabled”
   • [claimed-docs] “Catalog is where these interfaces live instead: APIs, AI Models, and more. Instead of digging through individual products to find what alrea…”
   • [claimed-docs] “Compose API packages from existing operations to serve specific partners or use cases.”

   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

Collections

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

   weight 3 · round to Insomnia
   Kong~partialclaimed6/10

   Kong's decK tool supports declarative configuration files (YAML/JSON) that represent Kong's gateway config as plain text, enabling APIOps-style workflows and 'Declarative Databaseless Deployment' which is commonly stored and versioned in git repos. However, the evidence never explicitly shows a 'collections' concept (like Postman-style API collections) or an explicit git-based workflow/example — it's inferred from decK's declarative config model. Missing for 10: explicit documentation of a 'collections' artifact, an explicit git-versioning workflow/example, and confirmation this applies beyond gateway config to broader workspace collections.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “decK | Kong Docs”
   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”

   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

Offline

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

   weight 2 · round to Kong
   Kong~partialclaimed5/10

   Kong Gateway supports declarative, DB-less deployment and Docker installation that can run entirely locally without Konnect (kong-gh-4, kong-gh-7, kong-gh-20), and decK/kongctl let you manage configuration as local files (kong-docs-67, kong-docs-68). However, the documented quickstart path explicitly creates a Konnect cloud control plane and ties licensing to it (kong-docs-45), and there's no dedicated 'local workspace' concept or explicit confirmation that all features work fully offline without any Konnect account. Missing for 10: a documented fully offline quickstart/workflow that never touches Konnect, and independent confirmation of offline usage without a cloud account.

   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”
   • [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”

   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

Environments

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

   weight 3 · round to Insomnia
   Kong—none0/10

   Kong's evidence covers secrets storage via Vaults (including environment-variable-backed secrets) and multi-control-plane management via Konnect/decK, but there is no documented feature for developers to define and switch between named 'dev/staging/prod' environment variable sets when making requests, as in a client-testing workflow. Missing for 10: explicit environment/variable-set switching UI or config, evidence of per-environment variable collections, and any workflow tying such sets to request execution.

   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
   • [claimed-docs] “You can add secrets to Vaults in one of the following ways: * Environment variables * Konnect Config Store * Supported third-party backend v…”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”

   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 Kong
   Kong✓fullclaimed8/10

   Kong Gateway's Vaults feature explicitly lets platform engineers store secrets outside plaintext config and reference them via environment variables, Konnect Config Store, or third-party vault backends (e.g., HashiCorp Vault), ensuring secrets aren't visible in plaintext throughout the platform. This directly matches the story of masking secrets and integrating with external vaults. Missing for 10: independent/hands-on validation of the vault integration beyond first-party docs, and more detail on which third-party backends are supported.

   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities”
   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities. This ensures that secrets aren't visible in plaint…”
   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
   • [claimed-docs] “You can add secrets to Vaults in one of the following ways: * Environment variables * Konnect Config Store * Supported third-party backend v…”

   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

Ai gateway

1. ai-native userProxy and govern LLM/MCP traffic (token limits, prompt guards, provider routing) through the platform

   weight 2 · round to Kong
   Kong✓fullclaimed9/10

   Kong's AI Gateway explicitly proxies and governs LLM traffic (multi-provider routing, rate limiting, semantic security, DLP/prompt guards, cost control) and dedicated MCP Gateway capabilities cover MCP traffic governance, security, observability, and auto-generation, with docs on rate-limiting plugins, data governance/prompt safety, provider routing, and OTel metrics for GenAI/MCP/A2A traffic. Missing for 10: independent hands-on validation of the AI Gateway/MCP governance features specifically (community evidence only covers unrelated core gateway routing bugs).

   • [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
   • [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
   • [claimed-docs] “The core of AI Gateway is the ability to serve AI Models from various AI Model Providers via a provider-agnostic API.”
   • [claimed-docs] “AI Gateway can proxy requests from AI command-line tools to LLM providers. This gives you centralized control over AI traffic: log all reque…”
   • [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
   • [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
   • [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
   • [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
   • [github] “advanced AI traffic capabilities with multi-LLM support, semantic security, MCP traffic security and analytics”
   • [claimed-docs] “Rate Limiting - Plugin”
   • [claimed-docs] “MCP Traffic Gateway”

   proof ↗⚑ flag

   Insomnia—none0/10

   Insomnia's MCP support is client-side only (docs-30, docs-46) — it lets users discover and invoke external MCP servers' tools/prompts, and a brief mention of connecting to Konnect for 'protecting requests' (docs-14), but there is no evidence of built-in token-limit enforcement, prompt guards, or LLM provider routing/proxying within Insomnia itself. Missing for 10: any documentation of token/rate limiting, prompt injection guards, or multi-provider routing/proxy governance features.

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

Gateway ops

1. platform-engineerManage API infrastructure as declarative config and sync it from CI (GitOps/APIOps)

   weight 2 · round to Kong
   Kong✓fullclaimed8/10

   decK and kongctl are dedicated CLIs for declarative APIOps, explicitly designed for CI-driven sync of Kong config (declarative databaseless deployment, Admin API/decK configuration), which directly matches the GitOps/APIOps story. missing for 10: no explicit worked CI pipeline example (e.g., GitHub Actions) or independent case study confirming production GitOps workflows.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”

   proof ↗⚑ flag

   Insomnia~partialclaimed6/10

   Insomnia supports Git Sync so projects/specs/collections live as files in a Git repo, and Inso CLI is explicitly designed to run in CI (disabling prompts, providing exit codes) to lint OpenAPI specs and run tests as part of pipelines. This gives a real GitOps-style workflow for API design/testing artifacts, but Insomnia manages API client/design/test config, not actual gateway infrastructure (routes, plugins, gateway resources) — that lives in Kong Gateway/Konnect, not Insomnia. Missing for 10: evidence of declaratively managing live gateway/infrastructure resources (not just specs/tests) from Insomnia, and independent/hands-on confirmation of CI pipelines using Inso CLI successfully.

   • [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] “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] “Automate your tests with Inso CLI”
   • [github] “Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.”

   proof ↗⚑ flag

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

   weight 2 · round to Kong
   Kong✓fullclaimed7/10

   Kong Gateway's Admin API is the canonical configuration interface, with Kong Manager UI and decK/kongctl CLI explicitly built on top of it (kong-gh-10, kong-gh-11, kong-docs-67/68), implying API-UI parity by design, and Kong also publishes OpenAPI specs for its APIs (kong-docs-9). Missing for 10: an explicit first-party statement guaranteeing 100% UI/API feature parity (especially for Konnect SaaS UI features) and independent confirmation that no UI-only features exist.

   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [github] “:8002 - access Kong's management Web UI ([Kong Manager](https://github.com/Kong/kong-manager)) on [localhost:8002](http://localhost:8002)”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [claimed-docs] “decK | Kong Docs”
   • [claimed-docs] “kongctl | Kong Docs”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”

   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 Insomnia
   Kong~partialclaimed6/10

   Kong's decK tool lets users declaratively dump and sync Gateway/Konnect configuration (routes, services, plugins) as open YAML/JSON files, and Kong explicitly touts 'databaseless deployment... without any vendor lock-in,' supporting a form of open, portable data export. However this only covers gateway configuration, not broader platform data (analytics, logs, catalog, dev-portal content), and there's no explicit documented full-account data export/deletion workflow. Missing for 10: a documented full data-export/account-closure process covering all Konnect/Catalog/Dev Portal data, and independent confirmation that decK exports are complete and lossless.

   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
   • [claimed-docs] “decK | Kong Docs”
   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [claimed-docs] “Tools for managing Konnect and Kong Gateway”

   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
   Kong~partialclaimed6/10

   The GitHub repo (Kong/kong) is publicly visible and used for docs, issues, and quickstart instructions, indicating the core gateway source is readable in the open, but no evidence pack item explicitly states the license (e.g., Apache-2.0) or confirms all components (AI Gateway, Konnect, plugins) are open-sourced rather than proprietary SaaS add-ons. missing for 10: explicit license statement/file, confirmation that AI Gateway/Konnect/enterprise pieces are also open-source, independent corroboration of license terms.

   • [github] “Let’s test drive Kong by adding authentication to an API in under 5 minutes.”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
   • [github] “Let's test drive Kong by adding authentication to an API in under 5 minutes.”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”

   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 Kong
   Kong✓fullclaimed9/10

   Kong Gateway is open-source (GitHub repo) and explicitly supports self-hosted deployment models including Docker, DB-less, and Hybrid deployments 'without any vendor lock-in', with admin API/decK for configuration and a quickstart script for local setup. This covers the core gateway/AI Gateway functionality, not just the SaaS Konnect offering. Missing for 10: no independent third-party confirmation of large-scale self-hosted production use, and some newer AI/MCP capabilities (Catalog, Konnect MCP Server) appear tied to the Konnect SaaS platform rather than self-hosted core.

   • [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
   • [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
   • [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
   • [claimed-docs] “Kong Gateway runs in front of any RESTful API and can be extended through modules and plugins.”
   • [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”
   • [github] “Kong runs natively on Kubernetes thanks to its official Kubernetes Ingress Controller.”

   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 Insomnia
   Kong—none0/10

   Kong is self-hostable (Gateway can be deployed anywhere, giving implicit data-location control), but the evidence pack contains no explicit region/residency selection feature, no Konnect region options, and no documentation letting a user choose where data is stored.

   ⚑ 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 drawn
   Kong—none0/10

   Kong's AI Gateway evidence covers traffic routing, semantic security/caching, observability, and MCP governance, but nothing in the pack addresses controlling or opting out of AI model training on user data. Missing for 10: any documented feature or policy for preventing data from being used in model training (e.g., zero-retention enforcement, provider opt-out headers, data-use contracts).

   • [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
   • [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
   • [github] “advanced AI traffic capabilities with multi-LLM support, semantic security, MCP traffic security and analytics”

   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 Insomnia
   Kong—none0/10

   Kong's AI Gateway docs cover logging locations, DLP/PII redaction, and secrets vaulting, but there is no documented capability for AI-native users to set data retention windows or explicitly delete stored logs/request data. missing for 10: retention policy configuration, data deletion/purge mechanism, user-facing controls over stored AI traffic data.

   • [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
   • [claimed-docs] “By default, you can view AI Gateway logs at `/usr/local/kong/logs/error.log`. If you're running an AI Gateway data plane in Docker, you can …”
   • [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”

   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 drawn
   Kong—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for Kong products; nothing documents a privacy/telemetry setting.

   ⚑ 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 Kong
   Kong✓fullclaimed7/10

   Kong's Dev Portal explicitly lets developers publish APIs using OpenAPI or AsyncAPI specifications plus Markdown documentation, with configurable public/private visibility, and lets consumers browse/search that documentation and manage credentials — directly matching the story of generating and publishing docs from specs. Missing for 10: explicit support for importing arbitrary 'collections' (e.g., Postman-style) rather than just OpenAPI/AsyncAPI specs, and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
   • [claimed-docs] “Public visibility without authentication”
   • [claimed-docs] “Private visibility with authentication enabled”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”

   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
   Kong—none0/10

   Kong's docs show it can import/publish existing OpenAPI specs (e.g., Dev Portal publishing APIs using OpenAPI/AsyncAPI, decK declarative config) but there is no evidence of a spec-first design/authoring workflow or an OpenAPI export feature for specs created within Kong. missing for 10: a spec-design/editor capability, evidence of generating/exporting an OpenAPI document from a user-authored spec.

   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
   • [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”

   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
   Kong~partialclaimed3/10

   Kong's Dev Portal can publish APIs from OpenAPI/AsyncAPI specs and lets developers 'browse and search API documentation, try API operations' (kong-docs-21, kong-docs-49), which is loosely analogous to generating requests from a spec, but there's no evidence of a Postman-like 'collections' concept or explicit request/collection generation workflow. missing for 10: explicit OpenAPI-import-to-request/collection generation feature, evidence of a collections concept, and any hands-on demonstration of this workflow.

   • [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
   • [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
   • [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”

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

Contract testing

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

   weight 2 · round drawn
   Kong—none0/10

   Kong is an API gateway/traffic management platform with plugins for routing, security, rate limiting, and AI/MCP governance, but there is no evidence of a contract-testing or response-validation-against-spec feature to catch API drift; this is a testing/mocking capability that a full lifecycle toolchain could offer but Kong's evidence pack shows no such capability.

   ⚑ 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