Postman vs Kong

Agent access

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

   weight 2 · round to Postman
   Postman✓fullprobed9/10

   Postman's docs site serves a live llms.txt (HTTP 200) and supports appending .md to any docs page for clean Markdown content, directly enabling an agent to be pointed at agent-oriented docs; this is confirmed hands-on via probes rather than just claimed. missing for 10: independent third-party corroboration that an agent successfully consumed llms.txt end-to-end in a real workflow.

   • [probe] “PROBE llms.txt: HTTP 200 at https://learning.postman.com/llms.txt # Postman Docs # Postman Docs Learn how to use Postman. Search the docs …”
   • [probe] “PROBE docs-md: HTTP 200 at https://learning.postman.com/docs/getting-started/overview/.md > For clean Markdown content of this page, append …”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Postman
   Postman✓fullprobed9/10

   Postman CLI (and Newman) explicitly support headless execution of collections, mocks, and governance checks in CI/CD pipelines, and this is documented alongside the Postman API for programmatic integration into toolchains. Missing for 10: independent/hands-on CI benchmark or third-party case study confirming real-world CI reliability beyond vendor docs.

   • [claimed-docs] “Run and manage collections with extensive configuration options and built-in reporters.”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “combine the Postman API with the Postman CLI to integrate Postman with your CI/CD workflow.”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”
   • [claimed-docs] “Newman allows you to run and test a Postman Collections directly from the command-line.”
   • [probe] “official CLI documented at https://learning.postman.com/docs/postman-cli/postman-cli-overview/”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Kong
   Postman—none0/10

   Evidence shows Postman can generate/register MCP servers (docs-7, docs-9) and has an AI 'Agent Mode' (docs-8), but there is no documentation or hands-on evidence that Postman itself acts as an MCP client, letting users plug in external MCP servers so its AI/tools can consume them. Missing for 10: explicit MCP-client integration inside Postman's AI/Agent Mode, UI/config for adding external MCP servers, and any hands-on proof of tool invocation from a connected MCP server.

   • [claimed-docs] “This guide walks you through registering a Model Context Protocol (MCP) server with the gateway and making it available to your team.”
   • [claimed-docs] “With Agent Mode, you can turn your words into action across the API lifecycle. Send requests, fix errors, update tests, and more, using natu…”
   • [claimed-docs] “With Postman’s MCP Generator, you can create your own MCP server with public APIs from the Postman API Network”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Postman✓fullprobed8/10

   Postman publishes an official MCP server (postman-mcp-server) and documents both registering MCP servers with its Fabric Gateway and generating MCP servers from Postman API collections, giving AI agents a standard way to connect. Missing for 10: independent/hands-on corroboration that the official MCP server works reliably with third-party agents beyond first-party docs.

   • [probe] “official MCP server documented at https://www.postman.com/postman-mcp-server/”
   • [claimed-docs] “This guide walks you through registering a Model Context Protocol (MCP) server with the gateway and making it available to your team.”
   • [claimed-docs] “With Postman’s MCP Generator, you can create your own MCP server with public APIs from the Postman API Network”

   proof ↗⚑ flag

   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

5. ai-native userUse an official CLI

   weight 2 · round to Postman
   Postman✓fullprobed8/10

   Postman ships an official Postman CLI with detailed docs covering running collections, linting, security/governance checks, mock servers, and CI/CD integration, and explicitly documents giving coding agents CLI context for API discovery, code generation, and maintenance tasks, directly matching an AI-native CLI story. A probe confirms the CLI docs page is live and first-party. Missing for 10: independent/hands-on community validation of AI-agent CLI usage beyond vendor docs.

   • [claimed-docs] “Give coding agents Postman CLI context for API discovery, code generation, and maintenance tasks.”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”
   • [probe] “official CLI documented at https://learning.postman.com/docs/postman-cli/postman-cli-overview/”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Postman
   Postman✓fullprobed9/10

   Postman documents a public Postman API for programmatically managing assets (postman-docs-5,41), an OpenAPI spec is live (postman-probe-3), and the API can be combined with CLI/CI-CD workflows (postman-docs-6,19). This is a well-documented, first-party public API surface for driving Postman programmatically. Missing for 10: no independent/hands-on corroboration of API robustness or rate limits from community sources.

   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “combine the Postman API with the Postman CLI to integrate Postman with your CI/CD workflow.”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “Integrate Postman into your development toolchain”
   • [probe] “PROBE openapi: HTTP 200 at https://learning.postman.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Kong
   Postman—none0/10

   Evidence shows Postman has team/workspace role permissions and a Vault for secrets, but nothing documents issuing scoped or least-privilege API credentials specifically for an AI agent's use (e.g., agent-specific API keys, granular scopes, or token restrictions tied to Agent Mode or MCP usage).

   ⚑ flag

   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

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Postman—none0/10

   Evidence shows Postman's own API (postman-docs-5, postman-docs-41) and a CLI (postman-probe-5) for programmatic access, and a feature to generate SDKs *from* user collections (postman-docs-4), but there is no evidence of officially maintained Postman SDKs (e.g., Node/Python/Go client libraries) that an AI-native developer could build against to integrate with Postman itself.

   • [claimed-docs] “Generate and manage client SDKs from your Postman Collections and API specifications.”
   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “Integrate Postman into your development toolchain”

   proof ↗⚑ flag

   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

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Postman
   Postman~partialclaimed6/10

   Postman CLI docs explicitly mention creating, managing, and forwarding webhooks for event-driven integrations and local development, which supports webhook subscription/handling. However, this is a thin CLI feature mention rather than a full first-class webhook subscription API/product surface with detailed setup, event types, or independent corroboration. Missing for 10: dedicated webhook subscription API docs, event catalog/type list, hands-on/independent verification of webhook reliability, and integration examples beyond a single line mention.

   • [claimed-docs] “Create, manage, and forward webhooks for event-driven integrations and local development.”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”

   proof ↗⚑ flag

   Kong—none0/10

   Kong is an API/AI gateway product; the evidence covers proxying, MCP, LLM routing, logging, and OpenTelemetry metrics, but there is no mention of webhook subscription or event-driven notification delivery to AI-native consumers.

   ⚑ flag

Agentic features

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

   weight 2 · round to Postman
   Postman✓fullclaimed7/10

   Postman ships an in-product AI layer (Agent Mode/Postbot) that generates suggestions and takes actions on your API data via natural language — sending requests, fixing errors, updating tests, visualizing responses, and writing documentation — which matches the 'AI-generated insights and suggestions from data' story. Missing for 10: independent/hands-on corroboration of Agent Mode's suggestion quality and no evidence of deeper analytics-driven insights (e.g., AI-derived patterns from usage/monitoring data) beyond action-oriented suggestions.

   • [claimed-docs] “With Agent Mode, you can turn your words into action across the API lifecycle. Send requests, fix errors, update tests, and more, using natu…”
   • [claimed-docs] “You can ask Agent Mode to add tests to requests, visualize responses, write documentation, and more.”
   • [claimed-docs] “Postbot is free to try on all Postman plans . Monthly usage is limited to 50 activities per user.”
   • [claimed-docs] “With Postman’s MCP Generator, you can create your own MCP server with public APIs from the Postman API Network”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Postman
   Postman✓fullclaimed8/10

   Postman ships Agent Mode, a built-in AI assistant that can send requests, fix errors, update tests, and write documentation using natural language (postman-docs-8, postman-docs-33), plus Postbot, another in-app AI assistant with defined usage limits (postman-docs-48). This is a first-party, in-product delegation capability. Missing for 10: independent/hands-on user reports validating Agent Mode's real-world reliability and depth beyond vendor docs.

   • [claimed-docs] “With Agent Mode, you can turn your words into action across the API lifecycle. Send requests, fix errors, update tests, and more, using natu…”
   • [claimed-docs] “You can ask Agent Mode to add tests to requests, visualize responses, write documentation, and more.”
   • [claimed-docs] “Postbot is free to try on all Postman plans . Monthly usage is limited to 50 activities per user.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Postman
   Postman✓fullclaimed8/10

   Postman's Agent Mode explicitly lets users 'turn words into action across the API lifecycle' — sending requests, fixing errors, updating tests — using natural language, plus Postbot for adding tests/docs via natural-language prompts, both first-party documented features. Missing for 10: independent hands-on validation of natural-language command reliability/accuracy beyond vendor docs.

   • [claimed-docs] “With Agent Mode, you can turn your words into action across the API lifecycle. Send requests, fix errors, update tests, and more, using natu…”
   • [claimed-docs] “You can ask Agent Mode to add tests to requests, visualize responses, write documentation, and more.”
   • [claimed-docs] “Postbot is free to try on all Postman plans . Monthly usage is limited to 50 activities per user.”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round to Postman
   Postman~partialclaimed6/10

   Postman's quick-start docs show a real, runnable example (send a request to postman-echo.com/get and view the response) and the API Network lets users 'find any API' with published collections/docs, plus response visualization and Spec Hub for API structure exploration — all consistent with an interactive, runnable API reference. However, there is no explicit evidence of a dedicated 'published documentation with Run-in-Postman' interactive reference page or AI-specific reference browsing feature. missing for 10: explicit documentation of a generated public API reference page with embedded runnable/try-it examples, and any AI-native framing of browsing that reference.

   • [claimed-docs] “Enter `postman-echo.com/get` for the request URL. 3. Click **Send**. Postman displays the response data sent from the server in the lower p…”
   • [claimed-docs] “You'll also learn how to save your request to a collection and write a basic test to validate the API response.”
   • [claimed-docs] “Postman's API client enables you to create and send API [requests](/docs/getting-started/basics/postman-elements/#requests), including HTTP,…”
   • [claimed-docs] “Find any API you need. This is where publishers share their APIs with the world.”
   • [claimed-docs] “[Response visualization](https://learning.postman.com/docs/sending-requests/response-data/visualizer/)”
   • [claimed-docs] “Use [Spec Hub](/docs/design-apis/specifications/overview/) to design your API's structure, or use [types in collections](/docs/design-apis/c…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Postman
   Postman✓fullprobed8/10

   A probe confirms Postman publishes a machine-readable OpenAPI spec at learning.postman.com/openapi.json (valid 'openapi' key), and Postman's own developer API docs and Spec Hub further support spec-based API design/consumption. This directly satisfies the AI-native need to fetch a structured API spec. Missing for 10: no independent/community corroboration of using this spec file in real workflows, and no explicit versioning/documentation of the spec's completeness.

   • [probe] “PROBE openapi: HTTP 200 at https://learning.postman.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “Use Spec Hub to design your API’s structure, or use types in collections to design your API with the Postman Collection format.”
   • [claimed-docs] “Use [Spec Hub](/docs/design-apis/specifications/overview/) to design your API's structure, or use [types in collections](/docs/design-apis/c…”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Postman
   Postman~partialclaimed6/10

   Postman's mock servers and environment/variable management let users simulate API behavior and separate sandbox/staging config from production, directly supporting isolated testing without touching real production data, and these are usable from Agent Mode/CLI workflows that an AI-native user might drive. However, no evidence explicitly frames this as an AI-agent-specific 'sandbox mode' or guarantees isolation from production systems beyond the mock-server abstraction. Missing for 10: explicit documentation tying mock/sandbox environments to AI-agent workflows, an explicit no-production-impact guarantee, and independent/hands-on corroboration of safe sandbox testing.

   • [claimed-docs] “Create a mock server in Postman to simulate a real API server that’s always available to handle requests.”
   • [claimed-docs] “Create a _mock server_ in Postman to simulate a real API server that’s always available to handle requests.”
   • [claimed-docs] “[Deploy a mock server](/docs/design-apis/mock-apis/set-up-mock-servers)”
   • [claimed-docs] “[Create dynamic mock responses](/docs/design-apis/mock-apis/create-dynamic-responses)”
   • [claimed-docs] “Run simulations against local mock servers to test how your service responds to disruptions and performance constraints.”
   • [claimed-docs] “[Variables](https://learning.postman.com/docs/sending-requests/variables/variables/) [Environments](https://learning.postman.com/docs/sendi…”
   • [claimed-docs] “With Agent Mode, you can turn your words into action across the API lifecycle. Send requests, fix errors, update tests, and more, using natu…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Postman—none0/10

   The evidence pack shows the Postman API exists and is documented for programmatic use (postman-docs-5, postman-docs-41) and an OpenAPI spec is publicly served (postman-probe-3), but nothing in the pack references API versioning conventions or a documented deprecation policy for that API. Since a platform API is a reasonable place to expect version/deprecation documentation, absence of such evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “Integrate Postman into your development toolchain”
   • [probe] “PROBE openapi: HTTP 200 at https://learning.postman.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Postman
   Postman✓fullclaimed7/10

   Postman lets users run entire collections (many requests) at once via the CLI/Newman and lets AI-native workflows programmatically manage many Postman assets in bulk through the Postman API (postman-docs-1, postman-docs-5, postman-docs-6, postman-docs-19, postman-docs-42). This directly supports bulk operations across many items (requests, collections, assets) in an automatable, scriptable way suited to AI-native/CI use. missing for 10: no explicit documentation of bulk-specific batch limits/throughput, and no independent hands-on evidence confirming large-scale bulk runs work reliably.

   • [claimed-docs] “Run and manage collections with extensive configuration options and built-in reporters.”
   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “combine the Postman API with the Postman CLI to integrate Postman with your CI/CD workflow.”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “Newman allows you to run and test a Postman Collections directly from the command-line.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Kong
   Postman~partialclaimed4/10

   Postman supports pre-request/post-response scripts that execute automatically around request events (docs-12), webhook creation for event-driven integrations (docs-24), and CI/CD-triggered collection runs (docs-19), which together provide some event-triggered automation. However there is no documented general-purpose rules/trigger engine (e.g., monitors, scheduled alerts, conditional if-event-then-action builder) that lets a user declaratively define arbitrary event-based rules. Missing for 10: a dedicated rule/trigger builder UI or API, conditional logic mapping arbitrary events to arbitrary actions, and independent/hands-on confirmation of this automation working reliably.

   • [claimed-docs] “Postman can run scripts before a request is sent (pre-request) or after (post-response).”
   • [claimed-docs] “Create, manage, and forward webhooks for event-driven integrations and local development.”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Postman~partialcommunity4/10

   Postman documents workspace 'versioning' and team review mechanisms (comments, live sessions, roles/permissions) that could support reviewing automations, but there is no explicit documented rollback/version-history feature for collections or automations, and a community report shows a case where a user's collections were deleted and had to be manually restored via support rather than self-service rollback. missing for 10: explicit version-history/rollback UI or API for collections/automations, first-party docs describing rollback workflow, and independent confirmation that rollback works reliably.

   • [claimed-docs] “Create internal workspaces, where team members can share, version, and discuss their work and collaborate on API projects.”
   • [claimed-docs] “[Comment on APIs](/docs/collaborating-in-postman/comments)”
   • [claimed-docs] “you can start a live session in an HTTP request to collaborate with your team in real time as you test, develop, and troubleshoot.”
   • [community] “One person had 'deleted' all his collections and workspaces after layoff... Postman support restored all the collections but the 'environmen…”

   proof ↗⚑ flag

   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

Scripting

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

   weight 2 · round to Postman
   Postman✓fullclaimed9/10

   Postman docs explicitly confirm pre-request and post-response scripting, passing data between requests, and dynamic parameters, plus CI/CD integration via CLI/Newman to chain and automate these scripted workflows. Missing for 10: independent hands-on corroboration of complex data-massaging scripts beyond vendor docs.

   • [claimed-docs] “Postman can run scripts before a request is sent (pre-request) or after (post-response).”
   • [claimed-docs] “Write scripts to add dynamic behavior to requests and collections. Perform API tests, add dynamic parameters, pass data between requests, an…”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “Newman allows you to run and test a Postman Collections directly from the command-line.”
   • [claimed-docs] “[Variables](https://learning.postman.com/docs/sending-requests/variables/variables/) [Environments](https://learning.postman.com/docs/sendi…”

   proof ↗⚑ flag

   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

Access control

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

   weight 2 · round to Postman
   Postman✓fullclaimed8/10

   Postman docs explicitly state roles and permissions can be defined at team, workspace, and element levels, directly matching the platform-engineer's need to control view/edit access on APIs and collections. Missing for 10: no independent/hands-on corroboration of granular permission enforcement in practice, and no detail on specific role types (admin/editor/viewer) or audit logging.

   • [claimed-docs] “You can define the roles and permissions assigned to team members at the team, workspace, and element levels.”
   • [claimed-docs] “Create internal workspaces, where team members can share, version, and discuss their work and collaborate on API projects.”
   • [claimed-docs] “Workspaces enable you to collaborate with teammates or anyone in the Postman community.”

   proof ↗⚑ flag

   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

Api catalog

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

   weight 2 · round to Kong
   Postman~partialclaimed6/10

   Postman supports internal workspaces for sharing/discovering collections and APIs, an API Network for publishing APIs, and Spec Hub/collection design docs, which together enable an internal catalog-like experience. However, there is no explicit evidence of a dedicated 'developer portal' product or public-facing catalog publishing feature distinct from workspaces. missing for 10: dedicated API portal/catalog publishing feature, evidence of external-facing discovery UI, governance/catalog curation tooling beyond workspace sharing.

   • [claimed-docs] “Create internal workspaces, where team members can share, version, and discuss their work and collaborate on API projects.”
   • [claimed-docs] “Workspaces enable you to collaborate with teammates or anyone in the Postman community.”
   • [claimed-docs] “Find any API you need. This is where publishers share their APIs with the world.”
   • [claimed-docs] “Use Spec Hub to design your API’s structure, or use types in collections to design your API with the Postman Collection format.”
   • [claimed-docs] “Use [Spec Hub](/docs/design-apis/specifications/overview/) to design your API's structure, or use [types in collections](/docs/design-apis/c…”

   proof ↗⚑ flag

   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

Collections

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

   weight 3 · round to Kong
   Postman—none0/10

   Postman's docs describe collections living in cloud workspaces with sharing/versioning via Postman's own platform, but there is no documentation of a native git-friendly, plain-text file storage workflow for collections. Community evidence even shows developers explicitly switching to Bruno specifically because it stores collections as files that can be put in git, implying Postman does not offer this as a first-class workflow.

   • [claimed-docs] “Create internal workspaces, where team members can share, version, and discuss their work and collaborate on API projects.”
   • [claimed-docs] “Workspaces enable you to collaborate with teammates or anyone in the Postman community.”
   • [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] “I remember when one of the 'Core Goals' of Postman was 'Complete control over your data - Keep simple JSON based data formats which can be e…”

   proof ↗⚑ flag

   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

Offline

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

   weight 2 · round to Kong
   Postman!disputedcontradicted4/10

   Docs mention a 'lightweight API client' usable without signing in (postman-docs-34), suggesting some offline capability, but multiple hands-on community reports directly contradict full offline/local-only operation: users report Postman wiping all collections when declining account creation (postman-comm-15), requiring telemetry/online connectivity even for local secrets (postman-comm-11, postman-comm-12), and pushing forced cloud sign-in for data migration (postman-comm-13), plus lost workspaces after account issues (postman-comm-4). This is a concrete, documented conflict between vendor claims and real-world failures, not mere skepticism. Missing for 10: first-party documentation of a persistent fully-offline local workspace mode, and any official acknowledgment/fix of the reported data-loss-on-offline-use bugs.

   • [claimed-docs] “If you're not signed in to a Postman account, you can still send multi-protocol requests using the [lightweight API client]”
   • [community] “I have been using postman offline without an account for a long time. Today when I opened the program it asked me to create an account. When…”
   • [community] “It connects to their servers when it starts up; have to assume their server is down. It used to be so much nicer before they added this 'fea…”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”
   • [community] “I moved from Postman to RapidAPI when Postman tried to get me to sign up for their cloud service just to migrate my data to a new laptop.”
   • [community] “One person had 'deleted' all his collections and workspaces after layoff... Postman support restored all the collections but the 'environmen…”

   proof ↗⚑ flag

   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

Environments

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

   weight 3 · round to Postman
   Postman✓fullcommunity6/10

   Postman docs explicitly reference an 'Environments' feature alongside Variables, and community evidence confirms teams use Postman to test/validate APIs 'across environments,' supporting the dev/staging/prod switching workflow via environment variable sets. However, the evidence pack lacks a detailed first-party doc excerpt walking through creating multiple environments and switching between them. Missing for 10: a direct doc excerpt describing environment creation/switching UI, and independent hands-on confirmation of variable-set switching specifically.

   • [claimed-docs] “[Variables](https://learning.postman.com/docs/sending-requests/variables/variables/) [Environments](https://learning.postman.com/docs/sendi…”
   • [community] “We've been using Postman for a while now, it's invaluable for testing/validating APIs across our environments. One feature we've been waitin…”

   proof ↗⚑ flag

   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

Secrets

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

   weight 2 · round to Kong
   Postman!disputedcontradicted4/10

   Postman advertises 'Postman Vault' to secure credentials (postman-docs-15), but multiple independent community reports claim Postman actually syncs/uploads or logs secrets and environment variables to its servers via telemetry, undermining the 'keep credentials out of shared files' promise (postman-comm-6, postman-comm-12). Missing for 10: detailed docs on secret masking mechanics, external vault (e.g., HashiCorp) integration specifics, and a vendor response addressing the telemetry/secret-leak claims.

   • [claimed-docs] “Send API requests, group them in collections, and secure your data with Postman Vault.”
   • [community] “Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago.”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”

   proof ↗⚑ flag

   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

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

   Postman's Fabric Gateway lets teams register and expose MCP servers (postman-docs-7), which touches the 'govern MCP traffic' idea, but there is no evidence of token limits, prompt/prompt-guard policies, or LLM provider routing/proxying features. missing for 10: token-limit controls, prompt guard/safety policies, LLM provider routing configuration, and any traffic-proxy/rate-limiting documentation for LLM calls.

   • [claimed-docs] “This guide walks you through registering a Model Context Protocol (MCP) server with the gateway and making it available to your team.”

   proof ↗⚑ flag

   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

Gateway ops

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

   weight 2 · round to Kong
   Postman~partialclaimed5/10

   Postman's API (postman-docs-5/6/41) lets teams programmatically manage collections/specs, and the CLI can run governance/lint checks and tests inside CI/CD pipelines (postman-docs-19, postman-docs-22, postman-docs-32), which supports an APIOps-style workflow. However there's no explicit gateway/infrastructure declarative-config model, no Git-native sync mechanism, or IaC-style (Terraform/K8s) integration described—this is closer to CI-triggered testing/governance than full GitOps management of API gateway infra. Missing for 10: explicit gateway-infrastructure-as-code support, native Git-sync workflow, and evidence of managing routing/gateway policies (not just collections/specs) declaratively from CI.

   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “combine the Postman API with the Postman CLI to integrate Postman with your CI/CD workflow.”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “Check API specifications against configured API governance rules.”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”

   proof ↗⚑ flag

   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

Monitoring

1. platform-engineerMonitor API traffic with metrics, logging, and tracing integrations

   weight 2 · round to Kong
   Postman—none0/10

   Postman's evidence pack focuses on API testing, collections, mock servers, collaboration, and an Analytics API for Postman's own usage reporting, but there is no evidence of metrics/logging/tracing integrations (e.g., OpenTelemetry, Prometheus, Datadog) for monitoring live API gateway traffic, which is what a platform-engineer would need. Missing for 10: any documented observability/tracing integration, gateway traffic metrics dashboard, or logging pipeline connecting Postman to APM/observability tools.

   • [claimed-docs] “The Analytics API enables you to explore Postman’s analytics reports programmatically.”
   • [claimed-docs] “This guide walks you through registering a Model Context Protocol (MCP) server with the gateway and making it available to your team.”

   proof ↗⚑ flag

   Kong~partialcommunity7/10

   Kong ships built-in plugins for traffic controls, logging, and monitoring (kong-gh-3), Konnect provides status monitoring of control/data planes (kong-docs-46), and AI Gateway explicitly supports OpenTelemetry (OTLP) metrics export for AI/MCP/A2A traffic plus file/docker logs (kong-docs-61, kong-docs-69). However, a community GitHub issue reports a real production case where Kong logging failed to surface 404 errors during cache rebuilding (kong-comm-1, kong-comm-2), showing logging gaps in practice, and the evidence pack lacks explicit documentation of a dedicated distributed-tracing integration (e.g., Zipkin/Jaeger) beyond OTel metrics. missing for 10: explicit tracing plugin/integration docs, and stronger independent confirmation that logging reliably surfaces all traffic issues.

   • [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
   • [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…”
   • [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
   • [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 …”
   • [community] “We have noticed in our Kong Gateway nodes times when common endpoints throw 404 route not found on a % of API calls... nothing in Kong loggi…”
   • [community] “To us the behavior points to cache rebuilding during new resource creation... production has not seen this issue with identical Kong configu…”

   proof ↗⚑ flag

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

   weight 2 · round to Kong
   Postman~partialprobed6/10

   Postman ships a documented Postman API for programmatic management of assets (collections, workspaces, environments, mocks, analytics) plus a CLI and an official OpenAPI spec, showing broad but not exhaustive API parity with the UI. There's no evidence that UI-only features like Live Sessions, Postbot/Agent Mode, or real-time collaboration have full API equivalents. missing for 10: explicit documentation confirming 1:1 API coverage of collaboration/AI features, independent verification of parity, and any gaps/limitations list.

   • [claimed-docs] “Use the Postman API to programmatically manage your Postman assets and integrate Postman into your development toolchain.”
   • [claimed-docs] “Integrate Postman into your development toolchain”
   • [claimed-docs] “The Analytics API enables you to explore Postman’s analytics reports programmatically.”
   • [probe] “PROBE openapi: HTTP 200 at https://learning.postman.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://learning.postman.com/docs/postman-cli/postman-cli-overview/”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Kong
   Postman!disputedcontradicted4/10

   Postman's Collection format is JSON-based and documented as exportable (postman-docs-16, comm-14 recalls Postman's stated 'core goal' of JSON export for full data control), but multiple hands-on community reports concretely contradict free portability: users had all collections/workspaces wiped when declining a forced account creation (postman-comm-15), had to dig into hidden config folders to manually recover a backup (postman-comm-16), were pushed to a paid cloud subscription just to migrate data to a new machine (postman-comm-13), and reported secrets/environment data being silently uploaded to Postman's servers (postman-comm-6, postman-comm-12). missing for 10: an official bulk/full-account data export tool, evidence of successful account-free clean exits, and a rebuttal to the documented forced-login data-wipe incidents.

   • [claimed-docs] “Use Spec Hub to design your API’s structure, or use types in collections to design your API with the Postman Collection format.”
   • [community] “I remember when one of the 'Core Goals' of Postman was 'Complete control over your data - Keep simple JSON based data formats which can be e…”
   • [community] “I have been using postman offline without an account for a long time. Today when I opened the program it asked me to create an account. When…”
   • [community] “I was able to manually import/restore using a backup I found in ~/.config/Postman but I have no trust for continued use of this tool.”
   • [community] “I moved from Postman to RapidAPI when Postman tried to get me to sign up for their cloud service just to migrate my data to a new laptop.”
   • [community] “Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago.”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Kong
   Postman—none0/10

   Postman is a closed-source, proprietary SaaS/desktop product; no evidence of an open-source license for its core codebase is provided, and community comments actually reflect frustration with lock-in and lack of local/offline data control, not openness of source. Since the axis (open license to read source) applies to any product category, absence of evidence means 'none'.

   • [community] “Postman dug its own grave after selling out itself for VC money... The 'File over app' philosophy is a direction that we should be supportin…”
   • [community] “I remember when one of the 'Core Goals' of Postman was 'Complete control over your data - Keep simple JSON based data formats which can be e…”
   • [community] “My main gripe with Postman and Insomnia isn't actually the web based UI, but the lock-in. Postman especially tries to push people towards ge…”

   proof ↗⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round to Kong
   Postman—none0/10

   Postman is a cloud-based SaaS product with a desktop client that syncs to Postman's servers; there is no evidence of a self-hostable core product (e.g., on-prem/enterprise server package). Community evidence even highlights forced cloud sync and telemetry requirements, but no self-hosting option is documented anywhere in the pack.

   • [community] “Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago.”
   • [community] “It connects to their servers when it starts up; have to assume their server is down. It used to be so much nicer before they added this 'fea…”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”
   • [community] “I have been using postman offline without an account for a long time. Today when I opened the program it asked me to create an account. When…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Postman—none0/10

   No evidence in the pack mentions data residency, region selection, or geographic storage controls for Postman workspaces/collections. Community evidence instead raises concerns about data being uploaded to Postman's servers and telemetry, but this doesn't address region choice specifically. missing for 10: any documentation of regional data residency options, EU/US data center selection, or enterprise data-locality controls.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Postman—none0/10

   No evidence pack item addresses AI training data opt-out or a data-use policy control for AI features (Agent Mode/Postbot); in fact community reports raise concerns about data/telemetry being sent to Postman's servers without any documented opt-out for AI training use. Missing for 10: any documentation of an AI-training opt-out setting, privacy policy statement on model training, or admin control to restrict data use for AI training.

   • [community] “Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago.”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”

   proof ↗⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Postman—none0/10

   No documentation describes explicit data retention or deletion controls (e.g., configurable retention windows, GDPR-style delete API, data export/purge tools) for Postman. Community reports actually describe the opposite experience — data being wiped without consent, forced cloud account creation, and secrets/telemetry being uploaded to Postman's servers — reinforcing the absence of user-controlled retention/deletion.

   • [community] “One person had 'deleted' all his collections and workspaces after layoff... Postman support restored all the collections but the 'environmen…”
   • [community] “I moved from Postman to RapidAPI when Postman tried to get me to sign up for their cloud service just to migrate my data to a new laptop.”
   • [community] “I have been using postman offline without an account for a long time. Today when I opened the program it asked me to create an account. When…”
   • [community] “I was able to manually import/restore using a backup I found in ~/.config/Postman but I have no trust for continued use of this tool.”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Postman—none0/10

   No documentation in the evidence pack describes a telemetry/usage-tracking opt-out setting for Postman, and community reports indicate the opposite — users note Postman 'needs to be online in order to send telemetry' and that it uploads secrets/environment data without an apparent way to disable this (postman-comm-11, postman-comm-12, postman-comm-6). No first-party privacy/opt-out control is documented anywhere in the pack.

   • [community] “It connects to their servers when it starts up; have to assume their server is down. It used to be so much nicer before they added this 'fea…”
   • [community] “Apparently Postman needs to be online in order to send 'telemetry': postman is logging all your secrets and environment variables.”
   • [community] “Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago.”

   proof ↗⚑ flag

   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

Docs generation

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

   weight 2 · round to Kong
   Postman—none0/10

   The evidence pack covers Postman's collections, mock servers, Spec Hub, CLI, and API, but no citation describes generating or publishing API documentation from collections/specs — a well-known Postman feature not evidenced here. missing for 10: explicit documentation generation/publish feature evidence, public doc hosting/sharing links, generated reference examples.

   ⚑ flag

   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

Spec import export

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

   weight 2 · round to Postman
   Postman~partialclaimed5/10

   Postman's docs explicitly mention 'Spec Hub' for designing an API's structure before building requests/collections, supporting spec-first design (postman-docs-16, postman-docs-38). However, the evidence pack never explicitly documents exporting that spec as an OpenAPI file/format, only that specs can be created and CLI can 'lint API schemas' (postman-docs-32), leaving the export step unconfirmed. Missing for 10: explicit documentation of OpenAPI export/download from Spec Hub, and independent/hands-on confirmation of round-tripping a spec-first design to OpenAPI.

   • [claimed-docs] “Use Spec Hub to design your API’s structure, or use types in collections to design your API with the Postman Collection format.”
   • [claimed-docs] “Use [Spec Hub](/docs/design-apis/specifications/overview/) to design your API's structure, or use [types in collections](/docs/design-apis/c…”
   • [claimed-docs] “The Postman CLI enables you to run collections, lint API schemas, run security and governance checks, and log in and out.”

   proof ↗⚑ flag

   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

2. developerImport an OpenAPI spec to generate requests and collections

   weight 3 · round to Postman
   Postman~partialclaimed4/10

   Docs reference a 'Spec Hub' for designing API structure and using Postman Collection format types, which implies API-spec-driven authoring, but no evidence explicitly describes importing an OpenAPI spec file to auto-generate requests/collections. missing for 10: explicit OpenAPI import feature documentation, generated request/collection examples, and any independent confirmation of the import workflow.

   • [claimed-docs] “Use Spec Hub to design your API’s structure, or use types in collections to design your API with the Postman Collection format.”
   • [claimed-docs] “Use [Spec Hub](/docs/design-apis/specifications/overview/) to design your API's structure, or use [types in collections](/docs/design-apis/c…”
   • [claimed-docs] “Send API requests, group them in collections, and secure your data with Postman Vault.”

   proof ↗⚑ flag

   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

Contract testing

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

   weight 2 · round to Postman
   Postman~partialclaimed6/10

   Postman supports writing test scripts that assert on live response status/body/schema, contract/governance checks against API specs via the CLI, and mock servers to compare expected vs actual behavior, which together enable a platform engineer to catch drift between live responses and a contract. However, there's no dedicated 'contract testing' feature that explicitly diffs live responses against an OpenAPI/spec definition — it relies on manually written test scripts or governance rule checks rather than automated schema validation of live traffic. missing for 10: a first-party automated schema-diff/contract-validation feature (e.g., built-in OpenAPI response validation against live traffic), and independent/hands-on evidence confirming this workflow catches real drift in practice.

   • [claimed-docs] “Check API specifications against configured API governance rules.”
   • [claimed-docs] “Postman can run scripts before a request is sent (pre-request) or after (post-response).”
   • [claimed-docs] “Write scripts to add dynamic behavior to requests and collections. Perform API tests, add dynamic parameters, pass data between requests, an…”
   • [claimed-docs] “You can also use the Postman CLI to run test collections as part of your continuous integration and continuous delivery (CI/CD) pipeline.”
   • [claimed-docs] “You'll also learn how to save your request to a collection and write a basic test to validate the API response.”

   proof ↗⚑ flag

   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