Anrok vs Kintsugi

Agent access

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

   weight 2 · round to Kintsugi
   Anrok—none0/10

   A direct probe for llms.txt returned 404, and no agent-oriented docs endpoint was found; OpenAPI probes also failed. No evidence supports pointing an agent at machine-readable docs.

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

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

   Anrok is explicitly headless/API-first ('Run tax through Anrok's APIs, or hand it to your agents') with a full REST API covering customers, transactions, certificates, filings, and tax calculation that can be scripted for automation/CI pipelines. Missing for 10: explicit CI/CD pipeline examples, official SDKs/CLI tooling, and a working machine-readable openapi.json/llms.txt (probes show 404s) that would make automated integration turnkey.

   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [claimed-docs] “Retrieves a customer by its ID.”
   • [claimed-docs] “Lists the customers on your seller account, in ascending customer ID order.”
   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   Anrok exposes a REST API and mentions 'hand it to your agents' but there is no evidence of an official MCP server for connecting AI agents; llms.txt and openapi probes both 404.

   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   Anrok offers an API and headless tax product, but no evidence of an official CLI tool; probes for llms.txt and openapi endpoints both returned 404s, and no docs mention a CLI.

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

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

   Anrok exposes a well-documented public API covering customers, certificates, tax calculation, transactions, filings, and product mappings, with a dedicated tutorials/integration overview and OpenAPI spec referenced, plus explicit messaging that agents can be handed the API ("Run tax through Anrok's APIs, or hand it to your agents"). Missing for 10: independent third-party corroboration of API usage and confirmation of a discoverable machine-readable spec (probe found openapi.json/llms.txt 404s despite an openapi.yaml reference).

   • [claimed-docs] “Retrieves a customer by its ID.”
   • [claimed-docs] “Lists the customers on your seller account, in ascending customer ID order.”
   • [claimed-docs] “This tax amount can be estimated using Anrok's createEphemeral endpoint and should be refreshed any time the customer changes something”
   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   No evidence of API key scoping, permission levels, or credential issuance mechanisms for agents; docs describe tax API endpoints but nothing about least-privilege or scoped credential issuance.

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

   Evidence shows Anrok has a REST API with OpenAPI schema references, but there is no mention of official client SDKs (e.g., Python, Node, Java libraries) for developers to build against; probes even show openapi.json/llms.txt discovery paths returning 404, suggesting no packaged SDK or machine-readable spec artifact is publicly distributed. missing for 10: named official SDK packages, language-specific client libraries, SDK installation/quickstart docs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”
   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”

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

   No evidence of any webhook subscription mechanism; all documented capabilities are REST endpoints for customers, transactions, filings, and certificates, with no mention of webhooks or event subscriptions.

   ⚑ 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 to Anrok
   Anrok✓fullclaimed7/10

   Anrok's AI Atlas feature explicitly lets users ask natural-language questions about their sales tax and receive AI-generated answers with reasoning, grounded in their own transactions, registrations, filings, and certificates. This directly matches the story of getting AI-generated insights from within the product's own data. Missing for 10: independent/hands-on corroboration of AI Atlas quality, and more detail on the range/depth of insights or suggestions beyond Q&A.

   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

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

   Anrok's marketing mentions background automations like automatic jurisdiction registration completion, early tax-obligation alerts, and a headless API that can be 'handed to your agents,' implying some autonomous background processing (tax calc, filings, registrations). However there's no evidence of a user-configurable automation builder or explicit agentic scheduling system that an AI-native user could set up themselves. Missing for 10: documentation of a user-facing automation/workflow builder, evidence of agent-triggered autonomous tasks beyond marketing claims, and independent confirmation these run without manual oversight.

   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”
   • [claimed-docs] “Early alerts before you owe anywhere”
   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”

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

   Anrok's 'Atlas' feature is described as a built-in AI assistant that lets users 'ask it anything about your sales tax' with reasoning grounded in the customer's own transactions, registrations, filings, and certificates, and the 'headless-tax' page mentions handing tax work 'to your agents.' However, evidence is limited to marketing copy about answering questions and general agent-friendliness, without documentation of the assistant executing multi-step tasks (e.g., filing, remediation) autonomously. Missing for 10: concrete examples of the assistant taking action (not just Q&A), technical/architecture docs on the assistant's task-execution scope, and independent/hands-on verification of its capabilities.

   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

   proof ↗⚑ 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 Anrok
   Anrok~partialclaimed5/10

   Anrok's AI Atlas feature lets users 'ask it anything about your sales tax' and get grounded answers, showing a natural-language query interface, and headless-tax mentions handing tax operations to agents. However, evidence only shows NL-based Q&A/insight retrieval, not full operational control (e.g., creating transactions, managing filings) via natural language commands. missing for 10: evidence of NL commands executing actions (not just queries), documentation of command syntax/scope, independent verification of AI Atlas performance.

   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

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

   The evidence pack shows Anrok's API docs describe endpoints (customers, tax IDs, address resolution, etc.) and reference an openapi.yaml spec, but nothing indicates an interactive reference with runnable/try-it examples; probes even show that common interactive-doc artifacts (openapi.json, swagger.json, llms.txt) return 404. Missing for 10: any mention of a 'try it' console, code sandbox, or runnable request builder in the docs.

   • [claimed-docs] “Retrieves a customer by its ID.”
   • [claimed-docs] “Lists the customers on your seller account, in ascending customer ID order.”
   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   Anrok's docs repeatedly reference a live openapi.yaml file (e.g., anrok-docs-4, anrok-docs-10-13) suggesting a machine-readable OpenAPI spec exists, but probes for common JSON/well-known OpenAPI paths and llms.txt all 404, and no direct confirmation of a downloadable spec file was found. Missing for 10: a verified working download link for openapi.yaml, an llms.txt or AI-friendly spec index, and independent confirmation the spec is complete/machine-consumable.

   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   No evidence pack item mentions a sandbox, test mode, or non-production environment for testing API integrations; the createEphemeral endpoint is described as a tax estimation tool, not a sandbox for isolating test data from production. Missing for 10: any mention of sandbox/test environment, test API keys, or documented separation between test and live data.

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

   No evidence of API versioning scheme or a documented deprecation policy anywhere in the docs pack; probes even show standard OpenAPI/discovery files returning 404. missing for 10: versioning scheme documentation, explicit deprecation policy, changelog or migration guides.

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

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

   Anrok's API supports listing customers and creating many-to-1 product mappings across a catalog, which implies some bulk-style operations, but there is no explicit documentation of batch create/update/delete endpoints or bulk transaction processing across many items at once. missing for 10: dedicated bulk/batch API endpoints, evidence of bulk certificate or transaction processing, and independent confirmation of scale handling.

   • [claimed-docs] “Lists the customers on your seller account, in ascending customer ID order.”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Anrok sellers only need to create product IDs for each unique tax category, not every single product in the catalog.”

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

   Anrok's evidence covers tax calculation APIs, certificate/registration tracking, and an AI Q&A assistant (AI Atlas), but nothing describes a user-defined rules engine that automatically triggers actions on events (e.g., 'if nexus threshold crossed, auto-register' as a configurable rule). 'Early alerts' and 'automatic registration completion' are pre-built product features, not user-definable trigger/action rules.

   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [claimed-docs] “Early alerts before you owe anywhere”

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

   Anrok is a tax compliance/API platform; no evidence describes any scheduling of recurring jobs or workflows (cron-like automation, scheduled syncs, recurring filings automation via API). Filings, registrations, and calculations are described as on-demand API calls or automatic processes, not user-schedulable recurring jobs.

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

   Anrok supports certificate collection and storage via UI/API, and pricing page states certificates are "collected, verified, and stored," with customer search enabling pre-billing certificate upload. However, there is no evidence of expiry tracking or explicit automatic application of certificates at tax-calculation time within the evidence pack. missing for 10: expiry tracking/alerting on certificates, explicit description of certificates being auto-applied during tax calculation, independent verification of the certificate workflow.

   • [claimed-docs] “creating it ahead of time makes the customer searchable by name in Anrok - for example, when uploading a tax exemption certificate before th…”
   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [claimed-docs] “Certificates collected, verified, and stored”

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

   Docs confirm certificates (which typically carry exemption reasons) can be uploaded via API alongside the calculation/transaction/return endpoints, implying exemption data could flow into the tax engine, but there is no explicit documentation of an API field to mark a customer/transaction exempt with a reason, nor confirmation that this reason is surfaced in reporting or on the filed return. Missing for 10: explicit API parameter/endpoint for setting exemption status+reason, and evidence that the reason appears in reports and filed returns.

   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [claimed-docs] “Certificates collected, verified, and stored”
   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”

   proof ↗⚑ 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 Kintsugi
   Anrok~partialclaimed3/10

   Evidence shows Anrok can fetch filings and supports automatic registration across jurisdictions, implying some filing automation, but there is no mention of remittance, on-time guarantee, or penalty coverage anywhere in the pack. missing for 10: explicit description of end-to-end return preparation/remittance workflow, guarantee language covering late-filing penalties, evidence of on-time filing across all registered jurisdictions.

   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”

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

   Evidence only shows a generic API endpoint to 'fetch filings' from Anrok, implying some filing-tracking capability, but there is no documentation of a calendar of upcoming returns, per-filing status detail, remitted amounts, or downloadable confirmations for submitted returns. Missing for 10: calendar view of upcoming filings, per-filing status detail, remitted amount reporting, downloadable filing confirmations.

   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”

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

   Anrok computes tax amounts, resolves jurisdictions/addresses, and collects/validates customer tax IDs per jurisdiction (docs-10, docs-11), which supports registration-number and locale-rule inputs into billing systems, but there is no evidence it generates or validates full compliant invoice documents (e.g., specific required VAT invoice fields, reverse-charge notices, locale formatting) itself. missing for 10: evidence of actual invoice-field/template compliance output, confirmation that generated invoices meet locale-specific legal requirements, and any hands-on/independent verification of this.

   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”

   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 to Anrok
   Anrok~partialclaimed6/10

   Evidence shows global exposure tracking (world exposure map, UK registration threshold tracker, tax obligations tracked across 13 countries, automatic registration in 13 jurisdictions) and filings API support, indicating international VAT/GST coverage beyond US sales tax. However, there's no explicit mention of EU OSS/IOSS schemes, Canada or Australia specifically, or detail on how foreign registration thresholds are tracked/filed beyond the UK example and generic '13 jurisdictions.' Missing for 10: explicit EU OSS/IOSS support, named coverage of Canada/Australia, and detailed foreign filing mechanics beyond dashboard alerts.

   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “Early alerts before you owe anywhere”

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

   Evidence shows Anrok collects and validates customer tax IDs for applicable jurisdictions (anrok-docs-10) and tracks global VAT obligations (anrok-docs-17, anrok-docs-18), but there is no evidence of real-time validation against official government registries (e.g., VIES) or of reverse-charge mechanics being automatically applied to B2B cross-border transactions.

   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”

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

   Evidence shows Anrok tracks nexus/exposure prospectively (world exposure map, registration threshold tracker, early alerts) but nothing describes importing historical transactions to backdate exposure or calculate estimated liability, penalties, and interest per jurisdiction. missing for 10: historical transaction import/backfill feature, backdated exposure calculation, penalty and interest estimation per jurisdiction.

   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Early alerts before you owe anywhere”

   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
   Anrok~partialclaimed6/10

   Anrok's marketing docs explicitly claim 'Early alerts before you owe anywhere' and show a world exposure map with a UK registration threshold tracker, indicating nexus monitoring across jurisdictions with proactive alerting. However, there is no detailed documentation of how thresholds are tracked per state/country, alert timing/mechanics, or transaction-count-based nexus logic. missing for 10: technical detail on threshold-tracking logic per state/country, transaction-count thresholds (not just revenue), alert delivery mechanics/timing, and independent/hands-on verification that alerts fire before crossing thresholds.

   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Early alerts before you owe anywhere”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”

   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 drawn
   Anrok~partialprobed6/10

   Anrok's API documentation covers most core operations (customers, certificates, transactions, tax IDs, address resolution, filings, product mappings) and it markets itself as 'headless tax' with 'one engine' powering both UI and API/agent workflows, suggesting strong parity. However, dashboard-style features (world exposure map, registration threshold tracker, AI Atlas natural-language assistant) are only described as UI experiences with no documented API equivalent, and probes show no discoverable OpenAPI spec or llms.txt for full API surface verification. Missing for 10: explicit statement/documentation of full UI-API parity, API access to dashboard/exposure-map and AI Atlas features, and a verifiable machine-readable API spec.

   • [claimed-docs] “Certificates can be uploaded to Anrok via the Anrok UI as well as via the API.”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

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

   There is no evidence of a bulk data export feature or open-format data portability (e.g., CSV/JSON export of all transactions, certificates, filings) for users to leave with their data; API endpoints only support fetching individual records via calls, not a full export mechanism, and probes for llms.txt/openapi.json artifacts returned 404s.

   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”
   • [claimed-docs] “Retrieves a customer by its ID.”
   • [claimed-docs] “Lists the customers on your seller account, in ascending customer ID order.”

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

   The evidence pack covers Anrok's tax calculation, filing, and certificate APIs but contains no mention of data retention policies, data deletion controls, or privacy/data lifecycle management features for AI-native users. No documentation addresses how users can control or delete stored data.

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

   No evidence pack items mention marketplace facilitator transactions, facilitator-collected tax tracking, or logic to avoid double-remittance on marketplace sales — the docs cover general transaction/refund/certificate APIs but nothing specific to marketplace facilitator nexus handling.

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

   Anrok's product-category mapping (docs-13, docs-14) shows it classifies products into tax categories, and AI Atlas (docs-15) lets users 'ask anything about sales tax' with reasoning shown, grounded in transactions/registrations/filings/certificates — suggesting visible research behind determinations. However, there's no direct evidence addressing the specific hard cases named (state-by-state SaaS taxability differences, digital-goods nuances, or bundled-offering treatment) or how the reasoning trail covers those scenarios. Missing for 10: explicit documentation of SaaS taxability variance by state, digital-goods rule handling, bundled-offering tax logic, and independent verification that Atlas's 'reasoning shown' actually resolves these edge cases correctly.

   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Anrok sellers only need to create product IDs for each unique tax category, not every single product in the catalog.”
   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

   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
   Anrok~partialclaimed6/10

   Anrok's API supports mapping catalog products to tax categories via product IDs and many-to-1 mappings (each unique tax category needs only one product ID), and jurisdiction-aware tax calculation/address resolution is documented. However, there's no explicit documentation showing the specific vendor tax category taxonomy (SaaS, digital goods, services, physical products) or a UI/API walkthrough of assigning each of those category types across jurisdictions. missing for 10: explicit list/definition of tax category taxonomy (SaaS vs digital goods vs services vs physical goods), concrete UI/API example mapping catalog items to these categories, independent corroboration of category-based jurisdictional taxation accuracy.

   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Anrok sellers only need to create product IDs for each unique tax category, not every single product in the catalog.”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”

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

   Anrok's API exposes some relevant read/act endpoints (filings, tax-ID/registration lists, address resolution, transaction create/void/refund) and marketing for 'headless-tax' explicitly says you can 'hand it to your agents', plus AI Atlas offers grounded Q&A over transactions/registrations/filings/certificates. However there is no evidence of an MCP surface, no mention of scoped/limited API credentials, no explicit nexus-status or accrued-liability endpoint, and probes show llms.txt and openapi discovery endpoints 404ing, undercutting easy machine/agent onboarding. Missing for 10: MCP server or endpoint, scoped-credential/OAuth support, explicit nexus-status and accrued-liability read endpoints, working machine-readable API discovery (llms.txt/openapi).

   • [claimed-docs] “Anrok responds with the list of customer tax IDs to collect... Anrok provides a list of valid tax IDs for each applicable jurisdiction.”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”
   • [probe] “PROBE llms.txt: HTTP 404 at https://apidocs.anrok.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://apidocs.anrok.com/openapi.json, https://apidocs.anrok.com/swagger.json, https://apidocs.anro…”

   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 to Anrok
   Anrok✓fullclaimed7/10

   Anrok's 'AI Atlas' is explicitly described as answering sales-tax questions 'with the reasoning shown, grounded in your own transactions, registrations, filings, and certificates' — a purpose-built tax AI over its own rule/data base rather than a generic chatbot. Missing for 10: independent/hands-on validation of answer accuracy, detail on invoice-level 'why did this tax this way' explanations, and citation format specifics.

   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

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

   No evidence pack item mentions an accuracy guarantee, indemnification, warranty, or audit-defense/support commitment tied to Anrok's tax calculations; all citations cover API mechanics, product features, and dashboards. Absence of any documented guarantee for this applicable finance/tax axis yields 'none'.

   ⚑ 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 Anrok
   Anrok~partialclaimed7/10

   Anrok's API docs describe a createEphemeral endpoint for real-time tax estimation during checkout and a dedicated Address Resolution endpoint that normalizes a customer address to determine taxable jurisdiction(s), supporting rooftop-level (not ZIP-only) accuracy. However, there is no explicit performance/latency benchmark or independent hands-on confirmation that calls are fast enough for checkout-critical paths. Missing for 10: documented latency/SLA numbers for checkout use, independent/third-party verification of real-time performance, and explicit comparison against ZIP-code-level competitors.

   • [claimed-docs] “This tax amount can be estimated using Anrok's createEphemeral endpoint and should be refreshed any time the customer changes something”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”

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

   Anrok documents a Shopify integration (verifying Shopify's own tax calc) and a general API for transactions, customers, and product mappings, but the mapping endpoint (many-to-1 product mapping) and createOrUpdate/negation flows show developers still must build the plumbing to sync billing-system data rather than plugging into a pre-built connector library covering multiple billing/payment/commerce platforms. Missing for 10: a documented catalog of maintained native integrations (e.g., Stripe, Chargebee, Recurly, other commerce platforms) beyond Shopify, and evidence that these connectors sync automatically without developer-built API glue.

   • [claimed-docs] “Tax calculation through Shopify requires Shopify tax. Anrok recalculates and verifies Shopify's calculations to ensure accuracy.”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “Use createOrUpdate endpoint to create a negative transaction representing the refund.”
   • [claimed-docs] “Use createNegation endpoint to negate the original transaction. Use createOrUpdate endpoint to create a new version of the partially refunde…”
   • [claimed-docs] “Run tax through Anrok's APIs, or hand it to your agents. One engine powers all five jobs”

   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 to Kintsugi
   Anrok—none0/10

   The evidence pack covers API endpoints, certificates, filings, and dashboards, but contains no claims about automatic rate/rule updates across jurisdictions, no changelog or effective-date documentation, and no statement that customers never need to redeploy for rate changes. This is a fair and central axis for a tax-calculation vendor, but no supporting evidence exists.

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

   Anrok's marketing claims 'automatic registration completion in 13 jurisdictions' and an exposure/threshold tracker, suggesting some in-product registration handling, but there is no evidence of per-registration pricing transparency or a dedicated status-tracking workflow for permit filings. missing for 10: per-registration pricing disclosure, explicit status tracking UI/API for registrations, confirmation of full state/local filing scope.

   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”
   • [claimed-docs] “Early alerts before you owe anywhere”

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

   Evidence shows Anrok tracks exposure, thresholds, and sends early alerts before liability accrues, but nothing in the pack mentions voluntary disclosure agreements, back-filing support, or any remediation path for past-due/uncollected tax periods.

   ⚑ 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 to Anrok
   Anrok~partialclaimed6/10

   Anrok's API docs explicitly cover refund/credit-note workflows: createOrUpdate for negative transactions, createNegation for full negation plus a new corrected transaction for partial refunds, and each saved transaction is tied to the appropriate tax return, implying downstream liability and filing effects. However, there's no explicit evidence describing how these adjustments flow through reporting dashboards or that manual journal fixes are entirely eliminated across all reporting/filing steps. Missing for 10: explicit documentation or independent confirmation that negative amounts automatically reconcile in liability reports and filings without any manual reconciliation, and real-world/hands-on validation of this flow.

   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “Use createOrUpdate endpoint to create a negative transaction representing the refund.”
   • [claimed-docs] “Use createNegation endpoint to negate the original transaction. Use createOrUpdate endpoint to create a new version of the partially refunde…”
   • [claimed-docs] “Void can be used in cases where a customer transaction payment was unsuccessful or when the invoice needs to be canceled”

   proof ↗⚑ 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 Anrok
   Anrok~partialclaimed6/10

   Anrok's API retains transaction data (createOrUpdate/createNegation saved and tied to filings), address resolution is a distinct queryable endpoint, and product category mapping is stored per tax category; AI Atlas explicitly says answers are grounded in transactions, registrations, filings, and certificates, implying underlying data is retrievable. However, there's no explicit documentation of a per-transaction audit trail showing the exact rate and rule set applied, nor a dedicated export/audit report feature. Missing for 10: explicit rate/rule audit trail per transaction, a documented export function for audit purposes, and independent confirmation of reconstructability beyond docs claims.

   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “The Anrok Address Resolution endpoint resolves a customer address to its normalized form, suitable for sales tax calculations, as well as ta…”
   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Anrok sellers only need to create product IDs for each unique tax category, not every single product in the catalog.”
   • [claimed-docs] “Ask it anything about your sales tax and get an answer with the reasoning shown, grounded in your own transactions, registrations, filings, …”

   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 drawn
   Anrok~partialclaimed6/10

   Anrok's API clearly supports transaction ingestion (createOrUpdate, void, refund/negation endpoints) and product mapping across billing systems (anrok-docs-6,7,8,9,13), and it explicitly recalculates/verifies Shopify tax data (anrok-docs-19), showing at least one storefront connector beyond the core API. However, evidence does not show a broader library of connectors to other processors/storefronts (e.g., Stripe, other marketplaces) or explicit historical-data backfill tooling. missing for 10: documented connectors to multiple processors/storefronts beyond Shopify, explicit bulk/historical backfill API or import tool, independent confirmation of multi-source coverage.

   • [claimed-docs] “this endpoint also saves the transaction in Anrok and associates it with the appropriate tax return”
   • [claimed-docs] “Void can be used in cases where a customer transaction payment was unsuccessful or when the invoice needs to be canceled”
   • [claimed-docs] “Use createOrUpdate endpoint to create a negative transaction representing the refund.”
   • [claimed-docs] “Use createNegation endpoint to negate the original transaction. Use createOrUpdate endpoint to create a new version of the partially refunde…”
   • [claimed-docs] “you can use this API endpoint to create many-to-1 mappings to associate various products in your billing system with equivalent products tha…”
   • [claimed-docs] “Tax calculation through Shopify requires Shopify tax. Anrok recalculates and verifies Shopify's calculations to ensure accuracy.”

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

   Anrok's docs show jurisdiction-level exposure dashboards and a filings-fetch API, implying some accrued/owed visibility and filing-ready data, but there is no explicit evidence of a collected-vs-owed liability view, GL-formatted exports, or accountant-consumable outputs. missing for 10: explicit collected vs owed liability breakdown, GL/accounting export formats, accountant-facing report examples.

   • [claimed-docs] “This endpoint can be used to fetch filings from Anrok.”
   • [claimed-docs] “Dashboard showing a world exposure map with sales data by jurisdiction and a UK registration threshold tracker.”
   • [claimed-docs] “Two dashboard screens showing tax obligations in 13 countries and automatic registration completion in 13 jurisdictions.”
   • [claimed-docs] “Early alerts before you owe anywhere”

   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