Klaviyo vs Kit

Agent access

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

   weight 2 · round to Kit
   Klaviyo—none0/10

   A direct probe for llms.txt returned 404, and no evidence pack item mentions agent-oriented documentation formats aside from the unrelated MCP server docs, which serve a different purpose (data assistance, not doc discovery for agents).

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.klaviyo.com/llms.txt”

   proof ↗⚑ flag

   Kit✓fullprobed9/10

   Kit provides a live llms.txt file confirmed by probe (HTTP 200 with structured doc links) plus agent-oriented docs including an official MCP server that queries live docs to avoid hallucinated API surfaces. Missing for 10: independent third-party confirmation of an AI agent successfully using llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.kit.com/llms.txt # Kit Developer Documentation - [Welcome](https://developers.kit.com/welcom…”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 2 · round to Klaviyo
   Klaviyo~partialclaimed6/10

   Klaviyo exposes a full REST API secured by API keys/OAuth, with maintained SDKs (Python, PHP, Ruby, Node) and a sandbox test account for safely automating campaign creation, imports, etc. — enough to script/automate outside the UI, but there is no explicit CI/CD documentation, CLI tool, or headless-runner guidance in the evidence. Missing for 10: dedicated CI/CD integration docs, official CLI, and any explicit statement about running headlessly in automated pipelines.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”
   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Populate your test account with sample data to quickly explore our API and see how data is used in Klaviyo.”
   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”

   proof ↗⚑ flag

   Kit~partialprobed3/10

   Kit exposes a REST API and an MCP server that let third-party tools or agents trigger actions (e.g., drafting broadcasts) programmatically, which could in principle be scripted into a CI pipeline, but there is no documentation of a CLI, headless mode, or explicit CI/automation-pipeline usage. missing for 10: explicit CI/headless execution docs, a CLI or non-interactive mode, and any independent evidence of running Kit unattended in automated pipelines.

   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Klaviyo✓fullprobed8/10

   Klaviyo documents an official MCP server that connects to MCP clients like Claude or Cursor, with example usage shown. Missing for 10: independent/hands-on third-party corroboration and details on scopes/auth specific to the MCP server itself.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit✓fullprobed8/10

   Kit's developer docs explicitly describe and document an official MCP server ('Kit Developer Docs MCP') that lets agents query live API docs and turn natural-language prompts into real account actions, and a probe confirms this page is live. Missing for 10: independent/hands-on third-party confirmation that the MCP server works as described beyond first-party docs.

   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Klaviyo—none0/10

   Evidence shows SDKs in Python/PHP/Ruby/Node and an MCP server, but no mention of an official CLI tool anywhere in the docs; llms.txt probe 404s and no CLI reference exists.

   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.klaviyo.com/llms.txt”

   proof ↗⚑ flag

   Kit—none0/10

   Kit's evidence pack covers its REST API, MCP server for AI agents, and marketing features, but nowhere mentions a CLI tool for developers or AI-native workflows. Since Kit is a SaaS platform where an official CLI is a plausible offering, absence of evidence means this axis is unmet rather than inapplicable.

   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.kit.com/llms.txt # Kit Developer Documentation - [Welcome](https://developers.kit.com/welcom…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

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

   weight 3 · round to Klaviyo
   Klaviyo✓fullclaimed9/10

   Klaviyo publishes a comprehensive public REST API with documented authentication (private API keys, OAuth for partners), scoped permissions, official SDKs in multiple languages, sandbox test accounts, and Postman collections, plus concrete endpoint docs (e.g., create campaign) showing programmatic control. Missing for 10: no evidence of an llms.txt or AI-specific machine-readable API discovery file, and no independent third-party corroboration of API robustness beyond vendor docs.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “If you are a tech partner integrating with Klaviyo, we recommend using OAuth to authenticate your app.”
   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”
   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “Adding a scope helps you protect your and your customers’ data by limiting what third parties can access.”

   proof ↗⚑ flag

   Kit✓fullprobed8/10

   Kit publishes a documented public API (broadcasts, subscribers, segments/tags) with a developer reference and overview explicitly aimed at third-party developers building on the platform, plus an llms.txt for AI-native discovery. Missing for 10: a publicly discoverable OpenAPI/Swagger spec (probe found only 404s) and independent hands-on developer corroboration beyond vendor docs.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.kit.com/llms.txt # Kit Developer Documentation - [Welcome](https://developers.kit.com/welcom…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

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

   weight 2 · round to Klaviyo
   Klaviyo~partialclaimed6/10

   Klaviyo supports private API keys with scoped permissions and explicitly frames scopes as a way to limit third-party access, which directly supports issuing least-privilege credentials for an agent; OAuth is also recommended for integrator apps. However, there's no documented workflow specifically for provisioning agent-specific credentials, no granular scope list/enumeration shown, and no evidence of key rotation, expiry, or agent-specific audit trails. missing for 10: agent-specific credential provisioning workflow, full enumerated scope list, key rotation/expiry controls, independent confirmation of scope enforcement in practice.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “If you are a tech partner integrating with Klaviyo, we recommend using OAuth to authenticate your app.”
   • [claimed-docs] “Adding a scope helps you protect your and your customers’ data by limiting what third parties can access.”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence shows Kit has an API and an MCP server for agent integration, but nothing describes issuing scoped or least-privilege API keys/tokens (e.g., granular permission scopes, read-only vs write keys) for agents. missing for 10: any documentation of scoped API key creation, permission/role-based tokens, or least-privilege credential issuance for agent use.

   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Klaviyo
   Klaviyo✓fullclaimed8/10

   Klaviyo maintains official SDKs in Python, PHP, Ruby, and Node, backed by API key/OAuth authentication, sandboxed test accounts, and Postman collections for development. Missing for 10: independent/third-party corroboration of SDK quality and no explicit mention of typed/async support or SDK versioning cadence.

   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”
   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “If you are a tech partner integrating with Klaviyo, we recommend using OAuth to authenticate your app.”
   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence shows Kit has a REST API with reference docs and an MCP server, but nothing indicates official client SDKs (e.g., Python/JS/Ruby libraries); in fact the OpenAPI spec probe returned 404s, suggesting no machine-generated or officially maintained SDK tooling. missing for 10: evidence of any official SDK/client library, language coverage, or published OpenAPI spec used to generate SDKs.

   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Klaviyo—none0/10

   The evidence pack contains no mention of webhooks or event subscription mechanisms—only API key auth, SDKs, sandbox testing, and an MCP server for AI agents. Missing for 10: any documentation of a webhooks API, event subscription endpoints, or push-notification mechanism.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack of Kit offering webhook subscriptions for events; documentation covers API endpoints, broadcasts, MCP, and pricing but never mentions webhooks. Missing for 10: any webhook documentation, event types, subscription/registration endpoints, or delivery mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round to Kit
   Klaviyo—none0/10

   The evidence only covers Klaviyo's MCP server, which lets external AI agents (Claude, Cursor) query and act on Klaviyo data—this is an external-agent integration, not native in-product AI-generated insights or suggestions surfaced to the user inside Klaviyo's own UI. No evidence pack item describes built-in analytics AI, predictive suggestions, or in-app insight generation. Missing for 10: any documentation of native AI-driven insights/suggestions surfaced within Klaviyo's own dashboard or reporting UI.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit~partialprobed4/10

   Kit offers subscriber engagement scoring and an MCP integration that lets an agent draft actions like broadcasts from natural-language prompts, which touches on data-driven suggestions, but there is no documented feature that surfaces AI-generated insights or recommendations from a user's own data (e.g., analytics summaries, content suggestions). Missing for 10: dedicated AI insight/analytics generation feature, evidence of proactive suggestions surfaced in-app, independent corroboration of engagement scoring being AI-driven.

   • [claimed-docs] “Subscriber engagement scoring”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Klaviyo~partialclaimed5/10

   Klaviyo's pricing docs confirm the platform supports building automations (flows) that presumably run autonomously once configured, and the MCP server lets an AI agent interact with Klaviyo (e.g., create campaigns) — suggesting some AI-native automation setup is possible. However, the evidence never details how automations trigger/run in the background, whether MCP can create or manage automation flows specifically, or any autonomous execution mechanics beyond a one-line mention. Missing for 10: documentation of flow/automation trigger logic and autonomous runtime behavior, evidence that MCP or another AI-native interface can configure automations (not just campaigns), and independent confirmation of autonomous background execution.

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””

   proof ↗⚑ flag

   Kit~partialprobed5/10

   Kit ships 'Unlimited Visual Automations' as a core background-automation feature, and its MCP server lets AI agents trigger real account actions (e.g., drafting broadcasts) via natural language, showing some agentic setup capability. However, no evidence shows the MCP or API being used to configure/build visual automation workflows themselves (only broadcast creation is exemplified), and there's no confirmation of persistent, autonomously-triggered background execution driven by an AI agent. Missing for 10: documented API/MCP endpoints for creating or editing automation workflows, evidence of scheduled/triggered autonomous runs initiated by AI, independent confirmation of this working end-to-end.

   • [claimed-docs] “Unlimited Visual Automations”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Klaviyo—none0/10

   Evidence only shows Klaviyo exposing an MCP server so external AI agents (Claude, Cursor) can act on Klaviyo data — this is the reverse of a built-in assistant inside Klaviyo itself. No documentation of an in-product AI assistant users delegate tasks to directly within the Klaviyo UI.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence only documents an MCP server that lets external AI agents (e.g., Claude) query Kit's docs and perform actions via natural language — this is agent-facing infrastructure, not a built-in AI assistant embedded in the Kit product UI itself. No evidence of an in-app assistant for drafting content, automations, or subscriber management.

   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 2 · round to Kit
   Klaviyo~partialprobed6/10

   Klaviyo ships an official MCP server that connects to AI agents (Claude, Cursor), enabling natural-language commands like "Create an email campaign promoting our Memorial Day sale" to operate Klaviyo data and actions. This directly supports natural-language operation, but it's mediated through third-party MCP clients rather than a native NL interface, and there's no independent/hands-on corroboration of reliability. Missing for 10: first-party natural-language UI within Klaviyo itself, independent verification of MCP command success, breadth of supported natural-language operations beyond the single documented example.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit✓fullprobed7/10

   Kit ships an official Developer Docs MCP server explicitly designed so natural-language prompts (e.g., 'draft a broadcast to my new subscribers from this week') translate into real account actions, confirmed by both docs and a probe verifying the MCP endpoint exists. Missing for 10: independent/hands-on verification of natural-language command execution beyond the single documented example, and broader coverage of which actions are supported via NL.

   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Klaviyo
   Klaviyo~partialclaimed5/10

   Klaviyo provides a Postman collection of pre-built API requests and a sandboxed test account for exploring the API, plus reference pages describing individual endpoints, but this relies on an external tool (Postman) rather than an in-browser interactive 'try it out' console with runnable examples. missing for 10: evidence of a native in-docs interactive API explorer/console, runnable code snippets embedded in the reference pages themselves.

   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”
   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Populate your test account with sample data to quickly explore our API and see how data is used in Klaviyo.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence confirms Kit has API reference docs (create-a-broadcast, overview) but nothing describes an interactive console or runnable/try-it-now examples, and a probe for an OpenAPI/Swagger spec (which typically powers such interactive references) returned 404s across all checked paths.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Klaviyo—none0/10

   Klaviyo's developer docs describe a full REST API reference, SDKs, and a Postman collection, but no evidence mentions a downloadable OpenAPI/Swagger spec file or machine-readable schema; the llms.txt probe returned 404 as well. missing for 10: explicit OpenAPI/Swagger spec download link, documented schema export, or API definition file.

   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.klaviyo.com/llms.txt”

   proof ↗⚑ flag

   Kit—none0/10

   Kit's developer docs describe an API reference and even an MCP server for live API access, but a direct probe for machine-readable spec endpoints (openapi.json, swagger.json, etc.) returned 404 on all candidates, and no OpenAPI/Swagger download is documented anywhere in the evidence.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.kit.com/llms.txt # Kit Developer Documentation - [Welcome](https://developers.kit.com/welcom…”

   proof ↗⚑ flag

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

   weight 1 · round to Klaviyo
   Klaviyo✓fullclaimed7/10

   Klaviyo explicitly documents a test/sandbox account for testing integrations without affecting production, plus sample data population and Postman collections for exploration. missing for 10: independent/hands-on confirmation of sandbox fidelity, and explicit guidance on using the sandbox specifically with AI agents/MCP workflows.

   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Populate your test account with sample data to quickly explore our API and see how data is used in Klaviyo.”
   • [claimed-docs] “Make test calls using Postman’s UI tool with our collection of pre-built API requests.”

   proof ↗⚑ flag

   Kit—none0/10

   No evidence of a sandbox/test environment, staging account, or test-mode API keys distinct from production data; the docs only describe live API/MCP actions against a real account.

   ⚑ flag

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

   weight 2 · round drawn
   Klaviyo—none0/10

   The evidence pack covers authentication, SDKs, sandbox testing, and MCP server support, but contains no mention of API versioning scheme or a documented deprecation policy anywhere in the docs excerpts provided.

   ⚑ flag

   Kit—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; the API reference and overview pages mention endpoints but say nothing about version numbers, sunset timelines, or backward-compatibility guarantees. OpenAPI spec probes also 404, further indicating no formal versioned contract is published.

   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

Api metrics

1. developerPull campaign and flow performance metrics through the API into my own warehouse or dashboards

   weight 2 · round drawn
   Klaviyo—none0/10

   The evidence pack shows general API access, authentication, and SDKs, plus a campaign-creation endpoint, but no documentation of any reporting/analytics or metrics endpoints for campaign or flow performance data. Missing for 10: evidence of a Campaigns/Flows reporting or metrics API endpoint, sample response schemas for performance data, or any mention of pulling analytics into a warehouse/BI tool.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”

   proof ↗⚑ flag

   Kit—none0/10

   The evidence only shows API endpoints for creating/scheduling broadcasts and general platform/MCP docs; there is no mention of any API for retrieving campaign or automation ('flow') performance metrics, open/click stats, or analytics exports suitable for warehousing.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

Attribution

1. founderAttribute signups or revenue to specific emails and flows, not just opens and clicks

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence in the pack addresses revenue/signup attribution to specific emails or flows, conversion tracking, or attribution reporting features; documentation only covers API auth, SDKs, MCP server, and pricing tiers.

   ⚑ flag

   Kit—none0/10

   No evidence of revenue/signup attribution reporting tied to specific emails or automations — the pack shows broadcast creation, MCP tooling, and general pricing feature bullets (e.g. engagement scoring, A/B testing) but nothing about linking conversions/signups/revenue back to specific emails or flows. Missing for 10: revenue attribution reporting, signup source tracking per email/flow, any analytics dashboard evidence.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “Subscriber engagement scoring”
   • [claimed-docs] “Sell digital products & subscriptions”

   proof ↗⚑ flag

Reporting core

1. marketerRead opens, clicks, unsubscribes, and conversions per campaign and per automation step, over time

   weight 3 · round drawn
   Klaviyo—none0/10

   The evidence pack contains no documentation of campaign/automation analytics reporting (opens, clicks, unsubscribes, conversions) or any reporting/analytics API or dashboard feature; it only covers API auth, SDKs, testing, MCP server, and pricing. Missing for 10: any mention of a reporting/analytics dashboard, per-campaign or per-flow-step metrics, or a metrics API endpoint.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack describes any analytics/reporting feature—no mention of open/click/unsubscribe/conversion tracking per broadcast or automation step; the pack only covers broadcast creation, MCP docs, and pricing feature lists. missing for 10: analytics dashboard docs, per-campaign/per-step metrics, conversion tracking evidence.

   ⚑ flag

Agent segments

1. ai-native userAn agent can translate a plain-language audience description into a real segment via the platform's programmatic surface

   weight 2 · round to Klaviyo
   Klaviyo~partialprobed4/10

   Klaviyo has a documented MCP server that lets an AI agent act on Klaviyo data via natural language, and the API supports arbitrary schema-free data plus programmatic campaign creation, suggesting an agent could plausibly create segments too. However, no evidence pack item shows a segment-creation endpoint or an MCP example translating a plain-language audience description into an actual segment (the campaign example is the only concrete natural-language-to-action illustration). Missing for 10: explicit segment/API endpoint documentation, a worked example of natural-language-to-segment translation, and independent/hands-on confirmation this works in practice.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence shows Kit's API can target broadcasts to existing segment/tag ids and its MCP server can turn natural language into broadcast actions, but there is no documented endpoint or MCP capability for creating or defining a new segment from a plain-language audience description. Missing for 10: a segment-creation API endpoint, MCP/agent workflow demonstrating natural-language-to-segment translation, and any example of dynamic segment criteria being set programmatically.

   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

Api contacts

1. developerCreate, update, and suppress contacts with custom properties through the API at production scale

   weight 3 · round to Klaviyo
   Klaviyo~partialclaimed5/10

   Docs confirm a flexible, schema-less API that accepts arbitrary custom data (klaviyo-docs-8), key-scoped authentication (klaviyo-docs-1, klaviyo-docs-14), and SDKs for production integration (klaviyo-docs-3), plus a sandbox for testing at scale (klaviyo-docs-4, klaviyo-docs-5). However, the pack never cites a specific contacts/profiles create-update-suppress endpoint (only campaign creation is shown), so explicit support for suppression workflows is unproven. Missing for 10: direct documentation of profile create/update endpoints, explicit suppression/unsubscribe API reference, and evidence of rate limits/production-scale throughput guarantees.

   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”
   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Adding a scope helps you protect your and your customers’ data by limiting what third parties can access.”
   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”
   • [claimed-docs] “Test custom integrations and apps without the risk of impacting your production account.”
   • [claimed-docs] “Populate your test account with sample data to quickly explore our API and see how data is used in Klaviyo.”

   proof ↗⚑ flag

   Kit—none0/10

   The evidence pack only covers broadcasts API, MCP docs, pricing features, and general company history — there is no documentation of contact/subscriber creation, updates, custom field/property management, or suppression via the API, nor any mention of production-scale rate limits or bulk operations.

   ⚑ flag

Api segments

1. developerCreate and update segments, tags, or lists programmatically and read back exactly who is in them

   weight 3 · round drawn
   Klaviyo—none0/10

   The evidence pack covers general API authentication, SDKs, sandbox testing, campaign creation, and MCP server integration, but contains no documentation of specific endpoints for creating/updating segments, tags, or lists, nor for reading back their membership. Missing for 10: any reference to Lists/Segments/Tags API endpoints, membership read endpoints, or examples of programmatic segment management.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence only shows that broadcasts can be targeted using existing segment or tag ids, implying some segmentation exists, but there is no documentation of API endpoints to create/update segments, tags, or lists, nor any evidence of reading back the exact subscriber membership of those groups.

   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”

   proof ↗⚑ flag

Segment core

1. marketerBuild audience segments from profile attributes, tags, and behavioral events, and they stay live as data changes

   weight 3 · round drawn
   Klaviyo~partialclaimed3/10

   Klaviyo's pricing page confirms segmentation as a core feature alongside automations and reports, but the evidence pack contains no documentation of how segments are built from profile attributes/tags/behavioral events or how they stay dynamically live as data changes. missing for 10: technical docs on segment definition logic, dynamic/live-updating behavior, and support for tags and behavioral event conditions.

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit~partialclaimed3/10

   Evidence only shows broadcasts can target subscribers by 'segment or tag ids' (kit-docs-2), implying segments exist as a concept, but there's no documentation of building segments from profile attributes or behavioral events, nor confirmation that segments update live as data changes. Missing for 10: segment-builder documentation, behavioral-event triggers, and confirmation of live/dynamic recalculation of membership.

   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”

   proof ↗⚑ flag

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

   weight 2 · round to Kit
   Klaviyo—none0/10

   The evidence pack covers API authentication, SDKs, sandbox testing, single-campaign creation, and the MCP server, but contains no mention of bulk/batch endpoints, mass import/export operations, or any mechanism for operating on many items at once. Missing for 10: bulk/batch API endpoints, documented rate-limit-aware batch processing, bulk data import/export tooling.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”

   proof ↗⚑ flag

   Kit~partialprobed5/10

   Kit's API/MCP lets users draft and send broadcasts to all or a segment/tag-based subset of subscribers, and the MCP overview shows natural-language prompts triggering such bulk actions, which is a form of bulk operation across many subscriber items. However, there's no evidence of broader bulk operations like batch subscriber import/export, bulk tagging/untagging, or bulk updates via API beyond broadcast targeting. Missing for 10: documented bulk subscriber CRUD/import-export endpoints, evidence of batch processing limits or throughput, and independent confirmation of bulk actions working via the MCP in practice.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

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

   weight 3 · round to Kit
   Klaviyo~partialclaimed3/10

   Klaviyo's pricing page mentions users can 'build automations' alongside segmentation and reports, implying event-triggered flow automation exists, but the evidence pack provides no detail on rule definition, trigger types, or conditional logic. missing for 10: documentation of flow/automation trigger configuration, conditional branching, and event-based rule examples.

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit~partialclaimed4/10

   Kit's pricing page references 'Unlimited Visual Automations' (kit-docs-6), implying a rule/trigger-based automation builder typical of email platforms, but the evidence pack contains no documentation detailing specific triggers, conditions, or actions, nor any hands-on confirmation of how automations are configured or fire on events. Missing for 10: detailed docs on trigger/event types, action definitions, conditional logic, and independent verification of automation reliability.

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Klaviyo~partialclaimed3/10

   Klaviyo's automation platform includes 'flows'/automations (klaviyo-docs-11) and campaign creation via API (klaviyo-docs-7), but the evidence never shows an AI-native user scheduling recurring jobs via the API or MCP server—MCP docs only describe one-off campaign creation requests (klaviyo-docs-9, klaviyo-docs-10), not recurring/cron-based automation triggering. Missing for 10: API/MCP documentation of recurring schedule creation, cron-like triggers, or workflow automation exposed to AI agents specifically.

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””

   proof ↗⚑ flag

   Kit~partialclaimed3/10

   Kit supports scheduling one-time broadcasts and offers 'Unlimited Visual Automations' and RSS campaigns (which are inherently recurring), but there's no evidence of an AI-native (API/MCP) mechanism to schedule or manage recurring workflows—broadcast scheduling is single-send and automations are event-triggered rather than time-based recurring jobs. Missing for 10: explicit API/MCP support for recurring/cron-style workflow scheduling, documentation of recurring automation triggers, and independent confirmation these can be set up via AI-native tooling.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “Unlimited Visual Automations”
   • [claimed-docs] “RSS campaigns”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Klaviyo—none0/10

   No evidence of versioning, review workflows, or rollback capability for Klaviyo automations/flows; docs cover API auth, SDKs, sandbox testing, and MCP server but nothing about automation version history or revert functionality.

   ⚑ flag

   Kit—none0/10

   No evidence Kit offers version history, review workflows, or rollback for automations/visual automations; docs mention only building automations and MCP-driven actions, not versioning or undo capabilities.

   ⚑ flag

Agent campaigns

1. ai-native userAn agent can draft a campaign against a segment and leave it scheduled or queued for a human to approve before send

   weight 3 · round to Kit
   Klaviyo~partialclaimed4/10

   Klaviyo's API and MCP server let an agent draft/create a campaign via natural language (klaviyo-docs-7, klaviyo-docs-9, klaviyo-docs-10), which implies a campaign is created before being sent, but there's no explicit documentation describing a scheduled/queued draft state with a human-approval gate before send. Missing for 10: explicit docs on campaign draft/review states, scheduling API parameters, or an approval workflow between agent creation and send.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””

   proof ↗⚑ flag

   Kit~partialclaimed6/10

   Kit's API and MCP let an agent draft or schedule a broadcast to a segment/tag (kit-docs-1, kit-docs-2, kit-docs-5), and drafts inherently sit unsent until a human acts, which functions as an approval gate. However, there is no explicit documentation of a formal 'queued for human approval' workflow or approval-status field distinct from draft/schedule. Missing for 10: explicit human-approval/review step or status beyond generic draft/schedule, and independent confirmation the MCP flow reliably leaves campaigns unsent pending approval.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”

   proof ↗⚑ flag

Api campaigns

1. developerCreate and schedule a campaign or broadcast entirely through a documented public API, without touching the dashboard

   weight 3 · round to Kit
   Klaviyo~partialclaimed6/10

   Klaviyo's public API documents a create_campaign endpoint with API key/OAuth auth and SDKs, supporting programmatic campaign creation, but the evidence pack lacks documentation of a scheduling/send endpoint or a full end-to-end example proving a campaign can be scheduled and sent without ever using the dashboard. missing for 10: documented schedule/send-campaign endpoint, evidence of full lifecycle (create+schedule+send) purely via API, independent developer confirmation this works end-to-end.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “If you are a tech partner integrating with Klaviyo, we recommend using OAuth to authenticate your app.”
   • [claimed-docs] “Install a Klaviyo maintained SDK to accelerate development– offered in Python, PHP, Ruby, and Node.”

   proof ↗⚑ flag

   Kit✓fullprobed7/10

   Kit's public API docs explicitly support creating/drafting and scheduling broadcasts with targeting by segment/tag, directly enabling campaign creation without the dashboard. Missing for 10: an accessible OpenAPI/swagger spec (probe found 404s), independent developer confirmation of end-to-end scheduling success, and clarity on recurring/RSS campaign API support.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

Campaign core

1. marketerCompose an email campaign, pick its audience, and send or schedule it — the arena's table-stakes loop

   weight 3 · round to Kit
   Klaviyo✓fullclaimed7/10

   Docs show a Create Campaign API, a drag-and-drop email editor, and built-in segmentation/automation, and even AI-assisted campaign creation via the MCP server (e.g., 'Create an email campaign promoting our Memorial Day sale'), covering the compose+audience+send loop. Missing for 10: explicit documentation of the schedule/send UI step and audience-selection mechanics beyond generic 'segmentation' mention.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”

   proof ↗⚑ flag

   Kit✓fullclaimed8/10

   Kit's API docs confirm drafting/scheduling a broadcast (send/schedule) with audience targeting by segment or tag (kit-docs-1, kit-docs-2), covering the core compose-audience-send/schedule loop, and this is corroborated by the product's broader marketing platform positioning (kit-docs-14, kit-docs-15). missing for 10: independent hands-on user account of composing and sending a real campaign via the UI, and detail on scheduling UI/preview features beyond the API reference.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “Get more subscribers with landing pages, forms, and creator recommendations.”

   proof ↗⚑ flag

Experiments

1. marketerA/B test subject lines or content variants and have the winner picked from real engagement

   weight 2 · round to Kit
   Klaviyo—none0/10

   None of the evidence items mention A/B testing, subject line testing, or automatic winner selection based on engagement; only campaign creation via API and general platform features are documented. Missing for 10: any mention of A/B test creation, variant configuration, winning metric selection, or automatic send-to-winner mechanics.

   ⚑ flag

   Kit~partialclaimed4/10

   Kit's pricing page lists "A/B test subject lines & content" as a feature [kit-docs-7], confirming the capability exists, but there's no documentation describing how winners are determined from engagement data (e.g., automatic winner selection, sample size, or evaluation window). Missing for 10: documentation on automatic winner-selection logic/criteria, evidence of engagement-based decisioning, and any hands-on or independent confirmation the feature works as described.

   • [claimed-docs] “A/B test subject lines & content”

   proof ↗⚑ flag

Deliverability signals

1. marketerSee bounce, complaint, and blocklist signals per send and get actionable guidance when deliverability degrades

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence in the pack addresses bounce, complaint, or blocklist deliverability signals, per-send reporting, or actionable guidance for deliverability degradation; the pack only covers API auth, SDKs, MCP server, and pricing. Missing for 10: any documentation of deliverability/bounce/complaint/blocklist metrics, per-send reporting, or guidance features.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack mentions bounce, complaint, or blocklist tracking, deliverability metrics, or actionable guidance for degraded sending reputation; the documentation covers broadcasts, pricing features, and MCP/API tooling but nothing about deliverability signal reporting.

   ⚑ flag

Domain auth

1. ops userAuthenticate my own sending domain — SPF, DKIM, DMARC alignment — with guided DNS setup and verification

   weight 3 · round drawn
   Klaviyo—none0/10

   No evidence pack items address sending-domain authentication (SPF/DKIM/DMARC) or guided DNS setup/verification; all evidence covers API keys, OAuth, SDKs, MCP server, and pricing tiers, which are unrelated to this axis.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack addresses domain authentication (SPF/DKIM/DMARC) setup, guided DNS configuration, or verification tooling; the evidence only covers broadcasts, MCP, pricing tiers, and general marketing.

   ⚑ flag

Suppression

1. ops userUnsubscribes, bounces, and spam complaints are suppressed automatically and honored across every send type — CAN-SPAM/GDPR hygiene by default

   weight 3 · round drawn
   Klaviyo—none0/10

   None of the evidence items address suppression handling, unsubscribe/bounce/spam-complaint processing, or CAN-SPAM/GDPR compliance mechanics; the pack is limited to API auth, SDKs, MCP server, and pricing. missing for 10: documentation of automatic suppression lists, bounce/complaint handling, cross-channel enforcement across email/SMS sends, and compliance default behavior.

   ⚑ flag

   Kit—none0/10

   No evidence pack items mention unsubscribe suppression, bounce handling, spam complaint suppression, or automatic CAN-SPAM/GDPR compliance across send types; the pack only covers broadcast creation, MCP/API access, and pricing features unrelated to suppression hygiene.

   ⚑ flag

First party integrations

1. ops userConnect the platform to my existing stack — Stripe or Shopify, a CDP like Segment, my product database — with maintained first-party integrations

   weight 2 · round drawn
   Klaviyo—none0/10

   The evidence pack only shows generic API/OAuth/SDK capabilities and a flexible schema, but contains no mention of maintained first-party integrations with Shopify, Stripe, Segment, or a product database — the specific connectors the story asks about.

   ⚑ flag

   Kit—none0/10

   Evidence only shows a generic marketing line about connecting 'creator tools' via apps (kit-docs-15) and a general third-party API note (kit-docs-3); there is no mention of specific maintained first-party integrations with Stripe, Shopify, Segment/CDPs, or product databases anywhere in the pack.

   • [claimed-docs] “Automate your work with apps that connect your creator tools directly to Kit.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”

   proof ↗⚑ flag

Webhooks

1. developerSubscribe webhooks to delivery and engagement events — sends, opens, clicks, bounces, unsubscribes — with a documented, signed payload

   weight 3 · round drawn
   Klaviyo—none0/10

   No evidence in the pack mentions webhooks, event subscriptions, or signed payloads for delivery/engagement events; the docs cover API auth, SDKs, MCP server, and pricing but nothing about webhook subscriptions or signature verification. missing for 10: webhook subscription API/docs, list of supported event types (sends, opens, clicks, bounces, unsubscribes), payload signing/verification mechanism.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack mentions webhooks, signed payloads, or event subscriptions (sends, opens, clicks, bounces, unsubscribes); the docs cover broadcasts, MCP, and pricing features unrelated to webhook delivery. missing for 10: any documentation of webhook subscription endpoints, event types, or payload signing/verification.

   ⚑ flag

Automation core

1. marketerBuild multi-step lifecycle automations — welcome series, onboarding, winback — with branches, delays, and exit rules

   weight 3 · round drawn
   Klaviyo~partialclaimed4/10

   Evidence only vaguely mentions building 'automations' via drag-and-drop editors, without any detail on branches, delays, exit rules, or lifecycle templates like welcome/onboarding/winback series. Klaviyo is widely known for this capability but the provided evidence pack does not document it in depth. missing for 10: documentation of branching logic, time-delay steps, exit/entry conditions, and specific lifecycle flow templates (welcome, winback, onboarding).

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit~partialclaimed4/10

   Kit's pricing page confirms a visual automation builder ("Unlimited Visual Automations") exists, which is consistent with the story's need for lifecycle automations, but the evidence pack contains no documentation detailing branch logic, delay steps, or exit-rule configuration, nor examples of welcome/onboarding/winback templates. Missing for 10: docs on branching logic, delay/wait steps, exit-rule conditions, and concrete welcome/onboarding/winback automation examples.

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

Event triggers

1. developerFire a custom event from my product and have it trigger an automation for exactly that person

   weight 3 · round to Klaviyo
   Klaviyo~partialclaimed3/10

   Klaviyo's docs mention flexible, schema-less data ingestion ('arbitrary data') which implies custom event tracking, but the evidence pack lacks any explicit mention of a track-event API or of flows/automations being triggered by specific custom events for an individual profile. Missing for 10: explicit custom event API documentation, explicit flow-trigger-on-event behavior, and confirmation that automations target the specific triggering profile.

   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”
   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”

   proof ↗⚑ flag

   Kit—none0/10

   The evidence pack covers broadcasts API, MCP docs integration, and pricing features, but contains no mention of a custom-event API or webhook mechanism that lets a developer fire an event to trigger a per-subscriber automation. This is a plausible axis for an email/lifecycle automation platform, but no evidence supports it here.

   ⚑ flag

Flow operations

1. ops userSee where any individual person sits inside an automation and pull or re-enter them without breaking the flow

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence describes flow-level visibility into where a profile sits within an automation, nor any capability to manually pull or re-enter a person mid-flow without breaking it; evidence only covers API auth, SDKs, sandbox testing, campaign creation, and MCP server setup. Missing for 10: automation flow status view per profile, pull/remove from flow controls, re-enter flow functionality, and any documentation of flow integrity safeguards.

   ⚑ flag

   Kit—none0/10

   Evidence only mentions 'Unlimited Visual Automations' as a pricing line item, with no documentation of subscriber-level visibility into automation steps or the ability to pull/re-enter an individual subscriber without disrupting the automation. Missing for 10: any docs on per-subscriber automation position view, manual add/remove-from-automation actions, and confirmation that re-entry doesn't break flow state.

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

Export

1. founderExport my entire audience — contacts, custom fields, tags, engagement history, and suppression list — in an open format, self-serve

   weight 3 · round drawn
   Klaviyo—none0/10

   The evidence pack covers API authentication, SDKs, sandbox testing, MCP integration, and pricing tiers, but contains no documentation of a bulk/self-serve export feature covering contacts, custom fields, tags, engagement history, and suppression lists in an open format. Missing for 10: explicit export/download documentation, confirmation of open format (CSV/JSON) output, and evidence suppression list and engagement history are included in any export.

   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”
   • [claimed-docs] “The free plan allows you to create a Klaviyo account, import or sync your contacts and activity data”

   proof ↗⚑ flag

   Kit—none0/10

   The evidence pack contains no mention of a self-serve data export feature (CSV/CSV-like) covering contacts, tags, custom fields, engagement history, or suppression lists; only API endpoints for broadcasts and pricing feature lists are present, none of which address audience export or portability.

   ⚑ flag

Import migration

1. marketerMigrate in from another email platform with guided list import that preserves tags, custom fields, and unsubscribe state

   weight 2 · round drawn
   Klaviyo—none0/10

   Evidence pack only covers API scopes, SDKs, sandbox testing, MCP server, and pricing tiers—no mention of a guided migration tool, list import wizard, or preservation of tags/custom fields/unsubscribe state from another ESP. Klaviyo docs mention generic 'import or sync your contacts' but nothing about migration-specific data preservation guarantees.

   • [claimed-docs] “The free plan allows you to create a Klaviyo account, import or sync your contacts and activity data”

   proof ↗⚑ flag

   Kit—none0/10

   The only relevant evidence is a single marketing line mentioning 'Free migrations' on the pricing page, with no documentation of guided list import, tag/custom-field preservation, or unsubscribe-state handling. missing for 10: any docs on import tooling, evidence tags/custom fields are preserved, evidence unsubscribe status is preserved, guided/step-by-step migration flow.

   • [claimed-docs] “14-day free trial. No credit card required. Free migrations.”

   proof ↗⚑ flag

Agent access

1. ai-native userAn agent can pull my whole email program — audiences, live automations, recent campaign results — programmatically and report on what's working

   weight 2 · round to Klaviyo
   Klaviyo~partialprobed6/10

   Klaviyo offers a documented REST API (with scoped private keys and OAuth) and a first-party MCP server explicitly built to let AI agents like Claude or Cursor interact with Klaviyo data, which supports programmatic, agent-driven access. However the evidence only shows a campaign-creation example and general API scope docs — there's no direct documentation of pulling audiences, live automation status, or campaign performance/reporting data through the API or MCP server. Missing for 10: explicit endpoints/examples for audience/segment retrieval, automation status, and campaign analytics/reporting accessible via API or MCP, plus independent confirmation of successful end-to-end reporting use.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “If you are a tech partner integrating with Klaviyo, we recommend using OAuth to authenticate your app.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [probe] “official MCP server documented at https://developers.klaviyo.com/en/docs/klaviyo_mcp_server”

   proof ↗⚑ flag

   Kit~partialprobed4/10

   Kit has a documented API and an official MCP server that can query live docs and turn natural-language prompts into account actions (e.g., drafting broadcasts), showing programmatic access exists. However, the evidence pack lacks any documentation of endpoints for pulling subscriber/audience lists, automation status, or campaign performance/reporting data — the core of 'report on what's working'. Missing for 10: audience/segment retrieval endpoints, automation status/reporting API, campaign analytics endpoints, and any example of an agent synthesizing a performance report.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “official MCP server documented at https://developers.kit.com/mcp/overview”

   proof ↗⚑ flag

Api access

1. developerRead per-person engagement history — what was sent, opened, clicked — through the API for any contact

   weight 3 · round drawn
   Klaviyo—none0/10

   No evidence pack items reference an events/metrics API, per-profile activity/timeline endpoint, or any way to retrieve sent/opened/clicked history for a contact — only general API overview, SDKs, campaign creation, and MCP server docs are cited.

   ⚑ flag

   Kit—none0/10

   Evidence covers broadcast creation, MCP server, and pricing features, but nothing shows an API endpoint for retrieving per-subscriber engagement history (sent/opened/clicked events) for a given contact. Subscriber engagement scoring is mentioned only as a pricing feature name, not an API capability.

   • [claimed-docs] “Subscriber engagement scoring”
   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”

   proof ↗⚑ flag

Scoped access

1. ops userMint scoped or read-only API credentials so an agent or contractor can read analytics without the power to send

   weight 2 · round to Klaviyo
   Klaviyo~partialclaimed6/10

   Klaviyo docs confirm private API keys support scopes to limit third-party access (e.g., read-only vs. send permissions), directly matching the ops need to mint restricted credentials for agents/contractors. However, there's no evidence detailing granular scope options (e.g., specific read-only analytics scope vs. campaign-send scope), no UI walkthrough for creating such a key, and no independent/hands-on confirmation of enforcement. missing for 10: granular scope list/UI screenshots, independent verification that scopes actually block send actions, documentation of a dedicated read-only analytics role.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Adding a scope helps you protect your and your customers’ data by limiting what third parties can access.”

   proof ↗⚑ flag

   Kit—none0/10

   No evidence of scoped or read-only API key/credential creation in Kit's docs; the evidence pack shows general API access, MCP integration, and pricing features but nothing about granular permission scoping or read-only tokens for third parties/agents.

   ⚑ flag

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

   weight 2 · round drawn
   Klaviyo~partialclaimed5/10

   Klaviyo's API supports many core objects (campaigns, contacts, arbitrary data) and even an MCP server for agent-driven actions, but the docs describe UI-only features like drag-and-drop email/SMS editors and visual automation builders that aren't shown to have API equivalents. Missing for 10: explicit evidence that visual template/automation building, reporting dashboards, and other UI-exclusive workflows are fully exposed via API, and independent confirmation of full UI/API parity.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”
   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit~partialprobed5/10

   Kit's docs show a real API and MCP layer that can create/schedule broadcasts and let agents take 'real account actions,' plus a llms.txt manifest, showing meaningful API parity ambition. But no OpenAPI spec is discoverable (404s across expected paths) and there is no evidence the API covers major UI-only features like landing pages/forms, visual automations, digital product sales, or A/B testing — so full UI-API parity is unconfirmed. Missing for 10: documented API coverage for landing pages/forms/commerce/automations, a public OpenAPI/schema reference, and independent confirmation of parity.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “If you are a third party developer, you can use the Kit API to link together or build on top of the Kit platform.”
   • [claimed-docs] “connect the Kit Developer Docs MCP. It queries the live docs so your agent stops working from a cached or hallucinated API surface.”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.kit.com/llms.txt # Kit Developer Documentation - [Welcome](https://developers.kit.com/welcom…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.kit.com/openapi.json, https://developers.kit.com/swagger.json, https://developers…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Klaviyo—none0/10

   Klaviyo has APIs to read data programmatically, but there's no evidence of a bulk data export tool/feature in open formats, nor any documented data-portability or account-export process for users to leave with their data. missing for 10: documented bulk export feature, open-format (e.g., CSV/JSON) full-account export, data portability/exit policy.

   ⚑ flag

   Kit—none0/10

   No evidence pack item documents a data export feature or open-format data portability for Kit; only a vague mention of 'Free migrations' (import-side) appears, with no explicit export/download-your-data capability. Data portability is a fair axis for a SaaS platform, but nothing shows Kit actually supports full open-format export.

   • [claimed-docs] “14-day free trial. No credit card required. Free migrations.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence in the pack mentions data residency, regional storage options, or ability to choose where data is hosted; the docs focus on API scopes, SDKs, and MCP server, not data location controls. missing for 10: any mention of regional data centers, residency options, or data storage location controls.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack mentions data residency, regional storage options, or any data-location controls for Kit.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Klaviyo—none0/10

   No evidence in the pack addresses AI-training data usage policies, opt-outs, or any statement about whether customer data is used to train AI/ML models. missing for 10: explicit AI-training data policy, opt-out mechanism, any privacy/DPA statement about model training.

   ⚑ flag

   Kit—none0/10

   No evidence in the pack addresses AI-training data opt-out or a privacy policy governing use of user/subscriber data for model training; all evidence concerns email marketing features, MCP/API docs, and business history.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence pack items address data retention policies, deletion controls, or export/erasure mechanisms; only API scoping and general auth/testing docs are provided, which don't speak to retention/deletion controls.

   ⚑ flag

   Kit—none0/10

   No evidence pack items address data retention policies, deletion controls, or privacy/data-export mechanisms for AI-native usage; all evidence concerns broadcast features, pricing tiers, and MCP integration.

   ⚑ flag

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

   weight 2 · round drawn
   Klaviyo—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Klaviyo's own tools (e.g., MCP server or SDKs); the docs focus on API auth, scopes, and testing sandboxes, not telemetry controls.

   ⚑ flag

   Kit—none0/10

   No evidence pack items mention telemetry, usage tracking, or opt-out controls for Kit's MCP server, API, or product; the evidence covers unrelated features like broadcasts, pricing, and MCP docs access.

   ⚑ flag

Ai content

1. marketerHave the platform's built-in AI draft or refine subject lines and email copy from a brief, inside the composer

   weight 2 · round drawn
   Klaviyo—none0/10

   Evidence shows an MCP server for external AI agents (Claude, Cursor) to create campaigns via API, not a built-in AI assistant inside Klaviyo's own composer for drafting/refining subject lines and copy from a brief. No documentation of an in-app AI content generation feature is present.

   • [claimed-docs] “You’ll connect Klaviyo’s MCP server to an MCP client, i.e., an AI agent like Claude or Cursor, to get assistance with your Klaviyo data.”
   • [claimed-docs] ““Create an email campaign promoting our Memorial Day sale.””
   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence shows Kit's API/MCP can create or draft broadcasts programmatically and offers A/B testing of subject lines, but there is no mention of an in-composer AI assistant that drafts or refines subject lines/email copy from a marketer's brief inside the editor itself.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “A/B test subject lines & content”
   • [claimed-docs] “Natural-language prompts like “draft a broadcast to my new subscribers from this week” become real account actions.”

   proof ↗⚑ flag

Editor

1. marketerDesign on-brand emails with a visual editor, reusable templates, and personalization tokens that render correctly across clients

   weight 2 · round to Klaviyo
   Klaviyo~partialclaimed4/10

   Evidence confirms Klaviyo has a drag-and-drop email editor and campaign creation API, supporting the visual design part of the story, but there is no mention of reusable template libraries, personalization token syntax, or cross-email-client rendering testing/previews. missing for 10: reusable template library details, personalization token documentation, cross-client rendering/testing evidence.

   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”

   proof ↗⚑ flag

   Kit—none0/10

   The evidence pack covers broadcast API, MCP integration, and pricing feature bullets (automations, A/B testing, collaborative editing) but contains no mention of a visual email editor, reusable templates, or personalization token rendering across email clients. Since this is a core capability marketers would expect from an email platform, the axis clearly applies, but no supporting evidence exists in the pack.

   ⚑ flag

Templates as code

1. developerManage email templates as code — HTML/MJML or API-managed templates with variable substitution — under version control

   weight 2 · round drawn
   Klaviyo—none0/10

   Evidence shows a campaign-creation API and drag-and-drop editors, but nothing about managing email templates as HTML/MJML code, API-managed templates with variable substitution, or version-control workflows for template content.

   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “use the drag-and-drop email/SMS editors and build automations, segmentation and reports”

   proof ↗⚑ flag

   Kit—none0/10

   No evidence of HTML/MJML template files, template-as-code storage, or version-control support for email templates; evidence only covers broadcast creation API, pricing features, and MCP docs tooling.

   ⚑ flag

Transactional api

1. developerSend one-to-one transactional email — receipts, magic links, notifications — through the same platform's API alongside marketing sends

   weight 3 · round drawn
   Klaviyo—none0/10

   Evidence shows Klaviyo's API centers on campaigns, flows, SDKs, and MCP integration for marketing sends, but nothing documents a one-to-one transactional email API (e.g., for receipts or magic links) alongside marketing sends.

   • [claimed-docs] “All `/api` endpoints use private API keys with API key scopes to authenticate requests.”
   • [claimed-docs] “Creates a campaign given a set of parameters, then returns it.”
   • [claimed-docs] “Since Klaviyo doesn't impose a rigid data schema, it's easy to send in just about any arbitrary data without having to do annoying manipulat…”

   proof ↗⚑ flag

   Kit—none0/10

   Evidence shows Kit's API only supports broadcast/campaign sends to subscriber segments or tags (kit-docs-1, kit-docs-2), with no mention of a transactional API for one-to-one sends like receipts or magic links. The axis is fair to ask of an email-sending platform, but nothing in the pack indicates this capability exists.

   • [claimed-docs] “Draft or schedule to send a broadcast to all or a subset of your subscribers.”
   • [claimed-docs] “We currently support targeting your subscribers based on segment or tag ids.”

   proof ↗⚑ flag

Transactional hygiene

1. ops userTransactional email is kept separate from marketing — its own templates, suppression rules, and reputation — so a receipt still delivers to an unsubscribed contact

   weight 2 · round drawn
   Klaviyo—none0/10

   Klaviyo is fundamentally a marketing/email-marketing platform; the evidence pack shows only marketing campaign creation, API scopes, SDKs, and an MCP server — nothing about a distinct transactional-sending pipeline, dedicated transactional templates, separate suppression logic, or isolated sending reputation that bypasses marketing unsubscribes. No mention of transactional email as a concept at all.

   ⚑ flag

   Kit—none0/10

   Kit is positioned as a creator/newsletter marketing platform (broadcasts, automations, landing pages) with no evidence of a distinct transactional-sending system, templates, or suppression-list separation from marketing sends. Nothing in the evidence pack addresses transactional email, receipts, or reputation isolation.

   ⚑ flag