TaxJar vs Kintsugi

Agent access

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

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Direct probes show no llms.txt (404) and no discoverable OpenAPI spec, and no evidence of agent-oriented documentation exists anywhere in the pack.

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

   proof ↗⚑ flag

   Kintsugi✓fullprobed8/10

   A probe confirms llms.txt is live and served (HTTP 200) with a clear description of the docs, and Kintsugi also documents an official MCP server that gives AI assistants direct access to its API documentation. Together these show agent-oriented docs access is explicitly supported. missing for 10: no independent third-party confirmation of agent usage/quality beyond the vendor's own probe and docs, and no evidence of a machine-readable openapi.json to complement llms.txt (404s on candidate paths).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trykintsugi.com/llms.txt # Kintsugi Developer Docs > Automated sales tax compliance, by API. Calcu…”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

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

   weight 2 · round to TaxJar
   TaxJar✓fullprobed6/10

   TaxJar exposes a full REST API with API-key auth and official client libraries in seven languages, which supports headless/CI automation for tax calculations, transaction uploads, and nexus tracking. Missing for 10: no published OpenAPI/Swagger spec or llms.txt (both probes 404), no explicit CI/CLI examples or independent hands-on automation reports.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed6/10

   Kintsugi is API-first: it exposes a REST API and five official SDKs plus configurable API keys, making it straightforward to call from scripts or CI pipelines without a UI. However, there is no explicit CLI, headless-mode documentation, or CI-specific guidance (e.g., GitHub Actions examples) confirming automated pipeline use. Missing for 10: dedicated CLI/headless tooling, CI/CD integration examples, and explicit 'automation' framing beyond generic API/SDK access.

   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “Choose when the key should expire: Never, One Month, Six Month, or One Year.”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trykintsugi.com/llms.txt # Kintsugi Developer Docs > Automated sales tax compliance, by API. Calcu…”

   proof ↗⚑ flag

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

   weight 3 · round to Kintsugi
   TaxJar—none0/10

   TaxJar is a SaaS tax API/service, so an official MCP server is a fair question, but evidence only shows a traditional REST API with language SDKs, no MCP server; probes for llms.txt and OpenAPI spec both returned 404s, indicating no AI-native integration surface.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed6/10

   Kintsugi documents an official MCP server that gives AI assistants direct access to its API documentation for building integrations, confirmed by both docs and a probe hit. However, the described purpose is limited to documentation/code-example access rather than full agentic action (e.g., invoking tax calculations, registrations, filings via MCP), and there's no independent/hands-on corroboration of its use. Missing for 10: evidence of MCP-driven actions beyond docs lookup, independent verification of setup/usage, and details on tool/action coverage via the server.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence of an official CLI tool; TaxJar offers API clients in several languages but nothing resembling a command-line interface, and probes for openapi/llms.txt failed, suggesting no such tooling exists.

   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Kintsugi offers SDKs, REST API, and an MCP server for docs access, but no evidence of an official CLI tool being published or documented anywhere in the evidence pack.

   ⚑ flag

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

   weight 3 · round to Kintsugi
   TaxJar✓fullprobed7/10

   TaxJar documents a full public REST API with API-key auth, versioned headers, and official client libraries in seven languages, covering rate lookups, transaction upload, and tax code parameters — clearly a documented public API for programmatic/agentic use. missing for 10: no discoverable OpenAPI/Swagger spec or llms.txt (probes returned 404s), and no independent/hands-on corroboration of API usability beyond vendor docs.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi✓fullprobed8/10

   Kintsugi documents a REST API with numerous endpoints (nexus, registrations, filings, exemptions, tax estimate), five official SDKs generated from an OpenAPI spec, API key management, and an llms.txt for AI-native discovery, plus an MCP server exposing docs to AI assistants. Missing for 10: a publicly reachable OpenAPI/swagger spec (probe found all candidate paths 404) and independent third-party corroboration of API robustness.

   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [claimed-docs] “Choose when the key should expire: Never, One Month, Six Month, or One Year.”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trykintsugi.com/llms.txt # Kintsugi Developer Docs > Automated sales tax compliance, by API. Calcu…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

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

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   TaxJar's docs only describe a single API key mechanism with no mention of scoped, least-privilege, or per-agent credential issuance; no OAuth scopes, roles, or granular permission tokens are evidenced, and OpenAPI/llms.txt probes returned 404.

   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialclaimed4/10

   Kintsugi lets users create API keys with configurable expiration windows (Never/1mo/6mo/1yr), which supports time-boxing credentials, but there's no evidence of scoped/permission-based least-privilege controls (e.g., read-only vs write, endpoint-level restrictions) for issuing to an agent specifically. The MCP server only exposes API docs to assistants, not credential-scoping. Missing for 10: permission/role-based scoping of API keys, agent-specific credential issuance workflow, and documentation tying key creation to least-privilege agent use cases.

   • [claimed-docs] “Choose when the key should expire: Never, One Month, Six Month, or One Year.”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Kintsugi
   TaxJar✓fullprobed7/10

   TaxJar documents official API clients across seven languages (Ruby, Python, PHP, Node, C#/.NET, Java, Go) with API key auth and versioned headers, giving AI-native developers concrete official SDKs to build against. Missing for 10: no public OpenAPI spec or llms.txt (both probes 404), and no independent/hands-on corroboration of SDK quality or completeness.

   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi✓fullprobed8/10

   Docs explicitly confirm five official SDKs (Python, TypeScript, Java, PHP, Ruby) generated from a shared OpenAPI spec, plus REST API docs and an official MCP server for AI-assisted integration. Missing for 10: independent/hands-on corroboration of SDK quality and a publicly reachable OpenAPI spec (probe found 404s on candidate URLs).

   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence of any webhook or event-subscription capability in TaxJar's API docs; only REST API key access, client libraries, and integrations are documented, with no mention of webhooks.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”

   proof ↗⚑ flag

   Kintsugi—none0/10

   No evidence pack item mentions webhooks, event subscriptions, or push notifications; Kintsugi's documented integration model is REST API/SDK polling and connector sync, not event-driven webhooks.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence of AI-generated insights, recommendations, or in-product analytics powered by AI; the nexus threshold tracker (taxjar-docs-7/8) is rule-based reporting, not AI-generated. Missing for 10: any mention of AI/ML-driven insights, natural-language summaries, or suggestion features within TaxJar.

   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Kintsugi's evidence shows nexus/threshold determination logic and an MCP server aimed at helping developers build integrations with accurate API docs, not AI-generated insights or suggestions surfaced to end users from their own data. No feature is described that analyzes user data and proactively generates recommendations or insights within the product UI.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

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

   weight 2 · round to Kintsugi
   TaxJar~partialclaimed4/10

   TaxJar's AutoFile feature runs autonomously in the background to file and remit state tax returns without manual intervention, which is a genuine 'set-and-forget' automation. However, this is a single fixed built-in feature rather than a general automation framework letting AI-native users configure their own triggers/workflows, and there is no evidence of webhooks, scheduled jobs, or agent-friendly automation tooling beyond the core API. Missing for 10: general-purpose automation/trigger framework, webhook or event-driven automation support, evidence of AI-agent-configurable workflows beyond AutoFile.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi~partialprobed5/10

   Kintsugi's connectors auto-sync transactions and its tax engine autonomously computes nexus, tracks exposure, and can register/file across jurisdictions once configured (kintsugi-docs-1, kintsugi-docs-15), which is background automation, but this is standard SaaS integration behavior rather than a user-defined 'automation' or agentic workflow builder, and the MCP server is scoped only to serving API docs to coding assistants, not orchestrating autonomous tasks (kintsugi-docs-6, kintsugi-probe-3). Missing for 10: evidence of a configurable automation/workflow engine, scheduling or trigger-based agent tasks, and any AI-agent-driven autonomous execution beyond passive data sync.

   • [claimed-docs] “Dozens of prebuilt connectors cover shopping carts, billing systems, ERPs, and accounting platforms. Pick your platform, authorize it once, …”
   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   TaxJar—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Kintsugi—none0/10

   Kintsugi's evidence only describes an MCP server that lets external AI assistants read its API documentation for developers building integrations (kintsugi-docs-6, kintsugi-probe-3) — this is not a built-in assistant inside the product that end users can delegate tasks to. No feature resembling an in-app AI assistant, chat, or task-delegation UI is documented anywhere in the pack.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

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

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   No evidence of any natural-language interface, chatbot, or NL command layer; TaxJar exposes only a traditional REST API with SDKs, and probes for llms.txt/OpenAPI discovery artifacts returned 404s. Missing for 10: any NL command support, conversational interface, or agent-friendly API documentation.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed3/10

   Kintsugi ships an official MCP server, but per its own docs it only gives AI assistants access to API documentation/code examples for building integrations—it does not let a user perform actual operations (sync transactions, create registrations, file exemptions) via natural-language commands. Missing for 10: an MCP/agent interface that executes real product actions (nexus checks, filings, registrations) via natural language, evidence of end-to-end task completion through NL commands, independent corroboration of agentic use.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   No evidence of an interactive API reference with runnable examples; probes for llms.txt and OpenAPI spec both returned 404, and docs only describe static API reference content and client libraries.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”

   proof ↗⚑ flag

   Kintsugi~partialprobed4/10

   Kintsugi has structured API reference pages (get-nexus-for-org, create-registration, get-filings, create-exemption) and SDKs generated from an OpenAPI spec, suggesting a formal reference exists, but no evidence explicitly confirms an interactive 'try it out' console or runnable code examples, and probes for a public openapi.json spec returned 404s. missing for 10: explicit confirmation of in-browser runnable/try-it examples, working public OpenAPI spec endpoint, independent corroboration of interactivity.

   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

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

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Direct probes for llms.txt and common OpenAPI/Swagger spec paths all returned 404, and no documentation references a downloadable machine-readable API spec; only client libraries and reference docs are mentioned.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”

   proof ↗⚑ flag

   Kintsugi!disputedcontradicted3/10

   Docs assert an OpenAPI spec underlies the SDKs and API reference (kintsugi-docs-10), but a direct probe for standard OpenAPI/Swagger download endpoints (openapi.json, swagger.json, etc.) returned 404 everywhere (kintsugi-probe-2), so no machine-readable spec is actually downloadable. Missing for 10: a working, publicly downloadable OpenAPI/Swagger file or documented export endpoint, and independent confirmation of successful spec retrieval.

   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   TaxJar—none0/10

   No evidence pack mentions a sandbox, test mode, or non-production environment for the TaxJar API; only production API usage, keys, and integrations are documented.

   ⚑ flag

   Kintsugi—none0/10

   No evidence pack mention of a sandbox/test environment, test API keys, or staging mode distinct from production; docs cover connectors, SDKs, nexus, and MCP for docs access but nothing about isolated testing without touching production data.

   ⚑ flag

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

   weight 2 · round to TaxJar
   TaxJar~partialprobed3/10

   TaxJar's API requires an 'x-api-version' header, indicating some form of API versioning exists, but there is no documented deprecation policy, changelog, or sunset timeline evidenced anywhere in the pack. Probes for OpenAPI spec and llms.txt both failed (404), further limiting machine-readable API contract discovery for AI-native tooling. Missing for 10: documented deprecation/sunset policy, changelog of version changes, OpenAPI/machine-readable spec, and any evidence of long-term version support commitments.

   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Evidence shows a REST API, SDKs generated from an OpenAPI spec, and API key management, but no mention anywhere of API versioning scheme or a documented deprecation policy; the OpenAPI spec itself couldn't even be located via probing. missing for 10: explicit API version numbering/headers, a deprecation/sunset policy document, changelog or migration guidance for breaking changes.

   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   TaxJar~partialclaimed3/10

   The API docs vaguely mention that you can "upload transactions" via the API, hinting at bulk transaction import, but there is no documented batch/bulk endpoint, CSV import spec, or rate-limit guidance for large-scale calls. Missing for 10: explicit bulk/batch API endpoint documentation, throughput/rate-limit specs for large batches, and any first-party or independent evidence of successful bulk operations at scale.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed3/10

   Kintsugi's API supports syncing large volumes of transaction data (a full year's worth) and offers paginated list endpoints (e.g., Get Filings, Get Nexus for Org), which implies handling many records, but there is no documented bulk/batch endpoint for creating or updating multiple exemptions, registrations, or other items in a single call. Missing for 10: explicit bulk-create/bulk-update API endpoints, batch operation examples, and evidence of an AI agent orchestrating multi-item actions via MCP or SDK.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   TaxJar—none0/10

   TaxJar offers fixed automated behaviors (AutoFile filing, nexus threshold tracking) but there is no evidence of a user-configurable rules/trigger system letting an AI-native user define custom event-based automations; no webhooks, event API, or rule engine documented.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Kintsugi is a sales-tax compliance API with connectors, SDKs, and an MCP server for documentation access, but there is no evidence of a rules engine or event-triggered automation system where users define conditional actions on events. The MCP server only exposes API docs, not workflow/rule automation.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   TaxJar—none0/10

   TaxJar's evidence covers API access, AutoFile, nexus tracking, and integrations, but there is no mention of scheduling recurring jobs/workflows or any workflow-automation/cron-like feature for AI-native users. AutoFile is a fixed filing automation, not a user-schedulable job system. missing for 10: any scheduler/cron API, workflow orchestration, or recurring job configuration capability.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Kintsugi's docs describe automatic background transaction syncing and filing, but there is no evidence of an API, SDK, or MCP capability that lets an AI-native user explicitly schedule or configure recurring jobs/workflows (e.g., cron-like triggers, webhook-based automation, or workflow orchestration). The MCP server only exposes documentation access, not job scheduling. Missing for 10: any documented scheduling/automation API, recurring job configuration options, or workflow-orchestration tooling for AI agents.

   • [claimed-docs] “Dozens of prebuilt connectors cover shopping carts, billing systems, ERPs, and accounting platforms. Pick your platform, authorize it once, …”
   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

Certificate management

1. ops userExemption and resale certificates are managed end to end — collected from customers, validated, stored with expiry tracking, and applied automatically at calculation time

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   No evidence in the pack describes exemption/resale certificate collection, validation, expiry tracking, or automatic application at calculation time — the pack only covers tax rate/category APIs, AutoFile, nexus tracking, and integrations, none of which address certificate management.

   ⚑ flag

   Kintsugi~partialclaimed4/10

   Kintsugi has a Create Exemption API allowing exemption records with type, jurisdiction, and validity dates to be stored (kintsugi-docs-14), but there is no evidence of a customer-facing collection workflow (e.g., certificate upload portal), automated validation of certificate authenticity, expiry-based alerting, or documented automatic application of exemptions at tax-calculation time. missing for 10: customer-facing certificate collection/upload flow, validation logic against jurisdiction rules, expiry tracking/alerts, and documented automatic application of stored exemptions during tax calculation.

   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”

   proof ↗⚑ flag

Exempt customers

1. developerMark a customer or transaction exempt through the API — with the exemption reason carried through calculation, reporting, and the filed return

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   No evidence pack item mentions exemption certificates, exemption reasons, or marking customers/transactions exempt via the API — only generic API reference, product_tax_code, and AutoFile filing features are documented. Missing for 10: any mention of exemption_type/exemption_id parameters, exemption certificate storage/reporting, or exemption data flowing into filed returns.

   ⚑ flag

   Kintsugi~partialclaimed5/10

   Kintsugi documents a Create Exemption API that lets developers define exemption type, jurisdiction, and validity dates via the API (kintsugi-docs-14), and the tax estimate/calculation endpoint exists separately (kintsugi-docs-9), implying exemptions feed into tax calc. However there is no explicit documentation showing the exemption reason is carried through calculation, reporting dashboards, and the actual filed return — the pack never ties exemption records to reporting or filing outputs. Missing for 10: evidence that exemption reason propagates into tax reports and filed returns, and confirmation it applies per-transaction or per-customer at calculation time.

   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”

   proof ↗⚑ flag

Autofile

1. finance leadReturns are prepared, filed, and remitted automatically in every registered jurisdiction — on time, with the vendor's guarantee covering penalties if it files late

   weight 3 · round to TaxJar
   TaxJar~partialclaimed6/10

   TaxJar's AutoFile is explicitly documented to handle state tax returns and remittances with deadlines guaranteed, backed by a vendor guarantee (taxjar-docs-6), directly matching the core of the story. However, evidence doesn't clarify guarantee scope/terms (e.g., what penalties are covered, caps, exclusions), doesn't confirm coverage in every registered jurisdiction (state-only per wording), and there's no independent/hands-on corroboration of the guarantee being honored in practice. Missing for 10: detailed guarantee terms/limits, evidence of local/city jurisdiction filing beyond state level, and independent customer confirmation of guarantee payouts.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed5/10

   Docs confirm registration creation, filings retrieval, and marketing copy claiming Kintsugi 'registers you and files everywhere you sell,' indicating automated filing/remittance across jurisdictions. However, there is no explicit documentation of an on-time filing guarantee or penalty-coverage commitment, nor independent evidence corroborating the claim. missing for 10: explicit vendor guarantee/penalty-coverage terms, evidence of remittance execution (not just filing), independent/hands-on confirmation of on-time filing performance.

   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”

   proof ↗⚑ flag

Filing visibility

1. ops userSee the whole filing picture — a calendar of upcoming returns, per-filing status, the amounts remitted, and downloadable confirmations for every return submitted

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Evidence confirms AutoFile handles filing/remittance and nexus tracking, but there is no mention of a filing calendar, per-filing status view, remitted-amount reporting, or downloadable confirmations for submitted returns. missing for 10: filing calendar UI, per-filing status tracking, remittance amount reporting, downloadable filing confirmations.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed3/10

   Kintsugi's Get Filings API supports listing filings with status/date/jurisdiction filters, and Create Registration tracks filings across jurisdictions, giving some per-filing status visibility, but there is no evidence of a calendar view of upcoming returns, remitted amounts, or downloadable filing confirmations. missing for 10: calendar UI for upcoming returns, remittance amount tracking, downloadable confirmation documents for filed returns.

   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”

   proof ↗⚑ flag

Invoice compliance

1. ops userInvoices come out compliant where I sell — required VAT fields, registration numbers, and locale rules flow through to my invoicing system or are generated by the product itself

   weight 2 · round drawn
   TaxJar—none0/10

   TaxJar's evidence pack covers only US sales tax rates, categories, economic nexus tracking, and state tax return AutoFiling — there is no mention of VAT-specific fields, EU/international registration numbers, invoice generation, or locale-specific compliance rules for VAT jurisdictions. The axis is fair for a tax-compliance product, but no evidence shows TaxJar addresses VAT invoicing at all.

   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”
   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Evidence describes Kintsugi as a sales-tax/nexus compliance API (calculating tax, tracking nexus, registrations, filings, exemptions) but never mentions VAT-specific invoice requirements, required VAT fields, registration-number formatting, or locale invoicing rules for non-US jurisdictions.

   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”

   proof ↗⚑ flag

Vat coverage

1. founder selling internationallyVAT and GST are covered like US sales tax — EU OSS/IOSS, UK, Canada, Australia and beyond, with foreign registration thresholds tracked and filings supported

   weight 3 · round drawn
   TaxJar—none0/10

   All evidence describes US sales tax nexus tracking, AutoFile for state returns, and US-centric integrations; nothing addresses EU OSS/IOSS, UK VAT, Canada GST/HST, Australia GST, foreign VAT registration thresholds, or international filing support.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”

   proof ↗⚑ flag

   Kintsugi—none0/10

   The evidence pack only describes US-style sales tax nexus, registration, and filing APIs (with generic "Country" fields) but never mentions VAT, GST, EU OSS/IOSS, or specific UK/Canada/Australia regimes, so there is no proof Kintsugi extends its compliance engine to international VAT/GST obligations.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”

   proof ↗⚑ flag

Vat validation

1. developerB2B cross-border sales are handled correctly — VAT and tax IDs validated against official registries in real time, reverse charge applied when it should be

   weight 2 · round drawn
   TaxJar—none0/10

   TaxJar's evidence is entirely focused on US sales tax (economic nexus, AutoFile state returns, US integrations) with no mention of VAT, EU/UK tax ID validation, official registry checks (e.g., VIES), or reverse charge mechanics for B2B cross-border sales. Nothing in the docs or community evidence addresses global VAT compliance.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”

   proof ↗⚑ flag

   Kintsugi—none0/10

   The evidence pack shows Kintsugi handling US-style sales tax, nexus determination, exemptions, and filings, but contains no mention of VAT ID validation against official registries (e.g., VIES), reverse-charge mechanism handling, or any EU/cross-border B2B VAT-specific logic. This is an applicable axis for a tax-compliance product, but no evidence demonstrates it.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Tell Kintsugi where you have: Offices, stores, or warehouses, Employees or contractors, including remote staff working from home, Inventory …”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”

   proof ↗⚑ flag

Exposure analysis

1. finance leadImport my historical transactions and see where I already owe — a backdated exposure analysis with estimated liability, penalties, and interest per jurisdiction

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Evidence shows TaxJar can track economic nexus thresholds and upload/import transactions via API, but nothing describes a backdated exposure analysis with estimated liability, penalties, and interest per jurisdiction. Missing for 10: any mention of historical liability calculation, penalty/interest estimation, or jurisdiction-level backdated exposure reporting.

   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed5/10

   Kintsugi documents historical transaction import spanning the prior calendar year plus current, explicitly for nexus/threshold backdating (kintsugi-docs-3), and markets 'finds the exposure you didn't know you had' with nexus tracking APIs (kintsugi-docs-11, kintsugi-docs-15). However, no evidence describes computing estimated liability, penalties, or interest amounts per jurisdiction — only nexus/threshold detection and registration/filing tracking are documented. Missing for 10: explicit liability/penalty/interest calculation methodology, per-jurisdiction dollar exposure reporting, and any UI/report showing a backdated liability summary.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”
   • [claimed-docs] “Tell Kintsugi where you have: Offices, stores, or warehouses, Employees or contractors, including remote staff working from home, Inventory …”

   proof ↗⚑ flag

Threshold tracking

1. founderThe product watches my economic nexus exposure — tracking sales and transaction counts against every state and country threshold and alerting me before I cross one, not after

   weight 3 · round drawn
   TaxJar~partialclaimed6/10

   TaxJar's economic nexus dashboard tracks sales/transaction counts against state thresholds and 'pinpoints states where you've met economic nexus thresholds' (taxjar-docs-7, taxjar-docs-8), showing real-time progress like '$90k of $100k' and '125 of 200' transactions. However, evidence does not confirm proactive alerting BEFORE crossing a threshold (vs. after), nor coverage of country-level (international) thresholds as the story specifies. missing for 10: explicit pre-crossing alert/notification mechanism, international/country threshold tracking, independent user confirmation of alert timing.

   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed6/10

   Kintsugi syncs transactions and computes nexus by looking back across the trailing year, and exposes a nexus list endpoint, supporting economic nexus tracking against thresholds — but this evidence is entirely first-party docs with no independent/hands-on corroboration, and none of the pack explicitly describes proactive pre-crossing alerts (only that it 'determines nexus' and 'finds exposure you didn't know you had,' which reads more retrospective than predictive). missing for 10: explicit documentation of real-time threshold alerts/notifications before a crossing occurs, per-state/country threshold configuration detail, and independent confirmation the monitoring works as claimed.

   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”
   • [claimed-docs] “Dozens of prebuilt connectors cover shopping carts, billing systems, ERPs, and accounting platforms. Pick your platform, authorize it once, …”

   proof ↗⚑ flag

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

   weight 2 · round to Kintsugi
   TaxJar~partialprobed5/10

   Docs show a real API for tax calculation, categories, and transaction uploads, but no evidence that UI-only features like AutoFile automated filing or the economic nexus threshold dashboard are exposed via API, and probes confirm no public OpenAPI spec or llms.txt exists. missing for 10: API coverage for AutoFile/state filing, API for nexus threshold tracking/dashboard, machine-readable OpenAPI spec for full API discoverability.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”
   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed6/10

   Kintsugi's REST API/SDKs expose most core tax-compliance actions—nexus lookup, registrations, filings, exemptions, transaction sync, tax estimation, product categorization—that mirror the platform's main UI workflows, and it ships 5 official SDKs plus an MCP server for developer docs access. However there is no explicit documentation claiming full UI/API parity, no accessible OpenAPI spec (probe returned 404s), and management-type UI features (account/user settings, dashboard reporting, filing status changes) are not evidenced via API. Missing for 10: explicit parity statement, public OpenAPI spec, evidence covering all UI-only settings/admin functions.

   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   TaxJar—none0/10

   The evidence pack shows only API access for uploading/retrieving transaction and rate data, with no documented bulk data-export feature, open-format full account export, or data-portability tooling; probes for llms.txt and OpenAPI specs both failed (404s). Missing for 10: any documented full-account data export capability, open format (CSV/JSON) bulk export tool, or data portability/account closure export guarantee.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi—none0/10

   No evidence of any data export feature, open-format export, or account portability tooling; the only migration-related content describes importing from Avalara/TaxJar into Kintsugi, not exporting out. This axis is plausible for a SaaS compliance platform, but no supporting evidence exists.

   ⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or privacy/data lifecycle management for TaxJar's API or platform; documentation focuses solely on tax calculation, filing, and integrations.

   ⚑ flag

   Kintsugi—none0/10

   Kintsugi is a sales-tax compliance API; the evidence pack covers connectors, SDKs, nexus tracking, API keys, and MCP docs, but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle settings for AI-native users.

   ⚑ flag

Marketplace rules

1. finance leadMarketplace sales are modeled correctly — transactions where a facilitator (Amazon, app stores) collected the tax are tracked for nexus and reporting without being double-remitted

   weight 2 · round drawn
   TaxJar—none0/10

   The evidence pack shows TaxJar tracks economic nexus thresholds and integrates with Amazon FBA, but there is no documentation describing how marketplace-facilitator-collected transactions are flagged, excluded from remittance, or reported separately for nexus purposes — the exact capability the story asks about is unaddressed.

   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”

   proof ↗⚑ flag

   Kintsugi—none0/10

   No evidence describes handling of marketplace-facilitator-collected transactions (e.g., Amazon, app stores) for nexus tracking without double-remittance; docs cover general nexus threshold tracking, transaction sync, and filings but never mention facilitator tax collection status or how it's flagged/excluded from remittance while still counted toward nexus. Missing for 10: any mention of marketplace facilitator flag/field, guidance on excluding facilitator-collected sales from filings, or documentation of nexus counting facilitator sales without double remittance.

   ⚑ flag

Saas rules

1. founder selling softwareThe product gets the hard cases right — SaaS taxability that differs by state, digital-goods rules, and bundled offerings — with the research behind each determination visible

   weight 3 · round to Kintsugi
   TaxJar—none0/10

   Evidence only shows a generic `product_tax_code` parameter for categorizing line items, with no documentation of specific SaaS-taxability rules by state, digital-goods nuances, bundled-offering logic, or any visible research/citations behind determinations.

   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed3/10

   Kintsugi documents product-category/subcategory classification that determines tax treatment across jurisdictions, implying it handles SaaS/digital-goods taxability differences, but there is no evidence of bundled-offering handling or of visible research/citations backing each determination. missing for 10: bundled-offering tax logic, state-by-state SaaS taxability rules detail, visible research/sourcing behind each determination.

   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”

   proof ↗⚑ flag

Tax codes

1. developerMap my catalog to the vendor's tax categories — SaaS, digital goods, services, physical products — so each line item is taxed by what it is, in every jurisdiction it sells

   weight 2 · round drawn
   TaxJar~partialclaimed6/10

   TaxJar's API supports a `product_tax_code` parameter per line item, which maps catalog items to tax categories (e.g., SaaS, digital goods, services, physical goods) so each is taxed correctly per jurisdiction — this is the core mechanism for the story. However, evidence lacks a published/detailed taxonomy list of category codes, guidance on how many categories exist or how granular they are, and no independent/hands-on confirmation of correct jurisdictional tax application per category. missing for 10: full published category taxonomy/reference list, hands-on validation of correct per-jurisdiction tax outcomes by category, documentation on default categorization behavior when no code is supplied.

   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed6/10

   Kintsugi documents a product categorization system (category + subcategory) that determines tax treatment across jurisdictions, which directly addresses mapping catalog items to tax categories, and this feeds into its estimate/calculation endpoints. However, the evidence pack lacks detail on the actual taxonomy (whether SaaS, digital goods, services, physical goods are explicitly distinct built-in categories), how granular the mapping API is, or independent confirmation of jurisdictional accuracy. Missing for 10: explicit list/taxonomy of category types (SaaS/digital/services/physical), API reference for assigning categories per line item, and independent/hands-on validation of correct jurisdictional taxation.

   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can read my tax posture — nexus status, registrations, accrued liability, upcoming filings — and act on it through the API or an MCP surface with scoped credentials

   weight 3 · round to Kintsugi
   TaxJar~partialprobed3/10

   TaxJar has a documented REST API with API-key auth (docs-1,2,4) and a nexus-threshold tracking feature (docs-7,8), but evidence shows no API/agent access to registrations or accrued liability, no scoped/limited credentials beyond a flat API key, and no MCP surface — probes for llms.txt and OpenAPI discovery both failed (taxjar-probe-1, taxjar-probe-2). Missing for 10: API endpoints for registrations/accrued liability/filings, scoped/least-privilege credential model, any MCP server or agent-facing surface, independent confirmation of nexus data via API rather than dashboard-only.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “TaxJar uses API keys to allow access to the API.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed5/10

   The REST API and SDKs expose real tax-posture endpoints an agent could call — nexus list, registrations, filings, exemptions, tax estimates — and API keys support expiration-based scoping, so the API half of the story is solidly evidenced. However, Kintsugi's actual MCP server is documented as giving AI assistants access to API documentation for building integrations, not as an interface for reading or acting on live nexus/registration/filing data — so the 'MCP surface' part of the story is not delivered as described, only a docs-lookup MCP exists. Missing for 10: an MCP server (or API scope) that lets an agent directly read/act on nexus, registrations, accrued liability and filings rather than just fetch documentation; fine-grained credential scopes beyond key expiration; independent/hands-on confirmation of agentic use.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “Choose when the key should expire: Never, One Month, Six Month, or One Year.”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

Builtin ai

1. founderThe product ships its own AI for tax questions — is this product taxable in this state, why did this invoice tax this way — answering from its rule base with citations, not a generic chatbot

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence of any AI/chatbot feature answering nexus or invoice-taxation questions with citations; evidence pack only covers API endpoints, AutoFile, nexus threshold tracking dashboards, and integrations. Probe results even show missing llms.txt/openapi discoverability artifacts, and there's no mention of an AI assistant anywhere in docs or community items.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.taxjar.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi—none0/10

   Evidence shows Kintsugi's MCP server exposes API documentation for developers building integrations, not an AI agent answering founder-facing tax questions like nexus or invoice-taxation rationale with citations to a rule base. No docs describe a conversational/Q&A tax-explanation feature.

   • [claimed-docs] “Kintsugi's MCP server gives AI assistants direct access to our API documentation, making it easier for developers to build integrations with…”
   • [probe] “official MCP server documented at https://docs.trykintsugi.com/docs/mcp/getting-started”

   proof ↗⚑ flag

Accuracy guarantee

1. finance leadThe vendor stands behind its numbers — a documented accuracy guarantee or audit support commitment if a calculation it produced turns out wrong

   weight 2 · round drawn
   TaxJar—none0/10

   The only guarantee-related evidence concerns AutoFile ensuring filing deadlines are met, not calculation accuracy or audit support for erroneous tax calculations. No documentation in the pack describes a calculation-accuracy guarantee, indemnification, or audit-support commitment tied to TaxJar's tax rate/amount outputs.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”

   proof ↗⚑ flag

   Kintsugi—none0/10

   No evidence of an accuracy guarantee, audit support commitment, or liability coverage for incorrect tax calculations anywhere in the docs; the pack covers integrations, API endpoints, and connectors but nothing about accuracy warranties or audit defense.

   ⚑ flag

Calculation api

1. developerCalculate the right sales tax for a transaction through an API in real time — address-level (rooftop) accuracy, not ZIP-code approximations — fast enough to sit inside checkout

   weight 3 · round to Kintsugi
   TaxJar~partialprobed5/10

   Docs confirm a REST API with API keys, multi-language clients, and line-item/product_tax_code support for tax calculation, implying real-time rate lookups suitable for checkout integration, but no evidence explicitly addresses rooftop/address-level accuracy claims or documented latency/performance suitable for checkout timing. Missing for 10: explicit documentation of rooftop-level address accuracy vs ZIP approximation, published latency/performance benchmarks, independent/hands-on corroboration of real-time checkout use, and a working OpenAPI spec (probes returned 404s).

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed6/10

   Docs confirm a REST API (tax estimate endpoint POST /v1/tax/estimate) plus SDKs for real-time tax pricing before payment, and product categorization drives jurisdiction-specific taxation — supporting the core 'calculate tax via API' story. However, there is no explicit evidence of address-level (rooftop) precision versus ZIP-level approximation, and no documented latency/performance benchmarks confirming it's fast enough for checkout. missing for 10: explicit rooftop/address-level accuracy claims, latency/performance guarantees for checkout-speed use, independent verification of calculation accuracy.

   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trykintsugi.com/llms.txt # Kintsugi Developer Docs > Automated sales tax compliance, by API. Calcu…”

   proof ↗⚑ flag

Integrations

1. developerThere are maintained integrations for my revenue stack — billing systems, payment processors, and commerce platforms feed transactions in without me building the plumbing

   weight 2 · round to TaxJar
   TaxJar✓fullclaimed7/10

   TaxJar documents pre-built integrations for major commerce/payment platforms (Amazon FBA, BigCommerce, eBay, Magento 2, NetSuite, PayPal, Shopify, Square, Stripe, WooCommerce) plus official API client libraries in seven languages, directly addressing the plug-and-play revenue-stack integration story. Missing for 10: no independent/hands-on verification that these integrations are actively maintained/up-to-date, no evidence of a public integrations marketplace or update changelog, and no OpenAPI spec available (probe returned 404s) to assess developer experience depth.

   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”
   • [claimed-docs] “We currently provide API clients for the following languages: Ruby Sales Tax API, Python Sales Tax API, PHP Sales Tax API, Node Sales Tax AP…”
   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed6/10

   Kintsugi advertises dozens of prebuilt connectors for shopping carts, billing systems, ERPs, and accounting platforms, plus REST API/SDKs for custom integrations, which supports the 'no plumbing' claim. However, the evidence pack lacks a named list of specific maintained integrations (e.g., Stripe, Shopify) or independent confirmation of connector reliability/maintenance status. Missing for 10: a documented list of specific named connectors with maintenance status, and independent/hands-on validation that these prebuilt integrations work as advertised.

   • [claimed-docs] “Dozens of prebuilt connectors cover shopping carts, billing systems, ERPs, and accounting platforms. Pick your platform, authorize it once, …”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “Five official SDKs. Python, TypeScript, Java, PHP and Ruby, each published to its language's package registry and generated from the same Op…”

   proof ↗⚑ flag

Rate maintenance

1. ops userRate and rule changes across thousands of jurisdictions are the vendor's job — updates land automatically, are documented when they take effect, and never require me to redeploy

   weight 2 · round drawn
   TaxJar~partialclaimed4/10

   TaxJar's API model implies rates are served dynamically (docs-1, docs-4 x-api-version header) so calculations don't require client redeploys, and nexus/AutoFile features suggest ongoing compliance handling, but there's no explicit documentation of a rate/rule change log, update cadence, or effective-date notices for jurisdiction changes. Missing for 10: explicit changelog/documentation of when rate/rule updates take effect, confirmation of automatic jurisdiction coverage updates, and independent verification that no client-side action is ever needed.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “'x-api-version' must be specified in API call request headers.”
   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”

   proof ↗⚑ flag

   Kintsugi~partialclaimed4/10

   Kintsugi's architecture is API-based (tax estimate endpoint, product categorization engine) which implies tax logic lives server-side and calls always reflect the vendor's current rules without requiring integrator redeploys, but there is no explicit documentation about how often rates/rules are updated or how such changes are communicated/dated to customers. Missing for 10: a documented update cadence or changelog for jurisdiction rate/rule changes, and any statement that changes take effect with a timestamp/notice to ops users.

   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”
   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”

   proof ↗⚑ flag

Registration filing

1. ops userRegistering for a sales tax permit is handled in-product — the vendor files state and local registrations on my behalf with transparent per-registration pricing and status tracking

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Evidence only covers TaxJar's AutoFile service for filing state tax returns and remittances, and nexus threshold tracking — nothing about registering for sales tax permits (state/local registration filing) or per-registration pricing/status tracking. Missing for 10: any mention of permit registration service, registration pricing, or registration status tracking.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed5/10

   Kintsugi's marketing copy explicitly claims it 'registers you' for sales tax and files everywhere you sell, and the API exposes a Create Registration endpoint for tracking/managing registrations across jurisdictions, showing in-product registration handling exists. However there is no evidence of transparent per-registration pricing, and status tracking is only inferred from a generic API endpoint rather than documented UI/status flow. Missing for 10: per-registration pricing disclosure, detailed status-tracking workflow/UI evidence, and independent confirmation that Kintsugi actually files the registrations rather than just tracking them.

   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”

   proof ↗⚑ flag

Remediation

1. finance leadPast-due exposure has a remediation path — voluntary disclosure agreements or back-filing support to clean up jurisdictions where I should have been collecting

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   Evidence covers nexus tracking, AutoFile remittance, and API/integrations, but nothing addresses voluntary disclosure agreements (VDAs) or back-filing/remediation support for past-due, uncollected jurisdictions. Absence of evidence for this applicable capability means it is not shown to be delivered.

   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed4/10

   Kintsugi's marketing claims it 'finds the exposure you didn't know you had, registers you, and files everywhere you sell,' and nexus lookback plus registration APIs support identifying past-due exposure and creating registrations, but there is no explicit mention of voluntary disclosure agreements (VDAs) or back-filing of historical periods to clean up past liability. missing for 10: explicit VDA program or negotiation support, back-filing of historical/past-due returns, penalty/interest abatement guidance, any case study or documentation describing remediation of already-accrued exposure rather than just prospective registration and filing.

   • [claimed-docs] “Kintsugi finds the exposure you didn’t know you had, registers you, and files everywhere you sell with real people to support you whenever n…”
   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “Get a list of all nexuses for the organization.”

   proof ↗⚑ flag

Adjustments

1. developerRefunds and credit notes adjust tax correctly — negative amounts flow through liability, reporting, and the next filing without manual journal fixes

   weight 2 · round drawn
   TaxJar—none0/10

   No evidence pack item addresses refunds or credit notes, how negative amounts propagate through liability/reporting, or whether they auto-reconcile into the next filing without manual fixes. Evidence only covers general API usage, tax codes, AutoFile filing, and nexus tracking — none of which speaks to refund-specific tax adjustment. missing for 10: any documentation of a refund/credit-note API or workflow, confirmation that negative line items reduce liability correctly, and evidence that refunds are reflected in AutoFile filings without manual journal entries.

   ⚑ flag

   Kintsugi—none0/10

   The evidence pack covers transaction syncing, nexus tracking, filings, exemptions, and product categorization, but nothing addresses how refunds or credit notes with negative amounts are processed through liability, reporting, or filings. This is a fair question for a tax compliance API, so the axis applies, but no supporting evidence exists.

   ⚑ flag

Audit trail

1. ops userEvery calculation is reconstructable — the rate, rules, address resolution, and product category that produced each transaction's tax, retained and exportable for an audit

   weight 2 · round to Kintsugi
   TaxJar—none0/10

   The evidence pack shows TaxJar's API can return rates, categories, and accept product_tax_code parameters, but there is no documentation of a stored, exportable audit record showing the exact rate, rule, address resolution, and category used for each historical transaction's calculation. Nothing addresses retention or export of calculation provenance for audit purposes.

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “the TaxJar API allows you to submit a `product_tax_code` parameter with each `line_item` in an order.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed3/10

   Kintsugi documents product-category classification and a tax estimate/calculation endpoint, plus nexus, registration, exemption and filings APIs, but there is no evidence of a retained, per-transaction breakdown of rate/rules/address resolution or an export mechanism for audit reconstruction. missing for 10: documented storage of calculation inputs (rate, rule, address resolution) per transaction, an audit-log or export feature, and any mention of reconstructability for compliance audits.

   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”
   • [claimed-docs] “The tax estimate endpoint (POST /v1/tax/estimate) prices sales tax before you take payment.”
   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”

   proof ↗⚑ flag

Channel imports

1. developerTransactions from every channel can be imported — API backfills and connector syncs from other processors and storefronts — so filings cover my whole business, not just one integration

   weight 2 · round to TaxJar
   TaxJar✓fullprobed7/10

   TaxJar's API supports uploading transactions and backfilling data programmatically, and its documented integrations list covers major storefronts and processors (Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce), enabling multi-channel data consolidation for filings. This directly supports the developer story of importing transactions from multiple sources into one nexus/filing view. Missing for 10: no independent/hands-on verification of connector sync reliability across all listed platforms, no detail on how conflicting/duplicate transactions from multiple sources are reconciled, and no OpenAPI spec confirming full API backfill capabilities (probe endpoints 404).

   • [claimed-docs] “You can use our API to get information on sales tax rates, categories or upload transactions.”
   • [claimed-docs] “Amazon FBA, BigCommerce, Ebay, Magento 2, Netsuite, PayPal, Shopify, Square, Stripe, Woocommerce”
   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.taxjar.com/openapi.json, https://developers.taxjar.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Kintsugi~partialprobed6/10

   Docs confirm prebuilt connectors for carts, billing, ERPs, and accounting platforms plus a REST API/SDKs for backfilling historical transactions (previous full calendar year through today), which supports multi-channel coverage. However, there's no independent/hands-on corroboration of connector breadth or reliability, and OpenAPI spec probes 404, leaving API completeness unverified. Missing for 10: independent verification of connector list/reliability, working public OpenAPI spec, evidence of successful multi-source reconciliation in practice.

   • [claimed-docs] “Dozens of prebuilt connectors cover shopping carts, billing systems, ERPs, and accounting platforms. Pick your platform, authorize it once, …”
   • [claimed-docs] “Build against the REST API or an official SDK. Start with Planning an Integration to choose your integration level, then Syncing Transaction…”
   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.trykintsugi.com/openapi.json, https://docs.trykintsugi.com/swagger.json, https://docs.t…”

   proof ↗⚑ flag

Liability reports

1. finance leadSee accrued liability by jurisdiction at any moment — collected versus owed, filing-ready detail, and exports my accountant and GL can consume

   weight 2 · round to Kintsugi
   TaxJar~partialclaimed3/10

   Evidence shows nexus threshold tracking and AutoFile remittance/filing automation, which implies some jurisdiction-level tax handling, but there is no documentation of a liability report showing collected-vs-owed by jurisdiction, no mention of filing-ready detail views, and no export formats designed for accountants or GL consumption. missing for 10: collected-vs-owed liability dashboard, jurisdiction-level accrued liability reporting, GL/accountant-ready export formats, evidence of real-time 'at any moment' visibility.

   • [claimed-docs] “Tracking Economic Nexus Sales threshold: $90k of $100k Transaction threshold: 125 of 200”
   • [claimed-docs] “This tool will pinpoint states where you've met economic nexus thresholds.”
   • [claimed-docs] “AutoFile handles state tax returns and remittances for you, ensuring deadlines are never missed – all backed by our guarantee.”

   proof ↗⚑ flag

   Kintsugi~partialclaimed6/10

   Kintsugi provides nexus tracking, filings, registrations, and exemption APIs (get-filings, create-registration, get-nexus-for-org) that could surface liability by jurisdiction, and product categorization determines taxability, but there's no explicit documentation of a 'collected vs owed' liability dashboard or accountant/GL-ready export format. missing for 10: explicit accrued-liability-by-jurisdiction view/report, collected-vs-owed reconciliation feature, documented GL/accountant export formats (e.g. CSV/QBO/NetSuite journal entries), independent confirmation of filing-ready detail accuracy.

   • [claimed-docs] “Get a list of all nexuses for the organization.”
   • [claimed-docs] “The Create Registration API allows users to create a new registration for tracking and managing tax filings efficiently across multiple juri…”
   • [claimed-docs] “The Get Filings API retrieves a paginated list of filings based on filters such as dates, jurisdiction, Country, status, etc.”
   • [claimed-docs] “The Create Exemption API allows you to create a new exemption record. This includes defining details such as exemption type, jurisdiction, C…”
   • [claimed-docs] “Kintsugi classifies every product into a category and subcategory, which together determine how it is taxed across jurisdictions.”
   • [claimed-docs] “Send transactions covering the previous full calendar year through today. Kintsugi determines nexus by looking back across that window, so w…”

   proof ↗⚑ flag