WooCommerce vs Swell

Agent access

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

   weight 2 · round to WooCommerce
   WooCommerce✓fullprobed9/10

   A direct probe confirms an llms.txt file is live at developer.woocommerce.com/llms.txt returning HTTP 200 with structured documentation listing, and there's an official MCP server for AI agent interaction with WooCommerce stores, directly supporting agent-oriented discovery. Missing for 10: no independent/community corroboration of agents actually using llms.txt successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.woocommerce.com/llms.txt # WooCommerce Documentation This file contains a list of all documen…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell—none0/10

   A direct probe of the documented llms.txt path returns 404, and no evidence pack item shows a dedicated agent-oriented docs endpoint (e.g., markdown docs, llms.txt, or similar) that an agent could be pointed at; the swell.is/ai marketing page describes AI-friendly schema/API concepts but not a llms.txt or agent-consumable doc file.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   WooCommerce~partialprobed4/10

   WooCommerce ships WC-CLI for command-line store management and a REST API for scripted automation, which supports some headless/CI-style operations, but there is no evidence of a documented headless runtime mode, containerized CI test harness, or official guidance for running WooCommerce end-to-end in a CI pipeline. missing for 10: documented headless/CI deployment pattern, official CI/testing pipeline integration, evidence of automated store provisioning without a GUI.

   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [github] “Once you've installed all prerequisites, the following will prepare all of the build outputs necessary for development”

   proof ↗⚑ flag

   Swell~partialprobed4/10

   Swell ships an official CLI (`swell app init/push`, switch store) and a REST/webhook API that could in principle be scripted in automation pipelines, and the AI page mentions a 'validate-deploy-verify loop' agents can drive via the CLI, implying non-interactive usage. However, there is no explicit documentation of CI/headless execution, environment variables for non-interactive auth in CI, or any CI/CD integration guide. Missing for 10: explicit CI/CD documentation or examples, non-interactive auth flow guidance, and independent confirmation of headless automation use.

   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “swell app push: push configuration files to a development store”
   • [claimed-docs] “Switch your current default store.”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [probe] “official CLI documented at https://developers.swell.is/apps/cli”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   WooCommerce—none0/10

   Evidence only shows WooCommerce exposing itself as an MCP *server* so external AI assistants can call its tools (docs-14/29/probe-3), not WooCommerce acting as an MCP *client* that plugs in and consumes tools from other MCP servers. No documentation or feature describes WooCommerce connecting outward to third-party MCP servers.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell—none0/10

   Swell is an e-commerce platform; evidence describes CLI, functions, webhooks, and an AI-assisted schema/model workflow, but nothing indicates Swell can consume external MCP servers or plug in third-party tool sets. Absence of evidence for an applicable capability means 'none'.

   ⚑ flag

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

   weight 3 · round to WooCommerce
   WooCommerce✓fullprobed7/10

   WooCommerce documents native MCP support enabling AI assistants to interact directly with stores via a standardized protocol, confirmed by both docs and a probe of the dedicated MCP feature page. Missing for 10: independent/hands-on corroboration of the MCP server working in practice, and details on setup/configuration depth.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell—none0/10

   Evidence shows a CLI, webhooks, and 'agent'-friendly file-based contract, but no mention of an official MCP server or MCP protocol support anywhere in the docs or probes; probes even show llms.txt and openapi.json as 404, suggesting no structured agent-integration endpoint. Swell is a commerce platform (not itself an agent), so this axis applies, but no evidence confirms it ships an MCP server.

   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”
   • [probe] “official CLI documented at https://developers.swell.is/apps/cli”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to WooCommerce
   WooCommerce✓fullprobed8/10

   WooCommerce documents an official WC-CLI for managing stores via command line (woocommerce-docs-13, woocommerce-probe-4), and separately ships native MCP support enabling AI assistants to interact with stores (woocommerce-docs-14/29/probe-3), which together satisfy the 'official CLI for AI-native workflows' story. Missing for 10: independent/hands-on verification of CLI usage in AI-agent workflows, and no explicit documentation tying the CLI itself to AI-native tooling (MCP is separate from CLI).

   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell✓fullprobed7/10

   Swell documents an official CLI (swell app init, push, switch store) and explicitly ties it into an AI-agent workflow ('Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop'), showing intent for AI-native usage. Missing for 10: independent/hands-on corroboration of agentic CLI usage, and deeper documentation of AI-specific CLI commands beyond app scaffolding.

   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “Switch your current default store.”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “swell app push: push configuration files to a development store”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [probe] “official CLI documented at https://developers.swell.is/apps/cli”

   proof ↗⚑ flag

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

   weight 3 · round to WooCommerce
   WooCommerce✓fullprobed9/10

   WooCommerce documents a full REST API (v3) with authenticated CRUD access to store data, official client libraries in multiple languages, a customer-facing Store API, a CLI, webhooks, and even a native MCP server enabling AI assistants to interact directly with stores — together this is a well-documented public API surface highly suited to AI-native/agentic use. Missing for 10: no published OpenAPI/Swagger spec (probe found 404s) and no independent hands-on developer report confirming ease of programmatic use.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “The Store API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality.”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.woocommerce.com/openapi.json, https://developer.woocommerce.com/swagger.json, http…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”

   proof ↗⚑ flag

   Swell✓fullprobed7/10

   Swell exposes a documented backend REST API with authentication (basic auth, environment-specific keys), official Node/PHP client libraries, and endpoints for products, stock, purchase links, etc., plus a runtime schema-introspection call and CLI for driving apps/config programmatically. However, no OpenAPI spec or llms.txt was discoverable (probes 404), reducing machine-readability for agentic consumption. Missing for 10: a discoverable OpenAPI/machine-readable spec, independent third-party confirmation of API robustness.

   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “Keys are environment-specific: secret keys prefixed sk_test_ route requests to your store's test environment, while sk_live_ keys target liv…”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “authenticate with basic auth using your store ID as the username and a secret key as the password”
   • [claimed-docs] “Purchase links allow you to configure a pre-selected group of products within a cart and direct a customer to its checkout through a designa…”
   • [claimed-docs] “Stock adjustments are used to keep track of inventory changes over time.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed6/10

   WooCommerce's REST API key generation lets admins choose an access level (Read, Write, or Read/Write) per user, and API access conforms to that WordPress user's roles/capabilities — enabling coarse-grained least-privilege credential issuance for an agent. However, this is role/permission-level scoping, not fine-grained resource- or action-specific scoping, and there's no documented agent-specific provisioning flow, key expiration/rotation, or scope granularity beyond the three access levels. Missing for 10: granular per-resource/per-endpoint scoping, dedicated agent-credential workflow, expiration/rotation controls, and independent corroboration of least-privilege usage in agentic contexts.

   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”

   proof ↗⚑ flag

   Swell—none0/10

   Swell's API auth docs only show basic auth with a secret key and test/live key environments (sk_test_/sk_live_), not granular, scoped or least-privilege credential issuance for agents; team role/permission assignment (docs-17) applies to dashboard users, not API credentials. No evidence of scoped API tokens, OAuth scopes, or agent-specific credential minting.

   • [claimed-docs] “Keys are environment-specific: secret keys prefixed sk_test_ route requests to your store's test environment, while sk_live_ keys target liv…”
   • [claimed-docs] “authenticate with basic auth using your store ID as the username and a secret key as the password”
   • [claimed-docs] “Assign specific roles and permissions to team members for better control.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to WooCommerce
   WooCommerce✓fullclaimed8/10

   WooCommerce documents official REST API client libraries in multiple languages (JavaScript, PHP, Python, Ruby), plus a documented REST/Store API and CLI, giving AI-native developers official SDK-level building blocks. Missing for 10: independent/hands-on corroboration of SDK quality and completeness, and no unified 'official SDK' branding beyond the library list.

   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”

   proof ↗⚑ flag

   Swell~partialprobed6/10

   Swell documents official backend API libraries for Node and PHP plus a first-party CLI, which supports building against official SDKs, but coverage is limited to two languages and there's no evidence of broader SDK ecosystem (e.g., Python, Go) or independent corroboration; openapi/llms.txt probes returned 404, suggesting weaker machine-readable API contract support. missing for 10: SDKs beyond Node/PHP, independent/hands-on validation, discoverable OpenAPI spec.

   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to WooCommerce
   WooCommerce✓fullclaimed9/10

   WooCommerce has native, well-documented webhook support that lets a store send automatic event notifications to any configurable URL, letting an AI-native agent subscribe to store events like order created/updated. Missing for 10: independent hands-on corroboration or examples of AI agents actually consuming these webhooks.

   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “A webhook is an event notification sent to a URL of your choice. You (or your developer) can configure a webhook that is triggered by events…”

   proof ↗⚑ flag

   Swell✓fullclaimed8/10

   Swell's docs explicitly describe webhooks that subscribe to model events and call external URLs, enabling event-driven/agentic integrations (swell-docs-5, swell-docs-25). Missing for 10: independent/hands-on corroboration of webhook reliability and a documented list of supported event types/payloads beyond the overview mention.

   • [claimed-docs] “Webhooks can be configured to call a URL when a particular event occurs, enabling outgoing calls to external services.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   WooCommerce—none0/10

   The evidence shows WooCommerce exposes data via REST API, MCP, and CLI for external AI tools to interact with the store, but there is no evidence of native AI-generated insights or suggestions surfaced inside the WooCommerce product itself (e.g., an AI-powered analytics/insights dashboard). MCP support enables external agents to query data but does not itself constitute in-product AI-generated insights.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell—none0/10

   Swell's AI-related docs focus on making its schema/API machine-readable for external agents to build integrations (schema discovery, model generation, CLI loop), not on the product itself surfacing AI-generated insights or suggestions from store data to users. Reporting features (swell-docs-35) are plain analytics with no AI generation mentioned.

   • [claimed-docs] “Drop a JSON file into your app’s models/ directory and Swell generates the REST resource from it—fields, validation, relationships and lifec…”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [claimed-docs] “Access detailed reports that aid in tracking and analyzing your store's performance.”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialprobed5/10

   WooCommerce documents webhooks that automatically fire event notifications in the background (docs-8, docs-26) and now ships native MCP support so AI assistants can programmatically interact with store data (docs-14, docs-29, probe-3), which together provide building blocks for background automation. However there's no evidence of a built-in 'set up an autonomous agent/workflow' feature for AI-native users beyond these primitives — automations still require external tooling or custom code via the REST API/CLI. Missing for 10: a first-party autonomous agent/automation-builder UI, documentation of persistent background AI-driven workflows, and independent confirmation that MCP-driven automations actually run unattended in production.

   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “A webhook is an event notification sent to a URL of your choice. You (or your developer) can configure a webhook that is triggered by events…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”

   proof ↗⚑ flag

   Swell~partialclaimed4/10

   Swell provides webhooks and serverless functions that could be composed into background automations (event-triggered external calls, edge functions with no cold start), but there is no documented dedicated 'automation' or scheduling/workflow engine, and the AI-agent skills content (swell-probe-rt-2) is about coding-time development assistance, not autonomous runtime automations. Missing for 10: a described automation/orchestration feature, scheduling or trigger-based workflow builder, and evidence of autonomous background execution beyond raw webhook/function primitives.

   • [claimed-docs] “Webhooks can be configured to call a URL when a particular event occurs, enabling outgoing calls to external services.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Functions are deployed to edge data centers in 200+ locations and have no cold start time.”
   • [claimed-docs] “Functions have no cold boots and do not require extra time to start up before executing your code.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   WooCommerce—none0/10

   Evidence shows WooCommerce supports the Model Context Protocol so external AI assistants/tools can connect to and interact with a store (docs-14, docs-29, probe-3), but this is the reverse of the story — it makes WooCommerce a target for external agents, not a built-in AI assistant inside the product that a user can delegate tasks to. No dashboard-embedded assistant, chat interface, or agentic feature is documented anywhere in the evidence pack.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”

   proof ↗⚑ flag

   Swell—none0/10

   Swell's docs describe making the platform friendly to external AI coding agents (schema discovery endpoint, file-based model generation, CLI hooks) but there is no evidence of a built-in AI assistant embedded in the Swell dashboard/product that a user can delegate tasks to directly.

   • [claimed-docs] “Drop a JSON file into your app’s models/ directory and Swell generates the REST resource from it—fields, validation, relationships and lifec…”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [claimed-docs] “One call returns a store's whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialprobed6/10

   WooCommerce documents native MCP support enabling AI assistants to interact with stores via a standardized protocol, which is the concrete mechanism for natural-language/agentic operation, and a CLI exists for scripted control. However, evidence is limited to first-party docs with no independent hands-on verification of natural-language command execution in practice. Missing for 10: independent/community validation that MCP-driven natural language commands actually work end-to-end, breadth of supported operations via MCP, and any real-world usage reports.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”

   proof ↗⚑ flag

   Swell—none0/10

   The evidence describes Swell's AI-focused developer tooling (CLI, JSON model files, schema introspection API, webhooks) aimed at letting AI coding agents build integrations, but nothing shows an end user issuing natural-language commands to operate the storefront/admin platform itself — the CLI (swell-docs-4, swell-docs-24, swell-docs-33, swell-docs-44) is a traditional command-line tool, not an NL interface. Missing for 10: any chat/NL command interface, conversational operation of dashboard or storefront, or documentation of natural-language input being parsed/executed by the product.

   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “swell app push: push configuration files to a development store”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   WooCommerce—none0/10

   WooCommerce publishes REST API reference documentation (docs-11, docs-27, docs-44, docs-x1/x2) but there is no evidence of an interactive, runnable API console (e.g., Swagger/OpenAPI explorer); a direct probe for OpenAPI/Swagger specs on the developer site returned 404 on all candidate paths (woocommerce-probe-2), indicating no interactive reference exists.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.woocommerce.com/openapi.json, https://developer.woocommerce.com/swagger.json, http…”

   proof ↗⚑ flag

   Swell—none0/10

   No evidence of an interactive API reference or runnable examples; probes explicitly show no OpenAPI/Swagger spec and no llms.txt found, and none of the docs mention a live/interactive API explorer.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   WooCommerce—none0/10

   WooCommerce documents a REST API extensively (woocommerce-docs-11, -27, -44, -x1, -x2) but a direct probe for machine-readable OpenAPI/Swagger specs at expected paths returned 404 across all candidates (woocommerce-probe-2), and no evidence pack item links to a downloadable OpenAPI/Swagger JSON/YAML file. The REST API docs site appears to be human-readable documentation, not a published machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.woocommerce.com/openapi.json, https://developer.woocommerce.com/swagger.json, http…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”

   proof ↗⚑ flag

   Swell—none0/10

   Direct probes for OpenAPI/Swagger files and llms.txt all returned 404, and no documentation item advertises a downloadable machine-readable API spec; the runtime schema endpoint (swell-docs-9/22) describes store data models, not an OpenAPI contract.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “One call returns a store's whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”

   proof ↗⚑ flag

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

   weight 1 · round to Swell
   WooCommerce—none0/10

   No evidence pack item describes a sandbox/staging environment, test-mode API keys, or any mechanism for testing WooCommerce (including its REST API or MCP integration) without affecting production data. The REST API and MCP docs describe live store interaction only, with no mention of a sandbox mode.

   ⚑ flag

   Swell~partialclaimed6/10

   Swell provides environment-specific API keys (sk_test_ vs sk_live_) that route to a store's test environment, and CLI commands reference a 'development store' for pushing configs, indicating a sandbox distinct from production data. However, there's no explicit AI-native workflow documentation tying this test environment to agentic testing loops, and the AI-focused docs emphasize schema/model generation rather than sandbox isolation explicitly. Missing for 10: explicit documentation of an AI agent using the test environment in its validate-deploy-verify loop, and independent/hands-on confirmation that sandbox data is fully isolated from production.

   • [claimed-docs] “Keys are environment-specific: secret keys prefixed sk_test_ route requests to your store's test environment, while sk_live_ keys target liv…”
   • [claimed-docs] “swell app push: push configuration files to a development store”
   • [claimed-docs] “Switch your current default store.”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed4/10

   WooCommerce's REST API is explicitly versioned (v1/v2/v3 under /wp-json/wc/v3/), satisfying the 'versioned APIs' half of the story, but the evidence pack directly states 'no deprecation-timeline policy is published' for these APIs. Missing for 10: a documented deprecation/sunset timeline or migration guide between API versions, and any changelog specifying when older versions (v1/v2/legacy) will be retired.

   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”

   proof ↗⚑ flag

   Swell—none0/10

   No evidence pack item mentions API versioning or a deprecation policy; probes for openapi.json/llms.txt also failed, suggesting no discoverable machine-readable API spec either. This is a fair question for an API-driven commerce platform, but nothing in the evidence supports it.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

Agent discovery

1. ai-native userMy products are discoverable by AI agents and answer engines through a cross-merchant catalog or feed built for agents

   weight 2 · round drawn
   WooCommerce—none0/10

   Evidence shows only single-store integrations (REST API, MCP server, llms.txt for developer docs) that let an agent interact with one WooCommerce store's own data — there is no evidence of a cross-merchant catalog, aggregated product feed, or answer-engine-oriented discovery layer spanning multiple WooCommerce merchants.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.woocommerce.com/llms.txt # WooCommerce Documentation This file contains a list of all documen…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”

   proof ↗⚑ flag

   Swell—none0/10

   Swell's AI-related docs focus on making a single store's own schema/API programmatically accessible to developers/agents building on Swell (schema endpoint, JSON model generation, CLI), not on a cross-merchant catalog or feed that lets external AI agents or answer engines discover products across multiple Swell merchants. No evidence of a shared product feed, marketplace-wide index, or agent-facing discovery layer spanning stores.

   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “One call returns a store's whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “Drop a JSON file into your app’s models/ directory and Swell generates the REST resource from it—fields, validation, relationships and lifec…”
   • [claimed-docs] “Drop a JSON file into your app's models/ directory and Swell generates the REST resource from it—fields, validation, relationships and lifec…”

   proof ↗⚑ flag

Agent ops

1. ai-native userAn agent can take an order through its post-purchase lifecycle — status, fulfillment, returns — via documented APIs and webhooks without a human in the admin

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed4/10

   WooCommerce's REST API (v3) documents CRUD access to WC data and webhooks for automatic event notifications, which could plausibly cover order status changes, and the Managing Money guide mentions issuing refunds — giving a technical path for agent-driven order lifecycle actions. However, there is no explicit documentation of an orders/returns endpoint, no RMA/returns workflow, and fulfillment is described only via the human-facing dashboard/shipping-label workflow, not an API a fully autonomous agent could drive end-to-end. Missing for 10: explicit order-status/fulfillment REST endpoints, a documented returns/RMA API, and evidence that refunds/fulfillment can be completed via API+webhooks without any admin UI step.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “A webhook is an event notification sent to a URL of your choice. You (or your developer) can configure a webhook that is triggered by events…”
   • [claimed-docs] “This includes topics such as listing transactions, viewing your payouts, issuing refunds to customers, and so on.”
   • [claimed-docs] “our Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing y…”
   • [claimed-docs] “our Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing y…”
   • [claimed-docs] “Carriers verify shipment information during the delivery process and compare the cost paid for the shipping label to the actual cost to ship…”
   • [claimed-docs] “If the amount paid for the label is incorrect, it can result in an adjustment.”

   proof ↗⚑ flag

   Swell—none0/10

   The evidence pack shows Swell has a backend API, webhooks for model events, and stock/inventory adjustment endpoints, but nothing documents order status tracking, fulfillment workflows, or returns/RMA processes exposed via API or webhook events. Without concrete evidence of order-lifecycle endpoints (status changes, fulfillment triggers, return creation/processing), there's no basis to say an agent can manage the full post-purchase lifecycle without human intervention in admin.

   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Stock adjustments are used to keep track of inventory changes over time.”
   • [claimed-docs] “Webhooks can be configured to call a URL when a particular event occurs, enabling outgoing calls to external services.”

   proof ↗⚑ flag

Agentic checkout

1. ai-native userA shopping agent can discover my store's products and build carts through a documented agent-commerce endpoint on the store (MCP/UCP), not by scraping

   weight 3 · round to WooCommerce
   WooCommerce✓fullprobed7/10

   WooCommerce documents native MCP support enabling AI assistants/tools to interact directly with stores via a standardized protocol, and separately exposes Store API endpoints for product listing, search, and cart-to-order conversion — together matching the story of a documented agent-commerce endpoint rather than scraping. Missing for 10: explicit documentation of which MCP tools/endpoints cover product discovery and cart-building specifically, no UCP mention, and no independent/hands-on validation that the MCP server works as described.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [claimed-docs] “The Store API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality.”
   • [claimed-docs] “Obtaining a list of products to display that can be searched or filtered... Converting a customer’s cart to an Order, collecting addresses, …”

   proof ↗⚑ flag

   Swell—none0/10

   The evidence shows Swell's AI features target developers building on Swell (schema-introspection API for building resources, CLI tooling) rather than a documented agent-commerce endpoint (MCP/UCP) for external shopping agents to discover products or build carts. No mention of MCP, UCP, or a shopping-agent-facing commerce protocol appears anywhere in the pack, and probes for llms.txt/openapi discovery endpoints return 404.

   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialprobed5/10

   WooCommerce exposes a REST API (CRUD via JSON), a CLI (WC-CLI) for command-line store management, and a native MCP server for AI assistants — all of which could be scripted to perform bulk operations across many items — but no evidence explicitly documents batch/bulk endpoints or bulk-processing workflows for AI-native automation. missing for 10: explicit batch/bulk API endpoint documentation, evidence of MCP or CLI actually performing multi-item bulk actions, and any hands-on confirmation of bulk operation performance at scale.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”

   proof ↗⚑ flag

   Swell~partialclaimed4/10

   Swell supports bulk product import/export via CSV (swell-docs-14) and bulk stock tracking (swell-docs-15, swell-docs-28), which are bulk-style operations, but there is no evidence of an AI-native bulk API (e.g., batch create/update/delete endpoints) or agent-driven bulk automation across arbitrary item sets. Missing for 10: documented bulk REST/GraphQL endpoints, agent-callable batch operations, and evidence of scale/performance guarantees for bulk actions.

   • [claimed-docs] “Seamlessly import or export products from CSV files, including product categories.”
   • [claimed-docs] “Create unique product variations with unlimited options and attributes. Track inventory of each variant in real-time.”
   • [claimed-docs] “Stock adjustments are used to keep track of inventory changes over time.”

   proof ↗⚑ flag

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

   weight 3 · round to Swell
   WooCommerce~partialclaimed4/10

   WooCommerce documents webhooks that fire automatic event notifications to a URL when store events occur, which is a form of event-triggered automation, but there is no native in-product rules engine to define conditional actions (if X then Y) — the actual 'action' logic must live in an external receiver, not within WooCommerce itself. missing for 10: a built-in rules/automation engine for defining conditional actions, first-party workflow/automation tooling beyond webhooks, and independent confirmation of AI-driven rule creation.

   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “A webhook is an event notification sent to a URL of your choice. You (or your developer) can configure a webhook that is triggered by events…”

   proof ↗⚑ flag

   Swell~partialclaimed5/10

   Swell provides webhooks that subscribe to model lifecycle events and trigger calls to external services, plus serverless functions to run custom logic in response to those events, which together enable event-driven automation. However, there is no evidence of a dedicated no-code 'rules engine' or conditional trigger-action UI — automation requires writing webhook handlers/functions rather than defining declarative rules. Missing for 10: a visual/declarative rules builder, conditional logic beyond simple event subscription, and independent evidence of real-world automation use.

   • [claimed-docs] “Webhooks can be configured to call a URL when a particular event occurs, enabling outgoing calls to external services.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Data models can alter a store's database schema, either by adding fields to existing models (like products and orders) or creating completel…”
   • [claimed-docs] “Deploy serverless functions to customize logic and connect to external APIs.”
   • [claimed-docs] “Functions are deployed to edge data centers in 200+ locations and have no cold start time.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   WooCommerce—none0/10

   WooCommerce offers webhooks, REST API, subscriptions/renewals, and a CLI, but there is no evidence of a scheduler or job orchestration feature for recurring automated workflows in an AI-native sense; nothing in the docs describes cron-like job scheduling or workflow automation.

   ⚑ flag

   Swell—none0/10

   Swell is an e-commerce platform with webhooks, functions, and a CLI, but no evidence describes any scheduling capability for recurring jobs or workflows (cron-like triggers, scheduled functions, or workflow automation timers).

   ⚑ flag

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

   weight 1 · round drawn
   WooCommerce—none0/10

   The evidence pack shows WooCommerce's REST API, webhooks, and MCP server integration for AI assistants to interact with store data, but nothing about versioning, reviewing, or rolling back automations or workflows. There's no changelog, audit trail, or rollback mechanism described for any automation actions taken via MCP, API, or webhooks.

   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [claimed-docs] “A webhook is an event notification sent to a URL of your choice. You (or your developer) can configure a webhook that is triggered by events…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”

   proof ↗⚑ flag

   Swell—none0/10

   Swell is an e-commerce platform; there's no evidence of version control, review workflows, or rollback capability for automations/workflows—CLI push and app config exist but no versioning/review/rollback of automation logic is documented.

   ⚑ flag

B2b

1. merchantSell B2B and wholesale — customer-specific price lists, volume pricing, quotes or net-terms invoicing — alongside DTC

   weight 2 · round to Swell
   WooCommerce—none0/10

   The evidence pack has no mention of B2B-specific capabilities like customer-specific price lists, volume/tiered pricing, quote requests, or net-terms invoicing; only generic marketplace/extension mentions and general product variation features are cited, none of which address wholesale/B2B commerce specifically.

   ⚑ flag

   Swell~partialclaimed5/10

   Swell documents customer-group price rules for wholesale/VIP accounts, tiered-price breaks, and running wholesale and retail from a single catalog/dashboard, covering price-list and volume-pricing needs. However, there is no evidence of quote generation or net-terms invoicing functionality anywhere in the pack. missing for 10: quote workflows, net-terms invoicing support, independent/hands-on corroboration of B2B pricing in practice.

   • [claimed-docs] “Use price rules for specific customer groups like wholesale accounts/VIPs, and offer tiered-price breaks.”
   • [claimed-docs] “Run your wholesale and retail operations from a single catalog and dashboard.”
   • [claimed-docs] “Assign specific roles and permissions to team members for better control.”

   proof ↗⚑ flag

Catalog

1. merchantModel products with variants, options, and custom fields/metafields that fit my catalog, not a fixed template

   weight 3 · round to Swell
   WooCommerce~partialclaimed6/10

   WooCommerce docs confirm product variations/attributes (e.g., variable products with color/size attributes), subscriptions, bundles, and simple products with just name/price, plus recent 'variation galleries' improvements, supporting flexible catalog modeling. However, evidence lacks explicit mention of custom fields/metafields support (WooCommerce does support custom product meta natively via WordPress custom fields, but no doc here confirms this) or detail on how flexible/extensible attribute schemas are beyond basic variations. Missing for 10: explicit metafields/custom-fields documentation, evidence of unlimited custom attribute sets beyond simple variations, and independent/hands-on confirmation of complex catalog modeling in practice.

   • [claimed-docs] “Let customers choose from endless product variations, subscription options, single items, or bundles.”
   • [claimed-docs] “In WooCommerce, you can add a product with just a name and a price.”
   • [claimed-docs] “You’ll need to decide which categories to use for organizing and displaying your products... How will you handle products with variations, l…”
   • [claimed-docs] “How will you handle products with variations, like a shirt that comes in different colors? What attributes will you need for these products?”
   • [claimed-docs] “you can sell anything with Woo. Let customers choose from endless product variations, subscription options, single items, or bundles”
   • [claimed-docs] “you can sell anything with Woo. Let customers choose from endless product variations, subscription options, single items, or bundles.”
   • [claimed-docs] “Variation galleries now on for every store, product collection grids alignment improvements, virtual orders drop shipping…”
   • [claimed-docs] “WooCommerce 11.1 is here! Variation galleries now on for every store”
   • [claimed-docs] “WooCommerce 11.1 is here! Variation galleries now on for every store, product collection grids alignment improvements, virtual orders drop s…”

   proof ↗⚑ flag

   Swell✓fullclaimed9/10

   Strong first-party documentation covers variants/options, custom fields, and extensible data models, but lacks independent/hands-on corroboration. missing for 10: independent verification or hands-on demonstration of custom field/metafield modeling in practice.

   • [claimed-docs] “Create unique product variations with unlimited options and attributes. Track inventory of each variant in real-time.”
   • [claimed-docs] “Integrate business data and custom content with your catalog using custom models and fields.”
   • [claimed-docs] “Data models can alter a store's database schema, either by adding fields to existing models (like products and orders) or creating completel…”
   • [claimed-docs] “Add functionality to the dashboard and backend API with custom models.”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”

   proof ↗⚑ flag

Catalog ops

1. operations leadBulk import, export, and edit the catalog — CSV or API — without touching products one at a time

   weight 2 · round to Swell
   WooCommerce~partialprobed5/10

   WooCommerce's REST API (docs-11, docs-27, docs-44) supports bulk create/read/update/delete of product data via JSON, and WC-CLI (docs-13, probe-4) lets operations staff manage the store from the command line — both enabling bulk catalog operations without per-product UI clicks. However, the evidence pack never cites WooCommerce's native CSV product importer/exporter (a well-known core feature) or any documentation of CSV-based bulk edit workflows, so the 'CSV' half of the story is unevidenced here. Missing for 10: explicit CSV import/export documentation, evidence of bulk-edit UI/tools beyond API/CLI, and independent confirmation of large-catalog performance.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”

   proof ↗⚑ flag

   Swell~partialclaimed6/10

   Swell explicitly documents CSV import/export for products and categories, plus a full backend API (with official Node/PHP libraries) that could support bulk editing programmatically. However, there's no direct evidence of a bulk edit UI or batch-update API endpoint distinct from one-at-a-time product edits, and no independent/hands-on corroboration of CSV import/export reliability at scale. Missing for 10: documented bulk-edit UI or batch API endpoint, independent verification of CSV import/export at scale.

   • [claimed-docs] “Seamlessly import or export products from CSV files, including product categories.”
   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “authenticate with basic auth using your store ID as the username and a secret key as the password”

   proof ↗⚑ flag

Inventory

1. operations leadInventory tracks across multiple locations with stock adjustments and fulfillment from the right warehouse

   weight 2 · round to Swell
   WooCommerce—none0/10

   The evidence pack covers products, payments, shipping labels, taxes, APIs, and marketplace extensions, but contains no mention of multi-location/warehouse inventory tracking, per-location stock adjustments, or fulfillment routing logic. WooCommerce's core inventory model (docs-4, docs-23, docs-50) is single-stock-count per product/variation with no multi-warehouse concept documented.

   • [claimed-docs] “In WooCommerce, you can add a product with just a name and a price.”
   • [claimed-docs] “You’ll need to decide which categories to use for organizing and displaying your products... How will you handle products with variations, l…”
   • [claimed-docs] “How will you handle products with variations, like a shirt that comes in different colors? What attributes will you need for these products?”

   proof ↗⚑ flag

   Swell~partialclaimed5/10

   Swell documents stock adjustments (swell-docs-28) and real-time variant inventory tracking (swell-docs-15), but there is no explicit evidence of multi-location/multi-warehouse inventory tracking or location-based fulfillment routing. missing for 10: multi-location inventory data model, per-location stock levels, warehouse/location-based fulfillment routing logic, and any hands-on confirmation of these features.

   • [claimed-docs] “Stock adjustments are used to keep track of inventory changes over time.”
   • [claimed-docs] “Create unique product variations with unlimited options and attributes. Track inventory of each variant in real-time.”

   proof ↗⚑ flag

Checkout

1. developerCustomize checkout — fields, branding, discounts, and validation logic — through supported extension points rather than forking checkout

   weight 3 · round to WooCommerce
   WooCommerce~partialclaimed6/10

   WooCommerce documents a general hook system (add_action/filter extension points for templates) and a dedicated Store API for building customer-facing cart/checkout functionality, plus a REST API and marketplace of extensions, all of which support extending checkout without forking core code. However, the evidence pack lacks specifics on checkout-field-level hooks (e.g., field customization/validation filters), discount/coupon extension points, or branding customization guidance specific to checkout — missing for 10: checkout field customization hooks, discount/validation extension documentation, and independent developer corroboration that these extension points suffice for real-world checkout customization.

   • [claimed-docs] “The Store API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality.”
   • [claimed-docs] “Obtaining a list of products to display that can be searched or filtered... Converting a customer’s cart to an Order, collecting addresses, …”
   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “Storefront has a lot of `add_action()` functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core …”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “Grow your business with hundreds of free and paid extensions”

   proof ↗⚑ flag

   Swell~partialclaimed4/10

   Swell offers general extension mechanisms—serverless functions for custom logic, webhooks, custom models/fields, and Liquid theme customization—that could plausibly be applied to checkout, and cross-sell/upsell at checkout is mentioned, but there is no documentation specifically describing checkout page field customization, checkout branding controls, or checkout-specific validation hooks as a supported extension point. Missing for 10: explicit checkout page/field customization API or theme section, checkout-specific validation hook docs, discount/promo configuration tied to checkout flow, and any hands-on example of extending checkout without forking.

   • [claimed-docs] “Deploy serverless functions to customize logic and connect to external APIs.”
   • [claimed-docs] “Functions are deployed to edge data centers in 200+ locations and have no cold start time.”
   • [claimed-docs] “Integrate business data and custom content with your catalog using custom models and fields.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Add functionality to the dashboard and backend API with custom models.”
   • [claimed-docs] “Increase sales with cross-sells and upsells on product pages and at checkout.”
   • [claimed-docs] “Create themes using Liquid, with compatibility for Shopify theme tags, filters and objects, supported by our visual theme editor.”

   proof ↗⚑ flag

2. merchantBuyers can pay with accelerated wallets — Apple Pay, Google Pay, PayPal, platform one-click — without re-entering details

   weight 2 · round drawn
   WooCommerce~partialclaimed4/10

   Docs confirm WooCommerce integrates with 140 region-specific gateways including WooPayments, Stripe, PayPal, Square, and Amazon Pay, which in practice enable wallet-based accelerated checkouts, but no evidence explicitly names Apple Pay or Google Pay support or describes a one-click/no-re-entry checkout experience. missing for 10: explicit documentation of Apple Pay/Google Pay support, description of accelerated/one-click checkout UX, and any hands-on confirmation that details aren't re-entered.

   • [claimed-docs] “there are 140 region-specific gateways to choose from and integrate with, including WooPayments, Stripe, PayPal, Square, and Amazon Pay”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery... there are 140 region…”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery. Beyond the basics, the…”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery. Beyond the basics, the…”

   proof ↗⚑ flag

   Swell~partialclaimed4/10

   Changelog entries confirm Apple Pay support for subscriptions via Braintree and a PayPal gateway integration, showing some accelerated-wallet capability, but there's no evidence of Google Pay, platform one-click checkout, or broad (non-subscription) Apple Pay support at general checkout. missing for 10: Google Pay support, platform one-click checkout evidence, confirmation Apple Pay works for all order types (not just subscriptions), independent/hands-on verification of wallet checkout flow.

   • [claimed-docs] “Added Apple Pay support for subscriptions via Braintree.”
   • [claimed-docs] “Implemented PayPal gateway for direct card payments”

   proof ↗⚑ flag

Conversion

1. merchantAbandoned carts and checkouts trigger recovery emails or links so I can win the sale back

   weight 1 · round drawn
   WooCommerce—none0/10

   No evidence pack item mentions abandoned cart recovery, cart abandonment tracking, or automated recovery emails/links; core WooCommerce docs cover payments, shipping, taxes, APIs, and product management but nothing about cart-abandonment recovery workflows (this is typically only available via third-party plugins/extensions not evidenced here).

   ⚑ flag

   Swell—none0/10

   The evidence pack contains no mention of abandoned cart recovery, cart reminder emails, or checkout recovery links anywhere in Swell's documented features, changelog, or API docs; klaviyo and other marketing integrations are noted only for unrelated SMS opt-in.

   ⚑ flag

App dev

1. developerBuild custom apps and extensions with official SDKs, scaffolding tooling, and a documented review/distribution path

   weight 2 · round drawn
   WooCommerce~partialprobed6/10

   WooCommerce provides official developer resources: a REST API with official JS/PHP/Python/Ruby libraries, a WC-CLI tool, Storefront theme hook system, Storybook integration for UX development, and a public GitHub repo for building extensions, plus a Marketplace for distributing extensions (docs-11, docs-40, docs-13, docs-9, docs-55, woocommerce-gh-1, docs-10). However, there is no documented formal extension review/approval process or dedicated scaffolding/generator tool (e.g., a 'create-extension' CLI) beyond WC-CLI for store management, so the 'scaffolding' and 'review' parts of the story are only thinly evidenced. Missing for 10: explicit extension review/approval criteria, a dedicated project scaffolding generator, and independent developer corroboration of the distribution pipeline.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “The WooCommerce repository also includes Storybook integration that allows testing and developing in a WooCommerce-agnostic context.”
   • [github] “Once you've installed all prerequisites, the following will prepare all of the build outputs necessary for development”
   • [claimed-docs] “Grow your business with hundreds of free and paid extensions”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”

   proof ↗⚑ flag

   Swell~partialprobed6/10

   Swell provides a real developer toolkit: official Node/PHP SDKs, a CLI (`swell app init`, `push`) for scaffolding apps/themes, custom models/functions/webhooks for extending the platform, and theme distribution/upgrade/duplicate features tied to storefront apps like Proxima. However, evidence for a formal app review or marketplace submission/distribution process (beyond theme distribution) is thin, and probes show no discoverable OpenAPI/llms.txt for programmatic SDK generation. Missing for 10: explicit third-party app marketplace/review workflow, broader language SDK coverage, and independent verification of the CLI/SDK experience.

   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “swell app push: push configuration files to a development store”
   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “Data models can alter a store's database schema, either by adding fields to existing models (like products and orders) or creating completel…”
   • [claimed-docs] “Add functionality to the dashboard and backend API with custom models.”
   • [claimed-docs] “A storefront app, such as Proxima, may implement themes and thereby support the Swell Theme Editor as well as a number of storefront feature…”
   • [claimed-docs] “may implement themes and thereby support the Swell Theme Editor as well as a number of storefront features such as the ability to upgrade, d…”
   • [probe] “official CLI documented at https://developers.swell.is/apps/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

Apps

1. merchantExtend my store from a marketplace of vetted apps and extensions covering the long tail of features

   weight 3 · round to WooCommerce
   WooCommerce✓fullcommunity9/10

   WooCommerce's official marketplace explicitly offers 'hundreds of free and paid extensions' plus 140 region-specific payment gateways, covering long-tail feature needs, and this is corroborated by hands-on positive community sentiment. Missing for 10: independent third-party vetting/curation quality analysis and marketplace app review/rating transparency details.

   • [claimed-docs] “Grow your business with hundreds of free and paid extensions”
   • [claimed-docs] “The Woo Marketplace has hundreds of free and paid extensions that add features and functionality to your store”
   • [claimed-docs] “The Woo Marketplace has hundreds of free and paid extensions that add features and functionality to your store.”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery... there are 140 region…”
   • [community] “I have had a lot of fun using woo and I look forward to using it more.”

   proof ↗⚑ flag

   Swell~partialclaimed4/10

   Swell provides a developer framework for building apps/extensions (CLI, functions, webhooks, custom models, themes) and ships one official storefront app (Proxima), but the evidence never describes a merchant-facing marketplace of vetted third-party apps that a merchant can browse and one-click install to cover long-tail features. This story's core—a marketplace ecosystem for merchants—is only implied by the developer app-building tooling, not demonstrated. Missing for 10: evidence of an actual app marketplace/directory, listing of third-party vetted apps, and a merchant-facing install flow beyond the single first-party Proxima app.

   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “Proxima is Swell's first official storefront app intended to help merchants get started quickly by supporting compatibility with the well-kn…”
   • [claimed-docs] “Install once and your agent picks up the file contract, the CLI and the validate-deploy-verify loop.”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “A storefront app, such as Proxima, may implement themes and thereby support the Swell Theme Editor as well as a number of storefront feature…”
   • [claimed-docs] “may implement themes and thereby support the Swell Theme Editor as well as a number of storefront features such as the ability to upgrade, d…”

   proof ↗⚑ flag

Functions

1. developerInject custom backend logic — discounts, shipping rules, validation — as serverless functions or hooks that run inside the platform

   weight 2 · round to Swell
   WooCommerce~partialclaimed5/10

   WooCommerce's architecture is documented as extensible via PHP hooks (add_action/add_filter) that plugins/extensions use to insert custom logic into templates and core flows, and the Marketplace/extensions ecosystem confirms third-party logic can run inside the platform. However, the evidence pack only shows generic Storefront theme hooks and marketplace extension mentions — it does not document WooCommerce's core action/filter hooks specifically for discounts, shipping rules, or validation, nor any serverless/function-as-a-service execution model. Missing for 10: concrete documentation of cart/checkout/shipping filter hooks (e.g., woocommerce_calculate_totals, woocommerce_package_rates) or a serverless functions feature, and independent developer corroboration of using hooks for discount/shipping/validation logic.

   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “Storefront has a lot of `add_action()` functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core …”
   • [claimed-docs] “Storefront has a lot of add_action() functions ... These allow you to insert sections of content using HTML, PHP, Javascript into its core t…”
   • [claimed-docs] “Grow your business with hundreds of free and paid extensions”
   • [claimed-docs] “The Woo Marketplace has hundreds of free and paid extensions that add features and functionality to your store”

   proof ↗⚑ flag

   Swell✓fullclaimed8/10

   Swell explicitly supports deploying serverless 'functions' to customize logic and connect to external APIs, deployed at edge locations with no cold start, plus webhooks that subscribe to model events for custom validation/business logic, and custom models/data schema extension via the CLI/app framework — directly matching the story's discounts/shipping/validation-as-hooks use case. Missing for 10: no concrete first-party example of a discount/shipping-specific function, and no independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Deploy serverless functions to customize logic and connect to external APIs.”
   • [claimed-docs] “Functions are deployed to edge data centers in 200+ locations and have no cold start time.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Data models can alter a store's database schema, either by adding fields to existing models (like products and orders) or creating completel…”
   • [claimed-docs] “Add functionality to the dashboard and backend API with custom models.”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “Functions have no cold boots and do not require extra time to start up before executing your code.”

   proof ↗⚑ flag

Admin api

1. developerManage the full commerce lifecycle programmatically — create products, edit orders, issue refunds, trigger fulfillments — through the admin API

   weight 3 · round to WooCommerce
   WooCommerce✓fullprobed9/10

   WooCommerce's REST API (v3, versioned under /wp-json/wc/v3/) supports full CRUD on products, orders, and refunds via standard HTTP verbs and JSON, with official client libraries in multiple languages and role-based key scoping; docs explicitly cover refunds and order/fulfillment management, and webhooks allow event-driven triggering. Missing for 10: no independent/hands-on developer corroboration of complex workflows (e.g., fulfillment triggers) beyond vendor docs, and no published OpenAPI spec or deprecation policy for versioning.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [claimed-docs] “our Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing y…”
   • [claimed-docs] “Webhooks let your WooCommerce store send automatic event notifications to a URL of your choice.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.woocommerce.com/openapi.json, https://developer.woocommerce.com/swagger.json, http…”

   proof ↗⚑ flag

   Swell✓fullprobed7/10

   Docs confirm a backend API with authentication (secret keys), stock adjustments, purchase links, product purchase options, official Node/PHP client libraries, and admin/backend workflows covering products, orders, stock, and purchase configuration — indicating broad programmatic control of commerce entities. However, explicit admin-API endpoints for issuing refunds and triggering fulfillments are not directly cited, and no OpenAPI spec or independent hands-on test of order/refund/fulfillment flows is available (openapi probes 404). missing for 10: explicit refund/fulfillment endpoint documentation, OpenAPI reference, independent/hands-on verification of order-edit and refund calls.

   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “Keys are environment-specific: secret keys prefixed sk_test_ route requests to your store's test environment, while sk_live_ keys target liv…”
   • [claimed-docs] “Purchase links allow you to configure a pre-selected group of products within a cart and direct a customer to its checkout through a designa…”
   • [claimed-docs] “Products can support both purchase options simultaneously.”
   • [claimed-docs] “Stock adjustments are used to keep track of inventory changes over time.”
   • [claimed-docs] “authenticate with basic auth using your store ID as the username and a secret key as the password”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

Headless

1. developerBuild a fully custom headless storefront on a documented storefront API or first-party frontend framework

   weight 3 · round drawn
   WooCommerce✓fullprobed8/10

   WooCommerce documents both a full REST API (v3, with official JS/PHP/Python/Ruby libraries) and a dedicated Store API purpose-built for headless cart/checkout/product frontends, enabling a fully custom headless storefront to be built against documented, versioned endpoints. Missing for 10: no first-party official headless frontend framework/starter kit evidenced, and no independent hands-on report confirming a production headless build.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “The Store API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality.”
   • [claimed-docs] “Obtaining a list of products to display that can be searched or filtered... Converting a customer’s cart to an Order, collecting addresses, …”
   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.woocommerce.com/openapi.json, https://developer.woocommerce.com/swagger.json, http…”

   proof ↗⚑ flag

   Swell✓fullprobed8/10

   Swell provides a documented backend REST API with authentication, official Node/PHP libraries, and explicit support for building frontends 'with any framework,' plus a CLI and serverless functions for custom logic — all core pieces needed for a fully custom headless storefront (swell-docs-1,7,8,33,39). missing for 10: a discoverable OpenAPI/machine-readable spec (probe hits 404) and independent/hands-on developer corroboration beyond first-party docs.

   • [claimed-docs] “Build frontends for storefronts and admin workflows with any framework.”
   • [claimed-docs] “Deploy serverless functions to customize logic and connect to external APIs.”
   • [claimed-docs] “Official libraries for the Swell API are available for Node and PHP.”
   • [claimed-docs] “Keys are environment-specific: secret keys prefixed sk_test_ route requests to your store's test environment, while sk_live_ keys target liv…”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “authenticate with basic auth using your store ID as the username and a secret key as the password”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

Channels

1. merchantList and sync products to external channels — marketplaces, social commerce, shopping feeds — from one catalog

   weight 2 · round drawn
   WooCommerce—none0/10

   The evidence pack mentions a general extensions marketplace and REST/Store APIs, but nothing documents native or extension-based syncing of a single catalog to external marketplaces, social commerce channels, or shopping feeds (e.g., Google Shopping, Facebook/Instagram, Amazon). Missing for 10: any documentation of channel-sync extensions or feed integrations, evidence of catalog export/sync workflows, or hands-on confirmation of multi-channel listing.

   • [claimed-docs] “Grow your business with hundreds of free and paid extensions”
   • [claimed-docs] “The Woo Marketplace has hundreds of free and paid extensions that add features and functionality to your store”
   • [claimed-docs] “The Woo Marketplace has hundreds of free and paid extensions that add features and functionality to your store.”

   proof ↗⚑ flag

   Swell—none0/10

   Swell's evidence covers catalog management, CSV import/export, custom models, and webhooks/APIs for building integrations, but there is no mention of built-in or official connectors for marketplaces (Amazon, eBay), social commerce (Instagram/Facebook Shop), or shopping feeds (Google Shopping). Webhooks and APIs could theoretically be used to build such sync, but no evidence shows this capability shipped or documented as a channel-sync feature.

   • [claimed-docs] “Seamlessly import or export products from CSV files, including product categories.”
   • [claimed-docs] “Webhooks enable real-time communication between the Swell platform and external services, by subscribing to any number of model events.”
   • [claimed-docs] “Webhooks can be configured to call a URL when a particular event occurs, enabling outgoing calls to external services.”

   proof ↗⚑ flag

Global

1. merchantSell internationally with localized storefronts, multi-currency pricing, translations, and duties handled

   weight 2 · round to Swell
   WooCommerce—none0/10

   The evidence pack shows tax setup, shipping, and payment gateway docs, but contains no mention of multi-currency pricing, localized/translated storefronts, or international duties/customs handling — the core elements of this story are absent. This is a fair question for an e-commerce platform (many competitors ship native multi-currency/localization), so it applies, but no supporting evidence exists.

   ⚑ flag

   Swell~partialclaimed5/10

   Swell docs claim multi-language content and dynamic currency conversion with local-currency pricing via supported gateways (swell-docs-43), which covers localized storefronts and multi-currency/translation aspects of the story. However, there is no evidence addressing duties, customs, or cross-border tax handling, and no independent corroboration of the localization features in practice. Missing for 10: duties/customs handling, cross-border tax automation, hands-on/independent verification of translation and currency features.

   • [claimed-docs] “Localize your stores with multiple content languages and dynamic currency conversion, plus pricing in local currencies with supported paymen…”

   proof ↗⚑ flag

Pos

1. merchantSell in person with a point-of-sale that shares the same catalog, inventory, and customers as my online store

   weight 2 · round drawn
   WooCommerce—none0/10

   The evidence pack contains no mention of a point-of-sale product, in-person selling, or POS-catalog sync capability for WooCommerce; all evidence covers online store features (payments, shipping, taxes, APIs, mobile app for managing the online store). This is a fair axis for an ecommerce platform, but no evidence shows WooCommerce delivers it, so it is 'none' rather than 'na'.

   ⚑ flag

   Swell—none0/10

   No evidence pack item mentions a point-of-sale (POS) product, in-person selling, or a POS syncing with online catalog/inventory/customers; only wholesale/retail catalog unification (swell-docs-30) is mentioned, which is not POS. The axis is applicable since e-commerce platforms commonly offer POS integrations, but no evidence shows Swell delivers this.

   ⚑ flag

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

   weight 2 · round drawn
   WooCommerce~partialprobed7/10

   WooCommerce documents a broad, versioned REST API (products, orders, customers, refunds, webhooks, coupons), a separate Store API for cart/checkout, an official WC-CLI, and even native MCP support for AI agents — strong evidence of API-driven parity with the UI. However, the docs don't confirm 1:1 coverage for every admin UI action (e.g., full store-setup wizard, extension marketplace management, granular tax/shipping configuration screens), and there's no independent hands-on test confirming complete UI/API parity. Missing for 10: explicit documentation or independent verification that every admin-UI setting/workflow (not just core commerce objects) is exposed via API, and confirmation of parity for extension-specific UI features.

   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “The Store API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality.”
   • [claimed-docs] “WooCommerce CLI (WC-CLI) offers an efficient way to manage WooCommerce (WC) stores via the command line.”
   • [claimed-docs] “WooCommerce includes native support for the Model Context Protocol (MCP), enabling AI assistants and tools to interact directly with WooComm…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “Official libraries: JavaScript Library, PHP Library, Python Library, Ruby Library”
   • [claimed-docs] “Use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities. Choose the level of access for thi…”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”
   • [probe] “official MCP server documented at https://developer.woocommerce.com/docs/features/mcp/”
   • [probe] “official CLI documented at https://developer.woocommerce.com/docs/category/wc-cli/”

   proof ↗⚑ flag

   Swell~partialprobed7/10

   Swell is headless-commerce with a backend API, custom-model/schema introspection, webhooks and CLI, and docs explicitly state you can 'build frontends for storefronts and admin workflows with any framework,' implying API parity for admin-side tasks. However there's no explicit UI-to-API parity guarantee, no OpenAPI spec (404 on probes), and no independent confirmation that every UI action (e.g., theme editing, reporting) has an API equivalent. Missing for 10: explicit parity documentation, discoverable OpenAPI/schema spec, and third-party confirmation that all admin UI actions are API-accessible.

   • [claimed-docs] “Build frontends for storefronts and admin workflows with any framework.”
   • [claimed-docs] “One call returns a store’s whole schema at runtime: every model—standard, merchant custom and app-installed alike—with field types and relat…”
   • [claimed-docs] “Data models can alter a store's database schema, either by adding fields to existing models (like products and orders) or creating completel…”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

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

   weight 3 · round to WooCommerce
   WooCommerce~partialclaimed6/10

   WooCommerce is self-hosted and open-source, with explicit messaging about 'full control of your data' and a REST API (JSON, versioned, documented) that allows programmatic export of products, orders, and customer data. However, evidence shows migration guides only for moving data *into* WooCommerce, not exporting/leaving, and no explicit CSV/data-portability export tool or 'leave the platform' guide is documented. Missing for 10: explicit data-export/portability documentation for leaving the platform, evidence of built-in CSV/data dump tools, and independent confirmation that a full data export actually works in open non-proprietary formats.

   • [claimed-docs] “WooCommerce is the open-source commerce platform for WordPress that gives you full control: of your checkout, your data, your costs.”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “This allows WC data to be created, read, updated, and deleted using requests in JSON format and using WordPress REST API Authentication meth…”
   • [claimed-docs] “WooCommerce (WC) 2.6+ is fully integrated with the WordPress REST API. This allows WC data to be created, read, updated, and deleted using r…”
   • [claimed-docs] “Ready to switch platforms? Our migration guides help you confidently move your store to WooCommerce... transfer your data, and unlock the fl…”
   • [claimed-docs] “Ready to switch platforms? Our migration guides help you confidently move your store to WooCommerce.”
   • [claimed-docs] “WooCommerce REST API Documentation - WP REST API v3 — all endpoints are versioned under the /wp-json/wc/v3/ prefix (e.g. GET /wp-json/wc/v3/…”

   proof ↗⚑ flag

   Swell~partialclaimed3/10

   Swell only documents CSV import/export for products and categories, not a comprehensive open-format export of all store data (orders, customers, custom models, etc.), and there's no documented full data-portability or account-closure export mechanism. Missing for 10: evidence of full-store data export (all models/entities) in open formats, a documented data portability/export-all endpoint, and any confirmation that a merchant can fully migrate away with all their data.

   • [claimed-docs] “Seamlessly import or export products from CSV files, including product categories.”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce✓fullclaimed9/10

   WooCommerce is explicitly open-source (GPL-licensed WordPress plugin) with its source publicly hosted on GitHub, and its own site states it 'gives you full control: of your checkout, your data, your costs' as an open-source commerce platform. missing for 10: no explicit citation of the license file/terms text itself, only general open-source claims and the GitHub repo link.

   • [claimed-docs] “WooCommerce is the open-source commerce platform for WordPress that gives you full control: of your checkout, your data, your costs.”
   • [github] “Once you've installed all prerequisites, the following will prepare all of the build outputs necessary for development”

   proof ↗⚑ flag

   Swell—none0/10

   Swell is a closed commercial SaaS platform; no evidence of any open-source license or public source repository is present in the evidence pack, and probes for open API/spec artifacts returned 404s.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.swell.is/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.swell.is/openapi.json, https://developers.swell.is/swagger.json, https://develope…”

   proof ↗⚑ flag

Processing

1. merchantChoose among third-party payment gateways and charge in multiple currencies when the built-in option doesn't fit

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed6/10

   Docs confirm WooCommerce bundles basic payment methods (cards, BACS, checks, COD) plus access to 140 region-specific third-party gateways (WooPayments, Stripe, PayPal, Square, Amazon Pay), showing strong third-party gateway choice. However, evidence does not explicitly document multi-currency charging/checkout support (this typically requires separate extensions), so the 'charge in multiple currencies' half of the story is unevidenced. Missing for 10: explicit multi-currency checkout/gateway documentation, independent/hands-on confirmation of gateway switching working smoothly.

   • [claimed-docs] “there are 140 region-specific gateways to choose from and integrate with, including WooPayments, Stripe, PayPal, Square, and Amazon Pay”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery... there are 140 region…”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery. Beyond the basics, the…”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery. Beyond the basics, the…”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery.”

   proof ↗⚑ flag

   Swell~partialclaimed5/10

   Evidence shows multiple third-party gateway integrations (PayPal, Braintree/Apple Pay) and multi-currency support via dynamic conversion and localized pricing with supported payment gateways, indicating merchants can use alternate gateways and multi-currency pricing. However, there's no evidence of a general gateway marketplace/plugin system letting merchants freely choose among many third-party gateways, nor detail on how currency charging interacts with each gateway. Missing for 10: comprehensive list/marketplace of supported gateways, clarity on which gateways support multi-currency charging, and independent confirmation of ease of switching gateways.

   • [claimed-docs] “Added Apple Pay support for subscriptions via Braintree.”
   • [claimed-docs] “Implemented PayPal gateway for direct card payments”
   • [claimed-docs] “Localize your stores with multiple content languages and dynamic currency conversion, plus pricing in local currencies with supported paymen…”

   proof ↗⚑ flag

2. merchantTake payments with the platform's integrated processing — published card rates, payouts, and fraud tooling — without wiring a third-party gateway

   weight 3 · round to WooCommerce
   WooCommerce~partialclaimed5/10

   WooPayments is documented as Woo's own integrated payment solution with transaction listing, payouts, and refunds handled directly in the dashboard (woocommerce-docs-5/24/37/43/52), which supports the 'no third-party gateway' framing. However, the evidence never publishes concrete card processing rates or documents dedicated fraud-prevention/chargeback tooling — the docs only gesture at 'managing money' generally, and WooCommerce's broader payments story explicitly leans on 140 external gateways (docs-1/18/41/47) rather than emphasizing WooPayments exclusivity. Missing for 10: published card rate sheet, explicit fraud/dispute tooling documentation, and confirmation WooPayments avoids third-party processor plumbing entirely.

   • [claimed-docs] “This includes topics such as listing transactions, viewing your payouts, issuing refunds to customers, and so on.”
   • [claimed-docs] “our Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing y…”
   • [claimed-docs] “our Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing y…”
   • [claimed-docs] “Managing Money guide explains how money can flow into and out of your site. This includes topics such as listing transactions, viewing your …”
   • [claimed-docs] “Once WooPayments is up and running, our Managing Money guide explains how money can flow into and out of your site.”
   • [claimed-docs] “there are 140 region-specific gateways to choose from and integrate with, including WooPayments, Stripe, PayPal, Square, and Amazon Pay”
   • [claimed-docs] “Woo comes bundled with the ability to accept major credit cards, bank transfers (BACS), checks, and cash on delivery... there are 140 region…”

   proof ↗⚑ flag

   Swell—none0/10

   Evidence shows Swell relies on third-party gateways (PayPal, Braintree) for payment processing rather than offering its own integrated processing with published card rates, payouts, or fraud tooling. No mention of native rates, payout schedules, or fraud tools is present anywhere in the evidence pack.

   • [claimed-docs] “Added Apple Pay support for subscriptions via Braintree.”
   • [claimed-docs] “Implemented PayPal gateway for direct card payments”

   proof ↗⚑ flag

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

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed4/10

   WooCommerce is self-hosted on WordPress, so by nature the store owner controls the hosting infrastructure and therefore the physical location of data — docs-16 states WooCommerce gives 'full control of your data.' However, there is no explicit first-party documentation of region-selection controls, data-residency settings, or compliance tooling addressing where data is stored. missing for 10: explicit data-residency/region-selection documentation, compliance certifications (e.g., GDPR data location controls), and any admin-facing region config feature.

   • [claimed-docs] “WooCommerce is the open-source commerce platform for WordPress that gives you full control: of your checkout, your data, your costs.”

   proof ↗⚑ flag

   Swell—none0/10

   No evidence in the pack mentions data residency, region selection, or hosting location choices for stores or data; Swell's docs focus on functions, themes, CLI, and commerce features without addressing data storage location controls.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   WooCommerce—none0/10

   No evidence pack items address data retention policies, deletion controls, GDPR-style export/erasure tools, or AI-specific data lifecycle controls; REST API docs describe generic CRUD capability but not a data retention/deletion governance feature. This axis applies to an e-commerce platform handling customer PII, but no documentation demonstrates such controls.

   ⚑ flag

   Swell—none0/10

   Swell is an e-commerce platform; the evidence pack covers catalog, storefront, apps, and API features but contains no mention of data retention policies, deletion controls, or privacy/data-lifecycle management for AI-native users or otherwise. No evidence exists to support this axis being delivered.

   ⚑ flag

Content

1. merchantManage content — pages, blogs, media — alongside my products from the same admin

   weight 1 · round to WooCommerce
   WooCommerce~partialclaimed5/10

   WooCommerce is built as a plugin on top of WordPress, and docs confirm this tight integration ("open-source commerce platform for WordPress," "If you have a WordPress site, adding Woo takes just minutes"), which implies the WordPress admin (with its native Pages, Posts/blog, and Media Library) is shared with product management. Storefront theme docs also show content can be inserted into store templates via hooks. However, no evidence explicitly describes a unified admin workflow for managing blog posts, pages, and media alongside products, or shows this in a hands-on merchant walkthrough. Missing for 10: explicit documentation or screenshots of managing WordPress pages/posts/media from the same dashboard as products, and independent confirmation of this workflow.

   • [claimed-docs] “WooCommerce is the open-source commerce platform for WordPress that gives you full control: of your checkout, your data, your costs.”
   • [claimed-docs] “If you have a WordPress site, adding Woo takes just minutes!”
   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “Storefront has a lot of `add_action()` functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core …”

   proof ↗⚑ flag

   Swell—none0/10

   The evidence pack shows Swell's admin covers products, categories, pricing, inventory, subscriptions, and custom data models, but there is no mention of built-in pages, blog, or media management features in the admin UI — only vague 'custom content' via custom models (swell-docs-19), which is not the same as a CMS/blog/media library. No documentation of pages, blogs, or media assets being managed alongside products.

   ⚑ flag

Theme dev

1. developerCustomize storefront code with a documented templating layer, local preview, and version-controlled theme deploys

   weight 2 · round to Swell
   WooCommerce~partialclaimed6/10

   WooCommerce/Storefront documents a genuine templating layer (add_action hooks for HTML/PHP/JS insertion into core templates) and the GitHub repo shows a local build process plus Storybook integration for developing/testing in isolation, giving developers a documented customization and local-preview path. However there is no explicit documentation of a version-controlled theme deployment workflow (e.g., CI/CD, staging-to-production theme push) — that relies on generic WordPress/Git practices not directly evidenced here. Missing for 10: documented deployment/versioning workflow for themes, explicit local preview tooling beyond Storybook, end-to-end example of a version-controlled theme release.

   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “Storefront has a lot of `add_action()` functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core …”
   • [claimed-docs] “Storefront has a lot of add_action() functions ... These allow you to insert sections of content using HTML, PHP, Javascript into its core t…”
   • [claimed-docs] “The WooCommerce repository also includes Storybook integration that allows testing and developing in a WooCommerce-agnostic context.”
   • [github] “Once you've installed all prerequisites, the following will prepare all of the build outputs necessary for development”
   • [claimed-docs] “WooCommerce introduces Purple, its first official block theme for beta testing, offering extensive customization options and modern template…”

   proof ↗⚑ flag

   Swell~partialclaimed7/10

   Swell documents a Liquid-based templating layer with Shopify-theme compatibility and a visual theme editor, plus a CLI (`swell app init`, `swell app push`) for creating apps/themes and pushing configs to a development store, which supports a deploy workflow. However there's no explicit mention of a local preview server or git-based version-controlled deploy pipeline beyond pushing to a dev store. missing for 10: explicit local preview/dev-server tooling, explicit version-control (git) integration for theme deploys, independent/hands-on confirmation of the workflow.

   • [claimed-docs] “Create themes using Liquid, with compatibility for Shopify theme tags, filters and objects, supported by our visual theme editor.”
   • [claimed-docs] “Proxima is Swell's first official storefront app intended to help merchants get started quickly by supporting compatibility with the well-kn…”
   • [claimed-docs] “Swell CLI is a command-line interface that helps you create and work with apps, themes, and storefronts.”
   • [claimed-docs] “swell app init: initialize an app in the current directory with a default config file and folder structure”
   • [claimed-docs] “swell app push: push configuration files to a development store”
   • [claimed-docs] “A storefront app, such as Proxima, may implement themes and thereby support the Swell Theme Editor as well as a number of storefront feature…”

   proof ↗⚑ flag

Themes

1. merchantLaunch a polished storefront from professionally designed themes and customize layout, sections, and branding without code

   weight 3 · round drawn
   WooCommerce~partialclaimed5/10

   WooCommerce offers designed themes (Storefront, and the new block theme 'Purple' with 'extensive customization options and modern templates') and initial setup guidance around homepage design, menus, and site structure, suggesting a storefront can be launched and styled. However, the core documented customization mechanism for Storefront explicitly requires inserting HTML/PHP/JavaScript via add_action() hooks, which is code-based rather than no-code, and evidence for genuine no-code block-editor customization (drag-and-drop sections, branding controls) is thin and limited to a single beta announcement. Missing for 10: detailed no-code section/layout editor documentation, evidence of drag-and-drop branding tools, and independent hands-on confirmation that non-developers can fully customize without code.

   • [claimed-docs] “Storefront has a lot of add_action() functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core te…”
   • [claimed-docs] “Storefront has a lot of `add_action()` functions... These allow you to insert sections of content using HTML, PHP, Javascript into its core …”
   • [claimed-docs] “Storefront has a lot of add_action() functions ... These allow you to insert sections of content using HTML, PHP, Javascript into its core t…”
   • [claimed-docs] “WooCommerce introduces Purple, its first official block theme for beta testing, offering extensive customization options and modern template…”
   • [claimed-docs] “The first decisions you need to make when setting up a store are about homepage design, menus, site structure... If you have a WordPress sit…”
   • [claimed-docs] “The first decisions you need to make when setting up a store are about homepage design, menus, site structure, and payment and shipping opti…”

   proof ↗⚑ flag

   Swell~partialclaimed5/10

   Swell offers a visual theme editor and Liquid-based themes compatible with Shopify Online Store 2.0 structure, plus a first-party storefront app (Proxima) meant to help merchants get started quickly and customize look/feel, along with no-code drag-and-drop category management. However, the bulk of Swell's documentation frames storefronts as developer-built (custom frontends, CLI, JSON model files, functions), suggesting the 'no-code for merchants' experience is thinner than the theme-editor claim implies, and there's no evidence of a marketplace of multiple professionally designed themes beyond Proxima. Missing for 10: evidence of a broader theme marketplace, hands-on/independent proof the visual editor supports full no-code section/layout customization, and clarity on how much coding is truly unnecessary for typical merchants.

   • [claimed-docs] “Create themes using Liquid, with compatibility for Shopify theme tags, filters and objects, supported by our visual theme editor.”
   • [claimed-docs] “Themes are optionally implemented by storefront apps to make it easier for merchants to customize the look and feel of their store.”
   • [claimed-docs] “Design category trees to help your customers find products. Manage it all with simple drag-and-drop.”
   • [claimed-docs] “Proxima is Swell's first official storefront app intended to help merchants get started quickly by supporting compatibility with the well-kn…”
   • [claimed-docs] “A storefront app, such as Proxima, may implement themes and thereby support the Swell Theme Editor as well as a number of storefront feature…”
   • [claimed-docs] “may implement themes and thereby support the Swell Theme Editor as well as a number of storefront features such as the ability to upgrade, d…”

   proof ↗⚑ flag

Shipping

1. operations leadCheckout shows live carrier rates and I can buy labels and track shipments from the platform

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed5/10

   WooCommerce marketing docs claim 'live shipping rates from leading carriers' and 'options to print labels at home' bundled with the platform, but the shipping doc itself only discusses label cost verification, not a live-rate/checkout integration or tracking dashboard, and label printing/live rates in practice typically require third-party extensions (e.g., WooCommerce Shipping) not detailed here. Missing for 10: concrete documentation of the checkout carrier-rate integration flow, label purchase workflow details, and shipment tracking UI, plus independent/hands-on confirmation this works out-of-the-box.

   • [claimed-docs] “Save time with automated tax calculations, live shipping rates from leading carriers, options to print labels at home”
   • [claimed-docs] “Save time with automated tax calculations, live shipping rates from leading carriers, options to print labels at home, and the mobile app fo…”
   • [claimed-docs] “options to print labels at home, and the mobile app for iOS and Android”
   • [claimed-docs] “Carriers verify shipment information during the delivery process and compare the cost paid for the shipping label to the actual cost to ship…”
   • [claimed-docs] “If the amount paid for the label is incorrect, it can result in an adjustment.”

   proof ↗⚑ flag

   Swell—none0/10

   No evidence of live carrier rate shopping, label purchasing, or shipment tracking integrations anywhere in the evidence pack; only stock adjustments and general inventory tracking are mentioned, which is unrelated to shipping/carrier functionality.

   ⚑ flag

Taxes

1. merchantSales tax and VAT are calculated automatically per jurisdiction, with rates kept current and reports I can file from

   weight 2 · round to WooCommerce
   WooCommerce~partialclaimed4/10

   WooCommerce docs mention 'automated tax calculations' as a marketing feature and a core guide for enabling/configuring taxes and adding tax rates, but the evidence pack shows only manual tax-rate table setup, not per-jurisdiction automatic rate updates, VAT-specific handling, or built-in filing-ready tax reports. Missing for 10: evidence of automatic jurisdiction rate updates (e.g. via a tax service integration), VAT-specific compliance handling, and generation of filing-ready tax reports.

   • [claimed-docs] “This guide explains how to enable and configure taxes in WooCommerce, add tax rates, and understand each available setting.”
   • [claimed-docs] “Save time with automated tax calculations, live shipping rates from leading carriers, options to print labels at home”
   • [claimed-docs] “Save time with automated tax calculations, live shipping rates from leading carriers, options to print labels at home, and the mobile app fo…”

   proof ↗⚑ flag

   Swell—none0/10

   No evidence in the pack mentions automatic sales tax or VAT calculation, jurisdiction-based rate updates, or tax filing/reporting; the pack only covers themes, apps, CLI, catalog, and dev tooling.

   ⚑ flag