Medusa vs Swell

Agent access

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

   weight 2 · round to Medusa
   Medusa✓fullprobed9/10

   Medusa has a verified live llms.txt file (HTTP 200) describing the platform for AI agents, plus a documented official MCP server for querying docs directly from AI tools/IDEs like Cursor, confirming agent-oriented documentation access is a first-class supported pathway. Missing for 10: independent third-party confirmation of agents successfully using llms.txt in practice beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.medusajs.com/llms.txt # Medusa > Medusa is a digital commerce platform with a built-in Framework f…”
   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”

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

   Medusa is explicitly described as a headless commerce platform with an installable open-source npm package and CLI (medusa-comm-3, medusa-gh-2, medusa-probe-4, medusa-docs-29), and cloud tooling references PR previews and background workers suggesting CI/automation support (medusa-docs-11, medusa-docs-30). However there is no explicit documentation of running Medusa in a CI pipeline or automated test/build scripts, and community notes flag unresolved serverless/background-job execution concerns (medusa-comm-2). Missing for 10: dedicated CI/automation guide, evidence of headless test execution, and independent confirmation of serverless/CI deployment working smoothly.

   • [community] “I love the idea of a headless ecommerce platform, especially one that comes with a nice backend GUI for managing inventory. Pleasantly surpr…”
   • [github] “Medusa's core commerce modules are open-source and freely available on npm.”
   • [probe] “official CLI documented at https://docs.medusajs.com/resources/medusa-cli”
   • [claimed-docs] “Medusa MCP and Cloud CLI”
   • [claimed-docs] “Instant previews on PRs”
   • [claimed-docs] “Background workers”
   • [community] “Haven't investigated deploying Medusa to a serverless environment yet. We use background workers to process jobs from a Bull queue that may …”

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

   The evidence only shows Medusa hosting an MCP server (docs.medusajs.com/mcp) that external AI tools like Cursor can connect to for documentation lookup — this is Medusa acting as an MCP server provider, not evidence that Medusa itself can consume/plug in external MCP servers to use their tools. No documentation or community evidence describes Medusa (or its Cloud Development Agent) connecting to external MCP servers as a client.

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”
   • [claimed-docs] “Cloud Development Agent”

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

   Medusa officially hosts a Streamable HTTP MCP server at docs.medusajs.com/mcp that can be added to MCP-compatible AI agents/tools like Cursor, confirmed by both docs and an independent probe. Missing for 10: independent hands-on report of connecting an agent to it and details on tool/resource coverage beyond documentation lookup.

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”

   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 Swell
   Medusa✓fullprobed6/10

   Medusa ships an official CLI (documented at docs.medusajs.com/resources/medusa-cli) and a separate Cloud CLI referenced in pricing, giving developers and agentic tooling a scriptable interface to manage Medusa projects. Missing for 10: detailed command reference/usage examples, evidence of AI-agent-specific CLI features (e.g., non-interactive/JSON output modes), and independent hands-on confirmation of the CLI beyond doc links.

   • [probe] “official CLI documented at https://docs.medusajs.com/resources/medusa-cli”
   • [claimed-docs] “Medusa MCP and Cloud CLI”

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

   Medusa maintains a full OpenAPI 3.0 spec for its Store and Admin REST APIs (medusa-gh-x1), which powers extensive public documentation for commerce modules (product, cart, order, payment, tax, fulfillment, inventory, sales channel), giving AI-native users a documented, machine-readable API surface to drive the platform programmatically. Missing for 10: independent hands-on confirmation of API usability, and standard discovery endpoints (openapi.json/swagger.json) 404 at the docs root per probe, meaning the spec is only reachable via GitHub rather than a conventional self-describing endpoint.

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [claimed-docs] “Product Module - Medusa Documentation”
   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Order Module - Medusa Documentation”
   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [claimed-docs] “Tax Module - Medusa Documentation”
   • [claimed-docs] “Fulfillment Module - Medusa Documentation”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

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

   Evidence shows only generic RBAC/SSO/Audit Logs mentions in pricing tiers, with no documentation of issuing scoped or least-privilege API credentials specifically for AI agents, nor any agent-specific token/key scoping mechanism.

   • [claimed-docs] “RBAC, SSO, Audit Logs”

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

   The evidence pack shows Medusa exposes a machine-readable OpenAPI 3.0 spec and various module docs, plus an MCP server and CLI for AI tooling, but there is no citation of an official client SDK (e.g., a maintained JS/TypeScript SDK package) that an AI-native developer could build against. missing for 10: explicit official SDK documentation/package reference, examples of SDK usage, language coverage beyond REST spec.

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

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

   Medusa's pricing page lists 'Webhook Events' as a feature, indicating webhook-based event subscription exists, but no documentation details the subscription mechanism, event catalog, or setup process, and no independent/hands-on confirmation is present. Missing for 10: detailed webhook docs, event type catalog, hands-on verification, independent corroboration.

   • [claimed-docs] “Webhook 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
   Medusa—none0/10

   Evidence only shows an MCP server for querying Medusa's documentation (medusa-docs-4, medusa-docs-33/37) and generic 'guardrails for agents to build customizations' marketing copy — nothing shows Medusa surfacing AI-generated insights or suggestions derived from a merchant's own commerce data (orders, inventory, sales trends). missing for 10: any feature generating insights/recommendations from store data, admin dashboard AI analytics, or product evidence of in-app AI suggestions.

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”

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

   The pricing/docs evidence mentions 'Background workers' and 'Webhook Events' as platform features that could underpin autonomous background automations, and a 'Cloud Development Agent' is referenced, but none of the evidence describes an actual workflow/scheduler/automation-builder interface an AI-native user would configure. Missing for 10: documented workflow/scheduled-job engine, concrete setup instructions for autonomous background automations, and independent confirmation these run unattended.

   • [claimed-docs] “Background workers”
   • [claimed-docs] “Webhook Events”
   • [claimed-docs] “Cloud Development Agent”

   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 to Medusa
   Medusa~partialclaimed2/10

   Medusa's pricing page lists a 'Cloud Development Agent' as an enterprise feature, hinting at some built-in AI assistant capability, but there's no documentation describing what it does, how a user delegates tasks to it, or how it's used within the product UI. The rest of the AI-related evidence (MCP server, 'guardrails for agents') is about external AI coding agents building customizations or IDE tools connecting to docs, not a built-in in-product assistant for end users. Missing for 10: documentation/screenshots of the Cloud Development Agent's actual task-delegation workflow, independent/hands-on confirmation it exists and works, and clarity on how it differs from the developer-facing MCP/CLI tooling.

   • [claimed-docs] “Cloud Development Agent”
   • [claimed-docs] “Medusa MCP and Cloud CLI”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”
   • [claimed-docs] “Guardrails for agents to build customizations.”

   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 Medusa
   Medusa~partialprobed4/10

   Medusa exposes an official MCP server, but it is scoped to searching documentation for AI tools/IDEs, not to operating the commerce platform itself (products, orders, carts) via natural language. Marketing mentions of a 'Cloud Development Agent' and 'guardrails for agents to build customizations' hint at broader agentic operation but are never elaborated with concrete NL-command examples or independent corroboration. Missing for 10: evidence of natural-language commands actually driving store/admin operations, hands-on examples of agentic customization via the guardrails feature, and independent confirmation of the Cloud Development Agent's capabilities.

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [claimed-docs] “Cloud Development Agent”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”
   • [claimed-docs] “Medusa MCP and Cloud CLI”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”

   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 to Medusa
   Medusa~partialprobed5/10

   Medusa maintains full OpenAPI 3.0 specs for its Store/Admin REST APIs that power a hosted docs.medusajs.com/api reference, indicating a structured, machine-readable API reference exists, but the evidence pack has no confirmation of 'try it out' style runnable request execution in that reference, and a direct openapi.json endpoint probe returned 404s. missing for 10: explicit documentation/screenshot of an interactive 'run this request' feature in the API reference, independent confirmation of a Swagger/Redoc-style try-it-out UI.

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

   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 to Medusa
   Medusa~partialprobed7/10

   Medusa maintains a full OpenAPI 3.0 spec for its Store and Admin REST APIs in the medusajs/medusa GitHub repo, which powers docs.medusajs.com/api and is directly downloadable as a raw YAML file (medusa-gh-x1). However, a runtime probe found no discoverable/conventional endpoint like openapi.json or swagger.json on the docs domain itself (medusa-probe-2), meaning users must know to fetch it from GitHub rather than a standard machine-readable discovery path. Missing for 10: a documented, directly-linked download endpoint on the docs site itself, and confirmation the spec is kept in sync/versioned for consumers outside the repo.

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

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

   While Medusa's self-hosted architecture and 'Instant previews on PRs' (medusa-docs-11) suggest general dev/staging capabilities, there is no evidence of a dedicated sandbox environment specifically for AI-native testing against non-production data (e.g., a test mode for the MCP server or API keys scoped to sandbox data). missing for 10: explicit sandbox/test environment documentation, AI-agent-specific test mode, isolation guarantees separating sandbox from production data.

   • [claimed-docs] “Instant previews on PRs”
   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”

   proof ↗⚑ 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 drawn
   Medusa—none0/10

   There's an OpenAPI spec for the Store/Admin APIs, but no evidence of API versioning scheme or a documented deprecation policy anywhere in the docs; probe for openapi.json even 404s at the docs root. Missing for 10: any mention of API version numbers, changelog of breaking changes, or a stated deprecation/support timeline.

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

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

   Evidence shows Medusa's MCP server only exposes its own developer documentation to AI tools like Cursor (medusa-docs-4, medusa-docs-33/37, medusa-probe-3), not merchant product catalogs. There is no evidence of a cross-merchant catalog, agent-facing product feed, or discoverability mechanism for storefront products by AI agents/answer engines — the OpenAPI probe for a public product feed also failed (medusa-probe-2).

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”

   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 Medusa
   Medusa~partialcommunity5/10

   Medusa documents dedicated Order, Fulfillment, and Payment modules and publishes a machine-readable OpenAPI 3.0 spec for its Store/Admin REST APIs (medusa-docs-23, medusa-docs-26, medusa-gh-x1), and a community comment confirms built-in returns/exchange ('swap') handling (medusa-comm-10) — together suggesting an agent could programmatically track and update post-purchase order states. However, the pack has no explicit documentation of a returns/RMA API endpoint, no concrete webhook payload/event schema (Webhook Events appears only as a Cloud pricing bullet, medusa-docs-16), and no example flow showing an agent completing status→fulfillment→return without touching the admin UI. Missing for 10: explicit returns/RMA API docs, concrete webhook event schema/trigger docs, and an end-to-end agent-without-admin example.

   • [claimed-docs] “Order Module - Medusa Documentation”
   • [claimed-docs] “Fulfillment Module - Medusa Documentation”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [community] “Swap Difference - love that you have this out of the box. Many e-commerce companies use 3rd party returns/exchange services because Shopify …”
   • [claimed-docs] “Webhook Events”

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

   Medusa's documented MCP server (medusa-docs-4/33/37, probe-3) is scoped to searching Medusa's documentation for IDEs/AI coding tools, not a storefront-facing agent-commerce endpoint for product discovery or cart building; the Store REST/OpenAPI (medusa-gh-x1) exists but is a generic commerce API, not a documented MCP/UCP agent-commerce interface. No evidence of any UCP or dedicated shopping-agent MCP endpoint on the storefront itself.

   • [claimed-docs] “Medusa hosts a Streamable HTTP MCP server at `https://docs.medusajs.com/mcp` that you can add to AI agents supporting MCP server connections…”
   • [claimed-docs] “allows you to find information from the Medusa documentation right in your IDEs or AI tools, such as Cursor”
   • [claimed-docs] “The Medusa documentation provides a remote Model Context Protocol (MCP) server that allows you to find information from the Medusa documenta…”
   • [probe] “official MCP server documented at https://docs.medusajs.com/learn/introduction/build-with-llms-ai/mcp-server”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [claimed-docs] “Cart Module - Medusa Documentation”

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

   While Medusa's commerce modules (Product, Inventory, Order, etc.) and REST/OpenAPI API surface could plausibly support batch operations, no evidence in the pack documents bulk-update, bulk-import/export, or batch-processing endpoints/workflows for AI-driven mass operations across items.

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

   Medusa's pricing page lists 'Webhook Events' as a feature, and its framework/workflow architecture (implied by 'Framework - Guardrails for agents to build customizations') suggests event-driven automation capability, but the evidence pack contains no documentation of a rule-definition system, event subscribers, or trigger-action configuration mechanism. Missing for 10: dedicated docs on defining custom event subscribers/rules, examples of trigger-condition-action automation, and independent confirmation the feature works as described beyond a single bullet point.

   • [claimed-docs] “Webhook Events”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”
   • [claimed-docs] “Guardrails for agents to build customizations.”

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

   Evidence mentions only generic 'background workers' and workflow/framework capabilities, with no documentation of a scheduling API, cron syntax, or recurring-job/workflow trigger mechanism. Missing for 10: explicit scheduled-job/cron API docs, recurring workflow trigger examples, any first-party or community confirmation of a scheduler feature.

   • [claimed-docs] “Background workers”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”

   proof ↗⚑ 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 to Medusa
   Medusa~partialclaimed3/10

   Medusa's evidence only shows generic infrastructure features—GitHub-based deployment, PR previews, and automatic backups—that imply some git-based versioning and rollback for the whole application, but nothing specifically documents versioning, reviewing, or rolling back 'automations' (e.g., workflow definitions) as a distinct AI-native capability. missing for 10: explicit automation/workflow version history, a review/approval flow for automation changes, and a dedicated rollback mechanism for automations themselves.

   • [claimed-docs] “Deploy from GitHub”
   • [claimed-docs] “Own and control all your source-code, while we handle your infrastructure.”
   • [claimed-docs] “Instant previews on PRs”
   • [claimed-docs] “Automatic backups”
   • [claimed-docs] “Push from GitHub to the fastest infrastructure.”

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

   Medusa has a documented B2B Recipe and related commerce modules (Product, Cart, Order, Pricing infrastructure implied) plus GitHub confirmation that the framework supports 'advanced B2B or DTC commerce stores,' showing the platform is architected to support B2B use cases alongside DTC. However, the evidence never details specific features like customer-specific price lists, volume/tiered pricing, quote workflows, or net-terms invoicing — these are not named in any docs excerpt. missing for 10: explicit documentation of customer-specific price lists, volume pricing rules, quote/RFQ workflow, net-terms invoicing support, and independent/hands-on confirmation these B2B features work in practice.

   • [claimed-docs] “B2B Recipe - Medusa Documentation”
   • [github] “The framework and modules can be used to support advanced B2B or DTC commerce stores, marketplaces, distributor platforms, PoS systems, serv…”
   • [claimed-docs] “Inventory Module - Medusa Documentation”
   • [claimed-docs] “Product Module - Medusa Documentation”

   proof ↗⚑ 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
   Medusa~partialcommunity5/10

   Medusa's open-source Product Module (variants/options) and broader commerce-module architecture support building custom product data structures (medusa-docs-21, medusa-gh-2, medusa-gh-4), but the evidence pack gives no detailed confirmation of a general metafields/custom-fields system for products — and an early hands-on community review explicitly noted that metadata support existed for orders but not products at the time (medusa-comm-9), raising doubt about full custom-field flexibility on the catalog side. Missing for 10: current first-party documentation/screenshots showing per-product custom fields or metafields UI, independent confirmation that this limitation has been resolved, and detail on how option/variant modeling handles non-standard catalog structures.

   • [claimed-docs] “Product Module - Medusa Documentation”
   • [github] “Medusa's core commerce modules are open-source and freely available on npm.”
   • [github] “build custom commerce applications without reinventing core commerce logic”
   • [community] “Really love that you have starter kits for both Gatsby and Nextjs... Metadata is a killer feature but I only see it for orders and not produ…”

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

   Medusa exposes a Product Module and REST/Admin API (medusa-docs-21, medusa-gh-x1) that could support programmatic catalog edits, but there is no direct evidence of a bulk CSV import/export feature or bulk-edit UI for operations leads. missing for 10: explicit CSV import/export tooling, bulk-edit admin UI documentation, and any hands-on confirmation that bulk catalog operations work without per-product edits.

   • [claimed-docs] “Product Module - Medusa Documentation”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [claimed-docs] “Customizable dashboard for your commerce.”

   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 Medusa
   Medusa~partialcommunity7/10

   Medusa's documented commerce modules explicitly include an Inventory Module and a Fulfillment Module, which per Medusa's architecture support multi-location stock levels and location-aware fulfillment, and the Sales Channel module ties fulfillment sets to channels — the core building blocks operations leads need. However, the evidence pack only lists module names/titles rather than detailed workflows (e.g., stock adjustment audit trails, warehouse-selection logic in fulfillment), and no independent/hands-on report specifically validates multi-location behavior. Missing for 10: independent corroboration of multi-location stock adjustments and warehouse-based fulfillment routing, and detailed docs excerpts beyond module titles.

   • [claimed-docs] “Inventory Module - Medusa Documentation”
   • [claimed-docs] “Fulfillment Module - Medusa Documentation”
   • [claimed-docs] “Sales Channel Module - Medusa Documentation”
   • [community] “I love the idea of a headless ecommerce platform, especially one that comes with a nice backend GUI for managing inventory. Pleasantly surpr…”

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

   Medusa's modular architecture (Cart, Payment, Tax, Fulfillment, Order modules) and documented 'Framework for customization' let developers extend commerce logic without forking core code, and Storefront Development Guides imply building custom checkout UIs on top of these modules. However, no evidence specifically documents checkout-page extension points for fields, branding, or discount/validation logic — no Promotion/discount module or checkout-specific customization guide is cited. missing for 10: dedicated checkout customization docs, discount/promotion module evidence, branding/field-level extension points, independent developer confirmation of checkout customization.

   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [claimed-docs] “Tax Module - Medusa Documentation”
   • [claimed-docs] “Storefront Development Guides - Medusa Documentation”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [github] “build custom commerce applications without reinventing core commerce logic”
   • [claimed-docs] “Extend, customize, and own every commerce workflow.”

   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 to Swell
   Medusa—none0/10

   The evidence only shows a generic 'Payment Module' doc entry with no mention of Apple Pay, Google Pay, PayPal, or any accelerated/one-click wallet checkout capability; nothing describes wallet-specific integrations or a one-click experience for buyers. This axis clearly applies to a commerce platform, but there is no evidence it delivers accelerated wallet payments.

   • [claimed-docs] “Payment Module - Medusa Documentation”

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

   Medusa's evidence pack covers cart, order, payment modules and general commerce architecture, but there is no mention of abandoned cart detection, recovery email triggers, or checkout-recovery links/workflows anywhere in the docs, GitHub, or community sources. This is a plausible axis for a commerce platform (notification/workflow modules could support it), but no evidence shows it shipping.

   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”

   proof ↗⚑ 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
   Medusa~partialprobed6/10

   Medusa provides a documented Framework and commerce modules for building custom apps, an official CLI (medusa-cli), OpenAPI specs for Store/Admin APIs, starter kits (Next.js/Gatsby storefronts per community feedback), and extension points like Admin Injection Zones and Medusa UI — a reasonably strong extensibility story for a commerce platform. However, there is no clear evidence of a formal marketplace/app-review process or distribution path (e.g., a plugin submission/certification pipeline), and no independent verification of SDK completeness beyond docs. missing for 10: documented app review/certification/distribution marketplace process, independent hands-on verification of scaffolding tooling and SDKs beyond first-party docs.

   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [github] “build custom commerce applications without reinventing core commerce logic”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”
   • [claimed-docs] “Admin Injection Zones”
   • [claimed-docs] “Medusa UI”
   • [probe] “official CLI documented at https://docs.medusajs.com/resources/medusa-cli”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [community] “Really love that you have starter kits for both Gatsby and Nextjs... Metadata is a killer feature but I only see it for orders and not produ…”

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

   Medusa's evidence covers its open-source core modules, framework, and integrations documentation, but there is no mention of a curated or vetted marketplace/app store of third-party extensions comparable to Shopify's App Store. The story specifically requires a vetted marketplace covering long-tail features, which is unevidenced here.

   ⚑ 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
   Medusa~partialclaimed5/10

   Medusa's GitHub and marketing docs confirm a 'built-in framework for customization' that lets developers 'extend, customize, and own every commerce workflow' and includes commerce modules (Fulfillment, Tax, Cart, Order) that could house custom logic, supporting the general concept of injecting backend logic. However, the evidence pack lacks concrete documentation of the specific hook/subscriber/workflow mechanisms, discount or promotion customization, or serverless function deployment model that would show how validation/shipping/discount logic actually gets injected. Missing for 10: explicit workflow/subscriber/hook API docs, a discount-module customization example, and confirmation of serverless execution model.

   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [claimed-docs] “Framework - Guardrails for agents to build customizations.”
   • [claimed-docs] “Guardrails for agents to build customizations.”
   • [claimed-docs] “Extend, customize, and own every commerce workflow.”
   • [claimed-docs] “Fulfillment Module - Medusa Documentation”
   • [claimed-docs] “Tax Module - Medusa Documentation”

   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 drawn
   Medusa✓fullprobed7/10

   Medusa documents commerce modules (Product, Order, Cart, Payment, Fulfillment, Tax) and maintains OpenAPI specs powering Admin/Store REST APIs, confirming programmatic control over products, orders, refunds, and fulfillment via the admin API. However, the evidence pack lacks a direct hands-on example of issuing a refund or triggering fulfillment through the API, and the openapi.json probe for the admin spec 404s despite the store spec being confirmed. missing for 10: direct admin API refund/fulfillment usage examples, independent developer corroboration of admin API completeness, working openapi.json endpoint discovery.

   • [claimed-docs] “Product Module - Medusa Documentation”
   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Order Module - Medusa Documentation”
   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [claimed-docs] “Fulfillment Module - Medusa Documentation”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.medusajs.com/openapi.json, https://docs.medusajs.com/swagger.json, https://docs.medusaj…”

   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 to Medusa
   Medusa✓fullcommunity9/10

   Medusa provides documented Storefront Development Guides, first-party Next.js starter storefronts, commerce modules (product, cart, order, payment, tax, fulfillment), and a documented Store REST/OpenAPI API (openapi.full.yaml) that developers can build fully custom headless storefronts against, corroborated by community feedback praising the Next.js/Gatsby starter kits and headless architecture. Missing for 10: independent hands-on report building a production custom storefront end-to-end and a live OpenAPI endpoint (probe found 404s on some openapi paths despite the spec existing in-repo).

   • [claimed-docs] “Storefront Development Guides - Medusa Documentation”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [github] “build custom commerce applications without reinventing core commerce logic”
   • [claimed-docs] “Product Module - Medusa Documentation”
   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Order Module - Medusa Documentation”
   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [community] “Really love that you have starter kits for both Gatsby and Nextjs... Metadata is a killer feature but I only see it for orders and not produ…”
   • [community] “I love the idea of a headless ecommerce platform, especially one that comes with a nice backend GUI for managing inventory. Pleasantly surpr…”

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

   Medusa's Sales Channel Module lets merchants manage a single product catalog across multiple defined sales channels, which is the underlying architecture needed for multi-channel selling, but there is no evidence of built-in connectors or sync tooling for actual external marketplaces, social commerce platforms, or shopping feeds (e.g., Amazon, Instagram, Google Shopping). Missing for 10: documented integrations/apps for external marketplaces or feed syncing, evidence of feed export formats, and any hands-on confirmation that products actually sync outward rather than just being logically grouped by channel.

   • [claimed-docs] “Sales Channel Module - Medusa Documentation”
   • [github] “The framework and modules can be used to support advanced B2B or DTC commerce stores, marketplaces, distributor platforms, PoS systems, serv…”

   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
   Medusa!disputedcontradicted4/10

   Medusa's Tax Module doc suggests some duties/tax handling capability, but there is no evidence in the pack of multi-currency pricing, localized storefronts, or translation tooling — and a hands-on HN reviewer explicitly flags that 'internationalization... every product has a single string for description/title, with no easy way to localize text across regions,' directly contradicting the translations/localization part of this story. missing for 10: multi-currency pricing docs, region/locale storefront docs, translation/i18n module evidence, duties/customs handling detail beyond a generic Tax Module link.

   • [claimed-docs] “Tax Module - Medusa Documentation”
   • [community] “One area I do think could be improved is internationalization; every product has a single string for description/title, with no easy way to …”
   • [community] “I love the idea of a headless ecommerce platform, especially one that comes with a nice backend GUI for managing inventory. Pleasantly surpr…”

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

   Medusa's evidence covers its Sales Channel, Inventory, and Product modules which theoretically enable multi-channel selling, but there is no mention of an actual point-of-sale product/app or in-person checkout capability anywhere in the pack. Missing for 10: any POS application/device support, in-store checkout flow, or documentation of a POS integration syncing catalog/inventory/customers in real time.

   • [claimed-docs] “Sales Channel Module - Medusa Documentation”
   • [claimed-docs] “Inventory Module - Medusa Documentation”
   • [github] “The framework and modules can be used to support advanced B2B or DTC commerce stores, marketplaces, distributor platforms, PoS systems, serv…”

   proof ↗⚑ 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 to Swell
   Medusa~partialclaimed6/10

   Medusa is architected API-first: its Admin dashboard is itself a client of the documented Admin REST API, and Medusa publishes complete OpenAPI 3.0 specs for both Store and Admin APIs, implying the UI's functionality is API-backed. However, no evidence explicitly confirms full feature parity (e.g., every admin UI action having a documented API equivalent) or independent verification of this claim. Missing for 10: explicit parity documentation/statement, independent hands-on confirmation that all UI actions map to API endpoints, and no gaps noted (e.g., some UI-only settings).

   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [claimed-docs] “Admin - Customizable dashboard for your commerce.”

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

   Medusa's core is open-source and self-hostable, and vendor messaging emphasizes 'you own the project' and full source-code control, plus documented REST/OpenAPI specs (medusa-gh-x1) that could be used to pull data out programmatically. However there is no explicit documented 'export all data' feature, bulk data-export tool, or standardized open-format export (CSV/JSON dump) for leaving the platform — ownership is implied via self-hosting rather than a first-class export capability. missing for 10: explicit bulk data-export tooling, documented open-format export (CSV/JSON), migration/exit guide confirming full data portability.

   • [github] “Medusa's core commerce modules are open-source and freely available on npm.”
   • [claimed-docs] “Own and control all your source-code, while we handle your infrastructure.”
   • [claimed-docs] “You own the project, we handle the infra.”
   • [claimed-docs] “You own the project, we handle the infra. No GMV-tax or special licenses.”
   • [github] “openapi: 3.0.0 / info: title: Medusa Storefront API, license: MIT — Medusa maintains complete machine-readable OpenAPI 3.0 specifications fo…”

   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 Medusa
   Medusa✓fullcommunity8/10

   Medusa's core is confirmed open-source on GitHub, with modules 'open-source and freely available on npm,' and community commentary independently confirms the repo is MIT-licensed. This directly satisfies an AI-native user's ability to read the source under an open license. Missing for 10: an explicit first-party license statement/citation (e.g., LICENSE file text) rather than inference from a community comment, and clarity on whether the entire platform vs. just certain modules is MIT-licensed.

   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”
   • [github] “Medusa's core commerce modules are open-source and freely available on npm.”
   • [community] “The landing page looks like it's trying to sell me a product, but the Github says it's MIT licensed... is there some component that costs mo…”
   • [community] “Listed among open-source SaaS alternatives: 'Shopify -> MedusaJS'.”

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

   The evidence pack only shows a doc-page title for a 'Payment Module' (medusa-docs-24) with no description of supporting multiple third-party gateways or multi-currency charging; there's no mention of Stripe/PayPal/other providers, currency configuration, or a plugin marketplace for payment providers. missing for 10: explicit description of pluggable third-party payment providers, evidence of multi-currency charge support, and any merchant-facing docs/community confirmation of switching or combining payment gateways.

   • [claimed-docs] “Payment Module - Medusa Documentation”

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

   Medusa's Payment Module (medusa-docs-24) is documented as an integration layer for third-party payment providers (e.g., Stripe, PayPal), not a first-party processor with its own published card rates, payouts, or fraud tooling. No evidence in the pack shows Medusa acting as the payment processor of record — the architecture is built around 'wiring' external gateways, which is the opposite of this story's ask.

   • [claimed-docs] “Payment Module - Medusa Documentation”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”

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

   Medusa's open-source/self-hosted architecture (BYOC, 'You own the project, we handle the infra') inherently lets users deploy in any region they choose, and the Enterprise pricing tier explicitly lists 'Data sovereignty, SOC2, custom DPA' as a feature, implying some data-residency control for cloud customers. However, there is no documentation of specific supported regions, a UI/API for selecting storage location, or details on how data sovereignty is technically enforced. Missing for 10: explicit region-selection mechanism/UI, list of supported regions, technical details on how residency is guaranteed, independent confirmation of the enterprise feature in practice.

   • [claimed-docs] “Data sovereignty, SOC2, custom DPA”
   • [claimed-docs] “You own the project, we handle the infra.”
   • [claimed-docs] “BYOC with Enterprise License”
   • [github] “Medusa's core commerce modules are open-source and freely available on npm.”

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

   Medusa is self-hosted/open-source (you own your infra and database) and Cloud tier mentions 'Data sovereignty, SOC2, custom DPA' and 'Automatic backups', implying some control over where and how data is stored, but there is no explicit documentation of data retention policies, deletion APIs, or GDPR-style erasure workflows for commerce/customer data. Missing for 10: explicit data retention/deletion tooling or docs, GDPR/right-to-erasure endpoints, and independent confirmation of these controls in practice.

   • [claimed-docs] “Own and control all your source-code, while we handle your infrastructure.”
   • [claimed-docs] “Data sovereignty, SOC2, custom DPA”
   • [claimed-docs] “Automatic backups”

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

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

   weight 2 · round drawn
   Medusa—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Medusa; the axis is applicable to a self-hosted commerce platform but no documentation, GitHub, or community source confirms or denies telemetry practices.

   ⚑ flag

   Swell—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out mechanisms for Swell's CLI, apps, or AI tooling; the pack covers commerce features and developer tooling but never mentions data collection or privacy settings.

   ⚑ flag

Content

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

   weight 1 · round drawn
   Medusa—none0/10

   Medusa's documented modules cover commerce entities (Product, Cart, Order, Payment, Tax, Fulfillment, Inventory, Sales Channel) but no evidence shows a content/pages/blog/media module or CMS capability in the admin; Admin Injection Zones only allow UI customization, not content authoring.

   • [claimed-docs] “Product Module - Medusa Documentation”
   • [claimed-docs] “Cart Module - Medusa Documentation”
   • [claimed-docs] “Order Module - Medusa Documentation”
   • [claimed-docs] “Admin Injection Zones”
   • [claimed-docs] “Admin - Customizable dashboard for your commerce.”

   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
   Medusa~partialcommunity4/10

   Medusa provides storefront development guides and Next.js/Gatsby starter kits (medusa-docs-5, medusa-comm-9) plus GitHub-based deploys and PR preview environments (medusa-docs-1, medusa-docs-11, medusa-docs-35), which cover part of the version-controlled-deploy and preview aspects of the story. However, Medusa is headless — there is no documented 'templating layer' or theme system (it's a full custom React/Next.js app, not theme templates), and no explicit local-preview workflow documentation is cited. Missing for 10: a documented templating/theme abstraction layer, explicit local-preview tooling docs, and independent hands-on confirmation of the PR-preview/deploy flow.

   • [claimed-docs] “Storefront Development Guides - Medusa Documentation”
   • [community] “Really love that you have starter kits for both Gatsby and Nextjs... Metadata is a killer feature but I only see it for orders and not produ…”
   • [claimed-docs] “Deploy from GitHub”
   • [claimed-docs] “Instant previews on PRs”
   • [claimed-docs] “Push from GitHub to the fastest infrastructure.”

   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 to Swell
   Medusa—none0/10

   Medusa is explicitly a headless, developer-first commerce platform — its storefront resources are 'Storefront Development Guides' requiring coding (medusa-docs-5), not a no-code theme/section editor. Community feedback explicitly notes headless means 'I have to write my own interfaces,' the opposite of a no-code polished-theme experience (medusa-comm-6). No evidence anywhere in the pack of a theme marketplace, visual page builder, or no-code branding/layout editor for merchants.

   • [claimed-docs] “Storefront Development Guides - Medusa Documentation”
   • [community] “Looks nice but to be a Shopify alternative, headless is not the way... Headless makes me think I have to write my own interfaces which then …”
   • [github] “Medusa is a commerce platform with a built-in framework for customization that allows you to build custom commerce applications without rein…”

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

   Evidence only shows a generic 'Fulfillment Module' doc title (medusa-docs-26); there is no evidence of live carrier rate shopping at checkout, label purchasing, or shipment tracking integration. Missing for 10: carrier rate-shopping integration details, label purchase workflow, tracking/status sync evidence.

   • [claimed-docs] “Fulfillment Module - Medusa Documentation”

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

   Medusa ships a dedicated Tax Module in its commerce modules, implying built-in tax configuration, but the evidence pack gives no detail on automatic per-jurisdiction rate calculation, rate updates/currency, or generating filing-ready tax reports. missing for 10: documentation of jurisdiction-based automatic tax calculation, rate update/maintenance mechanism, tax report generation/export for filing, and any third-party tax provider integrations (e.g., Avalara/TaxJar).

   • [claimed-docs] “Tax Module - Medusa Documentation”

   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