Autumn vs Polar

Agent access

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

   weight 2 · round to Polar
   Autumn✓fullprobed8/10

   A probe confirms llms.txt is live at docs.useautumn.com/llms.txt returning HTTP 200 with structured doc links, directly satisfying the ability to point an agent at agent-oriented docs; this is reinforced by an official MCP server for AI assistants. Missing for 10: no independent/community confirmation of an agent successfully consuming llms.txt in practice, and no openapi.json fallback.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.useautumn.com/llms.txt # Autumn - [Welcome to Autumn](https://docs.useautumn.com/welcome.md): Drop…”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar publishes an llms.txt at /docs/llms.txt (also live-probed at /llms.txt returning HTTP 200) with .md siblings for every doc page and versioned OpenAPI specs, explicitly designed for agent legibility; this is corroborated by a direct probe hit. Missing for 10: independent third-party confirmation that AI agents actually consume these docs successfully in practice (only first-party docs and probes provided), and the root-level docs.md probe returned 404, showing coverage isn't perfectly uniform across all URL patterns.

   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”
   • [probe] “PROBE docs-md: HTTP 404 at https://polar.sh/docs.md”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Autumn~partialprobed5/10

   Autumn ships an `atmn` CLI that syncs pricing configs (`autumn.config.ts`) with a single command and supports non-interactive actions like `preview` and `pull`, which are scriptable and could run in CI, plus SDK calls (`check`, `track`) that are inherently headless. However, there's no explicit documentation or example of running Autumn in a CI/CD pipeline, no mention of non-interactive auth/token flags for automated environments, and no community confirmation of headless CI usage. Missing for 10: explicit CI/CD pipeline examples, non-interactive authentication guidance, and independent confirmation of automated/headless runs.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar exposes a full API/SDKs (Python, TypeScript), a CLI (`polar listen` for webhook forwarding) and an isolated sandbox environment for testing without live money, all of which could be scripted into CI pipelines, and its OpenAPI/llms.txt makes it machine-legible for automation. However there is no explicit documentation of running Polar itself headlessly or CI/CD integration guidance (e.g., GitHub Actions examples, automated test suites against sandbox). missing for 10: explicit CI/CD pipeline documentation or examples, statement of headless/automation mode, independent evidence of running the CLI/SDKs unattended in a build pipeline.

   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

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

   weight 3 · round to Polar
   Autumn✓fullprobed8/10

   Autumn is a billing/entitlements SaaS platform (not itself an agent), and it documents an official MCP server that connects AI assistants to its billing, customer, plan, balance, and log tools, confirmed by both docs and probe. Missing for 10: independent hands-on confirmation of the MCP server working and more detail on its tool coverage/setup.

   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar (a SaaS billing platform, not itself an agent) documents an official remote MCP server with production and sandbox endpoints, OAuth-based auth, and setup instructions for Cursor, Claude Code, ChatGPT, and Claude Desktop, letting agents securely act on the organization's data. Missing for 10: independent/community hands-on confirmation beyond vendor docs and probes.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Autumn
   Autumn✓fullprobed8/10

   Autumn ships an official `atmn` CLI documented in first-party docs, supporting config-as-code (autumn.config.ts), pushing/syncing plans, previewing changes (bunx atmn preview), and pulling existing dashboard products (atmn pull) — clearly enabling AI-native, code-first workflows. Missing for 10: independent/hands-on community verification of the CLI itself (community evidence covers billing/security topics, not CLI usage) and no evidence of scripting/automation-specific features beyond basic commands.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

   The docs show a single CLI invocation, `polar listen http://localhost:3000/`, implying an official Polar CLI for local webhook forwarding/testing, but there's no dedicated CLI reference page, installation instructions, or list of subcommands beyond this one snippet. missing for 10: CLI installation/setup docs, full command reference, independent confirmation of broader CLI usage.

   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

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

   weight 3 · round to Polar
   Autumn✓fullprobed8/10

   Autumn ships a documented public API with clear reference pages (check, track, attach) and code examples, webhooks, and an API-reference section, letting an AI-native user drive billing/entitlements programmatically. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe found only 404s at expected paths), and independent hands-on confirmation of API robustness beyond docs.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “You can also [check and reserve] balance in a single, atomic API call for concurrent events.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar publishes a documented, versioned OpenAPI 3.1 spec, official typed SDKs (TypeScript/Python), webhooks, and llms.txt/agent-legible docs, giving AI-native users a fully documented public API surface to drive the product programmatically. missing for 10: independent third-party corroboration of the API's stability/completeness beyond first-party docs, and the probe showing openapi.json not reachable at the root domain (spec is only under /docs).

   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Autumn—none0/10

   Autumn's docs describe customerId-based check/track/attach calls and an MCP server for billing tools, but there is no evidence of an API-key or credential system that lets an AI-native user mint scoped, least-privilege credentials for an agent. Community reports even describe unauthenticated server actions and customer_id spoofing (IDOR), the opposite of least-privilege access control.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [community] “Commenters criticized Autumn's 'backendless billing' approach as reinventing JWTs poorly: "Your encrypted customer ID has the exact same sem…”
   • [community] “Security concern raised: Autumn's server actions were public, unauthenticated routes, meaning "a simple curl request with a different custom…”

   proof ↗⚑ flag

   Polar~partialprobed5/10

   Polar's MCP server uses OAuth so agents authorize access to an organization via browser rather than embedding a raw API key, which is a step toward safer agent credentialing, but the docs describe org-level authorization only, not fine-grained/least-privilege scopes (e.g., read-only vs write, per-resource permissions) for issuing agent-specific credentials. Missing for 10: documented scope/permission granularity for API keys or OAuth tokens, ability to restrict an agent to specific resources/actions, and any explicit 'least privilege' credential-issuance workflow.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Polar
   Autumn✓fullprobed7/10

   Docs consistently show official SDK code (autumn.check, autumn.track, autumn.attach) across many endpoints, plus a companion CLI (atmn) for config sync, indicating a first-party SDK for building AI-native billing integrations. Missing for 10: explicit multi-language SDK coverage/package registry links and independent developer corroboration of SDK usage beyond docs.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents official TypeScript and Python SDKs with full type safety, fully typed sync/async clients, framework adapters, versioned OpenAPI specs, and machine-legible llms.txt docs—clear support for AI-native developers building against official SDKs. missing for 10: independent third-party corroboration of SDK quality/coverage beyond vendor docs, and the openapi probe found no public root-level spec (though versioned specs are documented within docs).

   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Framework adapters make it dead simple to add Polar checkouts and webhooks to your stack.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Polar
   Autumn~partialclaimed6/10

   Autumn documents webhooks fired on plan/subscription changes (autumn-docs-8), giving basic event subscription capability, but evidence doesn't cover a broad event catalog (e.g. usage/track events), payload schemas, signing/verification, or subscription management API — missing for 10: full webhook event catalog, payload/signature docs, subscription management endpoints, independent hands-on confirmation.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar provides comprehensive webhook subscription support: documented endpoint configuration, async event notifications instead of polling, Standard Webhooks spec compliance, typed payloads, signature validation SDK helpers, local testing via `polar listen`, and CRUD API for webhook endpoints — directly enabling event-driven/agentic integration patterns. missing for 10: independent third-party corroboration of webhook reliability at scale beyond vendor docs.

   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Customer State is a concept allowing you to query for the current state of a customer, including their active subscriptions and granted bene…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Polar
   Autumn~partialprobed5/10

   Autumn ships an official MCP server that 'connects AI assistants to Autumn's billing, customer, plan, balance, and log tools,' enabling AI-native/natural-language operation indirectly through an MCP-connected assistant rather than a built-in chat interface. There's no first-party or community evidence of actual natural-language command usage in practice, and the product is fundamentally a CLI/API/dashboard tool otherwise. Missing for 10: direct natural-language command interface (not just MCP passthrough), hands-on demonstration of NL commands working, independent user corroboration.

   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

   proof ↗⚑ flag

   Polar✓fullprobed8/10

   Polar ships a documented remote MCP server (OAuth-secured) that lets AI agents look up data and take actions across products, customers, subscriptions, orders, and benefits, with explicit setup for Claude Code, Cursor, ChatGPT, and Claude Desktop — enabling natural-language operation of the product via an agent client. Missing for 10: independent/hands-on validation of the MCP server working in practice and concrete examples of successful natural-language command execution beyond vendor docs.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Polar
   Autumn—none0/10

   Autumn's docs include static code snippets for API endpoints (e.g. check, attach) but there is no evidence of an interactive, runnable API console—probes for openapi/swagger specs all 404'd, indicating no interactive reference tooling exists.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

   proof ↗⚑ flag

   Polar~partialprobed5/10

   Polar publishes versioned OpenAPI specs and machine-readable docs (llms.txt/.md pages) plus a sandbox environment for testing API calls with test cards, which supports API exploration, but there is no evidence of an actual interactive API reference UI (e.g., a Swagger/Redoc-style console) with embedded runnable examples directly in the docs. Missing for 10: an in-docs interactive 'try it' console, embedded runnable code examples per endpoint, and independent confirmation the OpenAPI spec renders as an explorable reference.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Autumn—none0/10

   There's an api-reference section implying documented endpoints, but a direct probe for OpenAPI/Swagger specs at standard paths returned 404s with no alternate machine-readable spec found or linked anywhere in the docs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

   proof ↗⚑ flag

   Polar✓fullprobed7/10

   Polar's docs explicitly state it serves versioned OpenAPI 3.1.0 specs (2026-04.openapi.json, 2026-10.openapi.json) directly from the docs site alongside llms.txt and per-page .md files, giving AI-native users machine-readable spec access. However, probes only tested root-domain paths (polar.sh/openapi.json etc., all 404) rather than the actual documented docs-site paths, so there's no independent confirmation of a successful direct download. Missing for 10: independent verification of the exact documented OpenAPI URL resolving successfully, and no mention of spec discoverability via standard well-known paths.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 1 · round to Polar
   Autumn—none0/10

   Autumn is a billing/entitlements layer where sandbox/test-mode testing is a reasonable ask (similar to Stripe test mode), but the evidence pack has no mention of a dedicated sandbox/test environment separate from production—only 'atmn preview' for previewing pricing plan changes before pushing config, which is not the same as isolating test transactions/customers from production data.

   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar documents a fully isolated sandbox environment (separate server, unlimited test accounts/orgs) that supports end-to-end testing including checkout with Stripe test cards, explicitly to avoid touching production data or money — and a dedicated sandbox MCP endpoint further supports AI-agent testing workflows. missing for 10: independent/hands-on third-party confirmation beyond vendor docs.

   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “To test Polar or work on your integration without worrying about actual money processing or breaking your live organization, you can use our…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Autumn—none0/10

   No evidence of API versioning scheme or documented deprecation policy; changelog entries show ongoing changes but no version numbers or deprecation guarantees, and OpenAPI/spec probes 404. missing for 10: versioned API endpoints/headers, explicit deprecation policy documentation, migration guides for breaking changes.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”
   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”

   proof ↗⚑ flag

   Polar~partialprobed4/10

   Evidence shows Polar publishes dated, versioned OpenAPI specs (2026-04.openapi.json and 2026-10.openapi.json) alongside machine-readable docs (llms.txt), indicating an API versioning scheme exists. However, no evidence describes an explicit deprecation policy, sunset timelines, or migration guidance between API versions; probes for a root-level openapi.json also 404 outside the documented docs-site paths. Missing for 10: documented deprecation/sunset policy, version lifecycle timelines, migration guides between dated API versions, independent confirmation of long-term version support.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Autumn—none0/10

   Autumn's docs show only single-item operations (check, track, attach for one customer/feature at a time) and CLI commands (pull/preview/push) that sync a single config, but no batch/bulk API for operating across many customers, features, or items at once. missing for 10: bulk/batch API endpoints, documentation of batch customer or feature updates, evidence of any multi-item transaction support.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's docs describe individual resource APIs, webhooks, SDKs, and an MCP server for agents to look up/take actions, but nothing in the evidence pack describes batch or bulk endpoints (e.g., bulk refunds, bulk customer/product updates, batch import) that would let an AI-native user act on many items in one call.

   ⚑ flag

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

   weight 3 · round drawn
   Autumn~partialclaimed4/10

   Autumn supports event-driven mechanisms like webhooks fired on plan changes and usage alerts with configurable thresholds (basis field), which act as simple automated triggers tied to billing state. However, there is no evidence of a general-purpose rule engine where users can define custom trigger→action logic across arbitrary events; the automation is scoped narrowly to billing/entitlement events. Missing for 10: a documented rules/automation DSL or workflow builder, support for arbitrary custom triggers/actions beyond billing events, and evidence of chaining multiple actions per rule.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “You can also [check and reserve] balance in a single, atomic API call for concurrent events.”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

   Polar ships built-in automated behaviors for specific billing events (auto-renewal, dunning/retry schedules, proration) and webhooks that notify external systems asynchronously when events occur, which a user can wire up to trigger their own actions. However, there is no evidence of a native rule-definition engine (e.g., 'if event X then do Y' conditions/workflows) inside Polar itself — automation requires building a webhook consumer outside the product. Missing for 10: a first-party rules/workflow builder, conditional logic on events, and any evidence of user-authored automation rules beyond webhook delivery.

   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”
   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

Ai billing ops

1. ai-native userHave an agent monitor failed payments via API and webhooks and drive retries and dunning outreach

   weight 3 · round to Polar
   Autumn—none0/10

   Evidence shows Autumn webhooks fire only on plan changes (new subscriptions, upgrades, downgrades) and covers usage/credit tracking, but there is no mention of failed-payment events, retry logic, or dunning outreach workflows anywhere in the docs, changelog, or community threads. This is a fair axis for a billing product (Stripe-based dunning is a common billing capability) but no evidence supports Autumn delivering it.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar documents automated dunning (fixed retry schedule 2/5/7/7 days, past_due state, customer emails) plus webhooks for async notifications and an official MCP server letting agents 'look up data and take actions' across subscriptions/orders — enough for an agent to monitor failed payments and dunning state via API/webhooks. However, dunning/retries are built-in automatic Polar behavior rather than agent-driven; there's no documented API/webhook event specifically for failed-charge notification or an endpoint for an agent to manually trigger a retry or custom outreach message. Missing for 10: explicit failed-payment webhook event schema, an API to trigger/override retry attempts, and evidence of agent-customized dunning outreach beyond Polar's built-in emails.

   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Polar lets you run these off-session charges against a customer's saved payment method, without the customer being present.”

   proof ↗⚑ flag

2. ai-native userHave an agent provision a new product, price, and payment link via the API in a single session

   weight 3 · round to Polar
   Autumn~partialprobed5/10

   Autumn's API/CLI supports creating products/plans (attach, config.ts, atmn CLI) and MCP server exposes billing/plan/customer tools to AI assistants, suggesting an agent could provision products and prices programmatically, but there is no direct evidence of generating a 'payment link' via API or of a documented single-session workflow combining product+price+payment link creation. missing for 10: explicit payment-link creation endpoint/API, end-to-end example of an agent provisioning product+price+payment link in one session, independent verification of this workflow.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

   proof ↗⚑ flag

   Polar~partialclaimed7/10

   Polar documents a remote MCP server giving agents OAuth-secured access to 'take actions across your products, customers, subscriptions, orders, benefits, and more,' plus a full API/SDK stack (Checkout Session API, versioned OpenAPI specs, llms.txt) that would let an agent create a product, price, and payment link programmatically in one session. However, there's no first-party walkthrough or hands-on example explicitly chaining product+price+payment-link creation via MCP or API in a single session. Missing for 10: an explicit documented example/tutorial showing an agent creating product, price, and checkout link together in one session, and independent confirmation the MCP tool schema exposes create-product/create-price actions (not just 'look up' access).

   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

Subscriptions

1. finance-ops userAutomatically retry failed subscription payments with smart dunning and recovery emails

   weight 2 · round to Polar
   Autumn—none0/10

   Autumn's evidence covers metering, entitlements, plan attachment, and Stripe catalog sync, but there is no mention of dunning, retry logic for failed payments, or recovery emails anywhere in the docs, changelog, or community discussion.

   ⚑ flag

   Polar✓fullclaimed8/10

   Polar documents automated dunning explicitly: failed charges move the subscription to past_due, trigger a fixed retry schedule (2,5,7,7 days up to 21 days), stamp next_payment_attempt_at, and send the customer a recovery email with a Customer Portal link to update payment method rather than canceling immediately. This directly matches the story's core ask of automatic retries with recovery emails. Missing for 10: no evidence of customizable dunning schedules, multi-channel (SMS/in-app) recovery notifications, or independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “The Customer Portal is a hosted, self-service page where your customers can manage everything related to their relationship with your busine…”

   proof ↗⚑ flag

2. developerSet up recurring subscription billing with plans, trials, upgrades, and proration

   weight 3 · round to Polar
   Autumn✓fullcommunity8/10

   Autumn's docs explicitly cover defining plans (autumn.config.ts + atmn CLI), attaching plans to customers with automatic handling of new subscriptions, upgrades, and downgrades, usage-based/pay-per-use pricing with proration-like billing period logic, and webhooks firing on plan changes (new subscriptions, upgrades, downgrades). Community feedback corroborates real-world use for billing/entitlements and notes Autumn's team handling of annual/monthly billing transitions and race conditions. Missing for 10: explicit first-party documentation of free trials and detailed proration mechanics, plus independent hands-on verification of trial/upgrade billing flows.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Pay-per-use (usage-based) pricing charges customers based on how much of a feature they actually consume, billed at the end of each billing …”
   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”
   • [community] “Autumn combines billing, metering, and entitlements into a single state, unlike Lago which only handles billing—users must sync permissions …”
   • [community] “"love this as someone who's been fixing the same billing bugs over and over and who sometimes finds stripe more complex than it should be." …”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar documents recurring subscriptions with automatic renewal, plan upgrades/downgrades with immediate rate changes, configurable proration behavior (org-level or per-call), trials are implied via subscription lifecycle, and dunning/failed-payment retry schedules; seat-based proration is also documented. Missing for 10: explicit first-party documentation of trial period configuration (only inferred, not directly cited) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Polar renews it automatically. At the end of each billing period, Polar advances the subscription to the next cycle and creates a new order”
   • [claimed-docs] “You pick the proration behavior either at the organization level (as the default) or per API call.”
   • [claimed-docs] “You can switch between plans anytime, and your rate adjusts immediately.”
   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Add, remove and prorate seats automatically.”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”

   proof ↗⚑ flag

Card acceptance

1. founderAccept an online card payment within a day of signing up

   weight 3 · round to Polar
   Autumn~partialcommunity4/10

   Autumn is a billing/metering layer built on top of Stripe, with an `attach` API that handles new subscriptions/upgrades/downgrades and a CLI that syncs pricing plans in a single command, suggesting reasonably fast setup. However, there's no direct evidence of a turnkey checkout page or explicit same-day payment acceptance flow, and the product only works atop Stripe (comm-4), meaning a founder still needs a separate Stripe account/setup for actual card processing. Missing for 10: an end-to-end checkout UI or hosted payment page, explicit time-to-first-payment claims, and independent confirmation of same-day integration speed.

   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents fast onboarding ('minutes from an existing store'), no-code Checkout Links you can 'share the URL anywhere,' embedded checkout, and a Merchant-of-Record model that lets founders accept international card payments without setting up separate processors — plus a sandbox to test cards before going live. This directly supports going from signup to accepting a real card payment within a day. Missing for 10: independent/hands-on account confirming actual time-to-first-live-payment (all evidence is vendor docs) and no explicit account approval/KYC timeline that could delay live payments.

   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”
   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “As the Merchant of Record, Polar takes care of charging customers, so Stripe Payments doesn't need to be available in your country.”

   proof ↗⚑ flag

Checkout surfaces

1. developerEmbed customizable payment components directly in my own site or app instead of redirecting to a hosted page

   weight 3 · round to Polar
   Autumn—none0/10

   Autumn's evidence describes a billing/metering/entitlements API, CLI, and MCP integration built on top of Stripe, but nothing in the pack mentions embeddable payment/checkout UI components as an alternative to hosted checkout pages—attach/billing calls appear to route through Stripe's own flows.

   ⚑ flag

   Polar✓fullclaimed8/10

   Polar documents an embedded checkout explicitly designed to avoid redirecting users off-site, plus a Checkout Session API for deeper custom integration, alongside the simpler hosted checkout links option — directly matching the story's ask for embeddable, customizable in-app payment components. Missing for 10: independent/hands-on confirmation of embed customization depth (styling, component-level control) beyond first-party docs.

   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”

   proof ↗⚑ flag

2. developerRedirect customers to a vendor-hosted, conversion-optimized checkout page without building my own payment UI

   weight 3 · round to Polar
   Autumn—none0/10

   The evidence pack covers Autumn's metering, entitlements, CLI, MCP, and plan-attach APIs, but nowhere describes a vendor-hosted, conversion-optimized checkout page that a developer can redirect customers to; 'attach' only documents subscription state changes, not a hosted checkout flow.

   ⚑ flag

   Polar✓fullclaimed9/10

   Polar documents no-code Checkout Links that developers configure once and redirect to (share URL anywhere, hosted, Polar handles the rest), plus a Checkout Session API for deeper redirect flows, and a sandbox to test the full checkout funnel end-to-end — directly matching a vendor-hosted redirect checkout without building custom payment UI. missing for 10: independent third-party review of checkout conversion/UX quality beyond vendor docs.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”

   proof ↗⚑ flag

No code selling

1. founderCreate a shareable payment link from the dashboard with no code and start selling immediately

   weight 2 · round to Polar
   Autumn—none0/10

   Autumn is a code-first billing/entitlements layer requiring SDK calls, an autumn.config.ts file, or CLI (atmn) to define and attach plans—there is no evidence of a no-code, dashboard-generated shareable payment link feature for founders to start selling immediately.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Pay-per-use (usage-based) pricing charges customers based on how much of a feature they actually consume, billed at the end of each billing …”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar explicitly documents no-code Checkout Links: 'Configure once in the dashboard, share the URL anywhere... and Polar handles the rest,' as one of three checkout surfaces alongside embedded and API-driven flows, and Polar acts as Merchant of Record so a founder can sell immediately without separate tax/payment setup. Missing for 10: independent/hands-on confirmation of the dashboard link-creation flow beyond vendor docs, and no third-party account of actual end-to-end usage.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”

   proof ↗⚑ flag

Payment methods

1. founderOffer digital wallets and local payment methods (Apple Pay, Google Pay, bank redirects, BNPL) from the same integration

   weight 2 · round drawn
   Autumn—none0/10

   Autumn is a billing/entitlement/metering layer built on top of Stripe (confirmed by autumn-comm-4, which notes it lacks support for other payment providers like Paystack), but the evidence pack contains no mention of Autumn configuring or exposing digital wallets, local payment methods, bank redirects, or BNPL options in checkout. Missing for 10: any documentation of wallet/BNPL/local payment method support, checkout configuration options, or evidence Autumn surfaces Stripe's payment-method capabilities to founders.

   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

   proof ↗⚑ flag

   Polar—none0/10

   The evidence pack extensively documents Polar's checkout flows (links, embedded, API-driven), merchant-of-record tax handling, subscriptions, and payments infrastructure, but nowhere mentions specific payment method support such as Apple Pay, Google Pay, bank redirects, or BNPL options. Sandbox testing is documented only via Stripe test card numbers, not wallet/local payment coverage.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”

   proof ↗⚑ flag

Integration reliability

1. developerSafely retry any API request using idempotency keys so network failures never create duplicate charges

   weight 2 · round drawn
   Autumn—none0/10

   No evidence pack item mentions idempotency keys or request-retry safety mechanisms anywhere in Autumn's docs, changelog, or community discussion; the API examples shown (check, track, attach) don't reference idempotency handling.

   ⚑ flag

   Polar—none0/10

   The evidence pack covers checkout, subscriptions, webhooks, SDKs, and dunning/retry logic for failed payments, but nowhere mentions idempotency keys or a documented mechanism for safely retrying API requests to prevent duplicate charges. This is a standard, fair expectation for a payments API, so its absence is 'none' rather than 'na'.

   ⚑ flag

2. developerRely on signed webhook deliveries with automatic retries, event logs, and replay to keep my system consistent with payment state

   weight 3 · round to Polar
   Autumn—none0/10

   Docs mention webhooks are fired for plan changes, but there is no evidence of signed payloads, automatic retries, event logs, or replay functionality for webhook deliveries; the evidence pack shows only a single event type description with no delivery guarantees.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar's webhooks are signed per the Standard Webhooks spec with SDK-side signature validation, typed payloads, and a Webhook Events API for endpoint management, plus delivery monitoring and Slack/Discord alerts. However, the evidence does not document automatic retry behavior for webhook deliveries specifically, nor event logs of delivery attempts, nor a replay/redeliver mechanism — the retry/dunning schedule cited is for failed payment charges, not webhook redelivery. missing for 10: explicit webhook delivery retry policy, delivery attempt/event log UI, and a replay/resend mechanism for missed webhooks.

   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

Onboarding dx

1. developerIntegrate a working payment flow from the docs alone in under a day, with copy-paste examples in my language

   weight 2 · round to Polar
   Autumn~partialcommunity6/10

   Docs provide multiple copy-paste TypeScript/JS snippets (check, track, attach, gating) and a CLI/config flow that suggest a fast path to a working payment flow, and community comments (comm-2, comm-5) reflect developers finding it appealing to integrate quickly. However all examples are JS/TS only (no other languages), there's no explicit hands-on confirmation of a 'under a day' integration timeline, and separate security reports (comm-6/7) show at least one integration built from the docs' approach ended up with an IDOR vulnerability, suggesting the docs alone may not guarantee a fully working/secure flow without extra care. Missing for 10: multi-language code samples, an independent hands-on report confirming rapid end-to-end integration, and evidence the documented flow is secure by default.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [community] “"I've suffered so much with all the pricing changes I've been experimenting with (early stage solo founder)... I'm going to integrate autumn…”
   • [community] “"love this as someone who's been fixing the same billing bugs over and over and who sometimes finds stripe more complex than it should be." …”
   • [community] “Security concern raised: Autumn's server actions were public, unauthenticated routes, meaning "a simple curl request with a different custom…”

   proof ↗⚑ flag

   Polar✓fullclaimed7/10

   Polar's docs provide copy-paste checkout flows (links, embed, session API), official TypeScript & Python SDKs, framework adapters, a full sandbox with test cards, local webhook testing CLI, and an explicit '6 lines of code' quick-start claim—together covering a realistic under-a-day integration path. Missing for 10: independent/hands-on confirmation of the 'under a day' timeline, broader language SDK coverage beyond TS/Python/adapters, and corroboration beyond first-party docs.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Framework adapters make it dead simple to add Polar checkouts and webhooks to your stack.”
   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “Payments & Billing with 6 lines of code. Open Source & Global Merchant of Record.”

   proof ↗⚑ flag

Sandbox fidelity

1. developerBuild and test the entire payment flow in a sandbox or test mode that mirrors production, with test cards for every scenario including declines and disputes

   weight 3 · round to Polar
   Autumn—none0/10

   No evidence in the pack mentions a sandbox/test mode, test cards, or simulated decline/dispute scenarios; Autumn's docs cover CLI, config, gating, webhooks, and MCP but nothing about a testing environment mirroring production payment flows. Since Autumn sits atop Stripe, this is a fair and applicable axis for a billing product, but it's simply undocumented here.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar documents a dedicated, isolated sandbox environment that mirrors the full checkout/customer funnel and supports Stripe test card numbers (e.g., 4242...), letting developers test payment flows without real money. However, evidence does not confirm dedicated test cards for every scenario (e.g., specific decline codes, dispute/chargeback simulation) — it relies on generic Stripe test cards with no documented list of scenario-specific cards or dispute-simulation tooling. missing for 10: explicit test-card matrix for various decline reasons, documented way to simulate disputes/chargebacks in sandbox, independent/hands-on confirmation of sandbox fidelity.

   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “To test Polar or work on your integration without worrying about actual money processing or breaking your live organization, you can use our…”

   proof ↗⚑ flag

Refunds

1. finance-ops userIssue full or partial refunds from both the dashboard and the API

   weight 3 · round to Polar
   Autumn—none0/10

   No evidence pack items mention refunds at all—no dashboard refund UI, no refund API endpoint, or partial-refund logic; docs cover checks, tracking, attach/subscriptions, credit systems, and CLI/MCP but never refunds.

   ⚑ flag

   Polar~partialclaimed6/10

   Polar's docs explicitly state that full and partial refunds can be issued regardless of refund policy (polar-docs-25), and the product exposes a general typed API/SDK for all resources (polar-docs-23), implying refund actions are API-accessible. However, no evidence explicitly confirms a dedicated refunds API endpoint or dashboard refund UI walkthrough — missing for 10: explicit refunds API endpoint documentation, dashboard UI screenshot/flow evidence, and independent confirmation that partial refund amounts can be specified via API.

   • [claimed-docs] “No matter what refund policy you offer to customers, Polar makes it easy to issue both full and partial refunds”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

Multi currency

1. founderCharge customers in their local currencies and settle to my bank in mine with transparent FX handling

   weight 2 · round drawn
   Autumn—none0/10

   No evidence in the pack addresses multi-currency charging, FX conversion, or settlement to a founder's home currency; documentation covers pricing models, metering, and Stripe catalog sync only. Community threads even highlight Autumn's dependency on Stripe alone with no other payment processors, but nothing on currency/FX handling either way.

   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”
   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's docs cover MoR tax handling, payouts, and pricing plans, but none of the evidence describes charging customers in their local currency or explains FX conversion/settlement transparency — payouts are described only in terms of a single 'account currency' threshold, with no mention of multi-currency checkout or FX rate disclosure.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Autumn~partialprobed6/10

   Autumn exposes a broad API (check, track, attach, credit systems, usage-based pricing) plus a CLI (`atmn push/pull/preview`) that can define and sync pricing config as code, and an MCP server for AI-native access to billing/customer/plan tools — strong evidence of API-driven control. However, the docs also show a 'pull' workflow for dashboard-created products, implying some setup still originates in the dashboard UI, and there's no explicit statement or independent test confirming full 1:1 parity between every UI action and API/CLI capability. Missing for 10: explicit parity documentation or proof that all dashboard-only actions (e.g., initial product/catalog creation, Stripe processor linking) are fully replicable via API/CLI without ever touching the UI, and independent verification of this parity.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Credit systems let you track actions with different credit costs from a single balance pool.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

   proof ↗⚑ flag

   Polar~partialprobed7/10

   Polar documents a broad, versioned API/SDK surface covering checkout, subscriptions, meters/usage billing, customer state, webhooks, refunds, and payouts, plus an official MCP server letting agents 'look up data and take actions across your products, customers, subscriptions, orders, benefits, and more' without needing the UI, and agent-legible docs (llms.txt, OpenAPI specs). However, no explicit vendor statement guarantees 1:1 UI/API parity, some dashboard-only mentions (e.g., 'create and manage your meters from the dashboard') aren't cross-confirmed with an API equivalent in the pack, and root-level openapi.json probes 404'd (spec is only reachable via versioned docs paths). Missing for 10: an explicit parity claim/audit, confirmation every dashboard action (e.g., payouts, balance views) has a documented API call, and independent corroboration of full API/UI equivalence.

   • [claimed-docs] “Customer State is a concept allowing you to query for the current state of a customer, including their active subscriptions and granted bene…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “"Polar has a powerful Usage Based Billing infrastructure that allows you to charge your customers based on the usage of your application. Th…”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Autumn—none0/10

   Autumn's docs show CLI sync/pull for pricing config (autumn.config.ts) and webhooks for event data, but there is no documented feature for exporting all customer/usage/billing data in an open format to allow a user or team to leave the platform. missing for 10: a documented full data-export or account-portability feature, open-format bulk export of customer/usage records, evidence of data portability upon offboarding.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   proof ↗⚑ flag

   Polar—none0/10

   Polar is a merchant-of-record billing/payments platform; the evidence pack covers API access, webhooks, MCP, and OpenAPI specs for developers to integrate with, but there is no mention of a data export feature letting a user (customer or merchant) export all of their own data (orders, subscriptions, customer records, transaction history) in an open, portable format for the purpose of leaving the platform. Having an API is not the same as a documented bulk data-export/portability capability.

   ⚑ flag

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

   weight 2 · round to Polar
   Autumn~partialprobed3/10

   The only evidence is a fragment from Autumn's llms.txt describing it as 'Drop-in, open-source control layer for AI and Sa[aS]', suggesting an open-source posture, but there is no link to an actual repository, license file, or license type (e.g., MIT/Apache) in the evidence pack, and no independent confirmation of a public code repo. Missing for 10: a direct GitHub/source repo link, an explicit license name/file, and corroboration that the full source (not just docs) is publicly readable.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.useautumn.com/llms.txt # Autumn - [Welcome to Autumn](https://docs.useautumn.com/welcome.md): Drop…”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar's own repo (github.com/polarsource/polar) is documented as open source under Apache-2.0 with 10k+ stars, meaning the product's source is publicly readable under a permissive OSI license, and this is reinforced by docs/site language positioning Polar as 'Open Source & Global Merchant of Record.' missing for 10: no independent third-party audit of license file contents or contribution history beyond the single citation.

   • [claimed-docs] “Polar is open source: the platform itself is developed in the open at github.com/polarsource/polar (Apache-2.0, 10k+ stars), positioning its…”
   • [claimed-docs] “Payments & Billing with 6 lines of code. Open Source & Global Merchant of Record.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Polar
   Autumn—none0/10

   Autumn's docs describe it as an 'open-source control layer' (autumn-probe-1), which would make self-hosting a fair question, but the evidence pack contains no self-hosting guide, Docker/deployment instructions, or infrastructure requirements — all documentation and CLI references (atmn, MCP, API) point to using Autumn as a hosted SaaS. missing for 10: self-host deployment docs, infrastructure/Docker setup instructions, confirmation of a self-hostable server component.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.useautumn.com/llms.txt # Autumn - [Welcome to Autumn](https://docs.useautumn.com/welcome.md): Drop…”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

   Polar's core codebase is confirmed open source (Apache-2.0, 10k+ stars on GitHub) which technically permits self-hosting, but the evidence contains no documented self-hosting guide, deployment instructions, or Docker/infra setup for running the full platform independently — and the core value proposition (Merchant of Record tax handling, payment processing) inherently depends on Polar's own hosted compliance/payment infrastructure, which cannot be self-hosted. Missing for 10: explicit self-hosting documentation/tutorial, confirmation that MoR/tax/payment features work outside Polar's hosted service, and any community reports of successful self-hosted deployments.

   • [claimed-docs] “Polar is open source: the platform itself is developed in the open at github.com/polarsource/polar (Apache-2.0, 10k+ stars), positioning its…”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “As the Merchant of Record, Polar takes care of charging customers, so Stripe Payments doesn't need to be available in your country.”

   proof ↗⚑ flag

Marketplace

1. developerBuild a marketplace or platform that onboards sellers, splits payments between parties, and pays out to each seller

   weight 2 · round drawn
   Autumn—none0/10

   Autumn's evidence focuses entirely on single-party SaaS billing—metering, plans, entitlements, customer subscriptions via Stripe—with no mention of multi-party marketplace features like seller onboarding, payment splitting, or payouts (e.g., Stripe Connect-style functionality). No evidence pack item addresses marketplace/platform payment distribution.

   ⚑ flag

   Polar—none0/10

   Polar's evidence describes single-organization merchant-of-record billing, payouts, and balances for one seller, but nothing about onboarding multiple sellers/sub-accounts, splitting a single transaction's proceeds between parties, or a Connect-like marketplace primitive. The axis is plausible for a payments platform, but no evidence supports multi-seller marketplace functionality.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Autumn—none0/10

   Autumn is a billing/entitlements infrastructure product, and its own telemetry/tracking APIs (track, check) are core product features for customer usage billing, not analytics on the developer's own usage of Autumn itself—so the axis of opting out of Autumn's own telemetry collection about its users is applicable but no evidence addresses it. No docs, changelog, or community evidence mention any telemetry opt-out, privacy settings, or data collection disclosure for Autumn's own tooling (CLI, SDK, MCP). missing for 10: any privacy policy or opt-out mechanism documentation, any mention of what usage data Autumn collects from its own users, any CLI/SDK flag to disable telemetry.

   ⚑ flag

   Polar—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out; Polar's docs focus on billing, checkout, MCP, webhooks, and merchant-of-record features with no mention of a privacy/telemetry setting.

   ⚑ flag