Customer.io vs Kit

Agent access

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

   weight 2 · round drawn
   Customer.io✓fullprobed9/10

   A probe confirms a working llms.txt at docs.customer.io/llms.txt returning structured documentation content, and Customer.io also publishes agent-oriented docs like the MCP get-started guide and CLI/skills for AI assistants. missing for 10: no independent third-party report of an agent successfully consuming llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.customer.io/llms.txt # Customer.io Documentation > Customer.io is a messaging automation platform …”
   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [claimed-docs] “List all active automations in my workspace.”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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 Customer.io
   Customer.io~partialprobed6/10

   Customer.io exposes a documented CLI, REST APIs (Track/Pipelines), an OpenAPI spec, and Postman collection, all of which allow scripting/automation outside the UI — the core building blocks for headless/CI use. However, there is no explicit documentation or example of running these in a CI pipeline (e.g., auth/token setup for automated jobs, CI examples, idempotent scripting patterns), so headless-in-CI is inferred rather than directly evidenced. Missing for 10: explicit CI/pipeline integration docs or examples, authentication guidance for automated/headless contexts, and independent confirmation of CLI use outside interactive sessions.

   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”
   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”

   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
   Customer.io✓fullprobed8/10

   Customer.io publishes an official MCP server (docs.customer.io/ai/mcp/get-started/) that lets an agent list automations, draft emails in Design Studio, and separates reads from writes/deletes for approval control, confirmed by a live probe of the docs page. Missing for 10: independent/hands-on third-party confirmation that the MCP server works as documented and broader detail on setup/auth steps.

   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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 to Customer.io
   Customer.io~partialclaimed5/10

   Docs explicitly mention installing 'the CLI and the skills that teach your AI assistant to use it,' confirming an official CLI exists for AI-native workflows, but no further detail (commands, docs page, install instructions) or independent corroboration is provided. Missing for 10: dedicated CLI reference/docs page, example commands, and independent/hands-on confirmation of the CLI's use.

   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”

   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 Customer.io
   Customer.io✓fullprobed9/10

   Customer.io publishes a documented public API (Track API, Pipelines API, Postman collection) confirmed live via OpenAPI spec probe, plus additional documented programmatic surfaces (CLI, MCP server) for AI-driven use. Missing for 10: independent third-party developer corroboration of API robustness/completeness beyond docs and probes.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.customer.io/llms.txt # Customer.io Documentation > Customer.io is a messaging automation platform …”
   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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 Customer.io
   Customer.io~partialprobed5/10

   The MCP integration separates reads from writes/deletes so users can approve each category independently, which is a form of scoped permissioning for agent actions, but there's no evidence of true API-key-level least-privilege credential issuance (e.g., scoped tokens, role-based API keys, or workspace-level permission scoping for agents) beyond this read/write approval gate. missing for 10: scoped API key/token generation, documented credential-level permission granularity, independent verification of the approval mechanism's enforcement.

   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”
   • [claimed-docs] “List all active automations in my workspace.”

   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 Customer.io
   Customer.io~partialprobed6/10

   Customer.io documents official Track/Pipelines APIs and SDKs for ingesting data, backed by a Postman collection and machine-readable OpenAPI spec (docs-3, docs-6, docs-7, docs-8, probe-2), which supports building AI-native/agentic integrations. However, there's no explicit enumeration of language-specific SDKs (e.g., Node, Python, Java) or independent developer corroboration of SDK quality/completeness beyond one community complaint about lack of code-based flexibility (comm-3). Missing for 10: named list of official SDK languages/repos, independent hands-on corroboration of SDK usability, and versioning/maintenance details.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “The Pipelines API natively supports objects and relationships through the /group endpoint.”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”

   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
   Customer.io—none0/10

   The evidence pack contains no mention of a webhook subscription mechanism (e.g., outbound event notifications for opens, clicks, unsubscribes, etc.); it only covers inbound Track/Pipelines APIs, broadcasts, and the MCP server for AI agent actions. Webhooks are a plausible capability for a messaging platform like Customer.io, but nothing here documents or demonstrates the ability to subscribe to events via webhooks.

   ⚑ 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 Customer.io
   Customer.io~partialclaimed5/10

   Docs show a broader AI assistant that can 'analyze performance' and 'build automations' (docs-1) plus AI in Slack (docs-20) and AI-generated design elements (docs-15/16), suggesting some data-informed suggestions, but there's no dedicated analytics/insights feature that surfaces AI-generated observations or recommendations from customer data specifically. Missing for 10: a documented insights/analytics dashboard powered by AI, concrete examples of data-driven suggestions (e.g. segment or campaign optimization tips), and independent confirmation of this capability in practice.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “Use Customer.io AI in Slack”
   • [claimed-docs] “AI-generated global styles”
   • [claimed-docs] “Draft a welcome email in Design Studio.”

   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 to Customer.io
   Customer.io✓fullclaimed8/10

   Customer.io's core product is journey/automation building that runs autonomously in the background, triggered by events or segment membership, independent of user presence (docs-12, docs-13, docs-18), and this can even be managed/listed via AI/MCP tooling (docs-9). This is well-documented first-party functionality central to the platform's purpose. Missing for 10: independent hands-on verification that automations run reliably at scale without manual intervention (community evidence only discusses unrelated outages/bugs, not automation autonomy specifically).

   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Chain multiple delays together in a single _Wait Until_ block”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”

   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 to Customer.io
   Customer.io~partialprobed6/10

   Customer.io documents a 'Customer.io AI' capable of building automations, drafting messages, and analyzing performance (docs-1, docs-16), with a Slack-based assistant interface (docs-20) and AI-generated design features (docs-15), suggesting some built-in assistant functionality. However, most detailed evidence describes this AI working through an external MCP server/CLI-skills setup (docs-2, docs-9, docs-10, probe-3) rather than a fully native in-product chat assistant, and there's no independent/hands-on confirmation of its reliability. Missing for 10: clear documentation of a native in-app assistant UI (vs. MCP/CLI-only access), and third-party corroboration of task delegation working well.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [claimed-docs] “Use Customer.io AI in Slack”
   • [claimed-docs] “AI-generated global styles”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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 Customer.io
   Customer.io✓fullprobed8/10

   Customer.io documents an official MCP server plus CLI+skills that let an AI assistant perform actions via natural language (list automations, draft emails, build automations) with read/write permission separation, and a Slack AI interface for natural-language operation. Missing for 10: independent/hands-on corroboration of these NL workflows actually working end-to-end beyond first-party docs.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “Install the CLI and the skills that teach your AI assistant to use it”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [claimed-docs] “Use Customer.io AI in Slack”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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 Customer.io
   Customer.io~partialprobed5/10

   Customer.io provides an OpenAPI spec (confirmed live at openapi.json) and a downloadable Postman collection for hands-on API testing, but there's no evidence of an in-browser interactive reference (e.g., Swagger-style 'try it' console) with runnable examples embedded directly in the docs site. Missing for 10: an embedded interactive try-it-now console in the docs, independent confirmation of usability/coverage of the OpenAPI spec.

   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”

   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 to Customer.io
   Customer.io✓fullprobed9/10

   A probe confirms a live, machine-readable OpenAPI spec at https://docs.customer.io/openapi.json returning HTTP 200 with an 'openapi' key, plus a Postman collection is also provided for API onboarding. Missing for 10: independent/community corroboration of developers actually consuming the OpenAPI spec (e.g., via SDK generation).

   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”
   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”

   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 drawn
   Customer.io—none0/10

   No evidence of a sandbox/staging environment or test workspace separate from production; the evidence pack covers API docs, MCP tooling, and pricing features, but nothing about isolated test data or sandbox mode. Community evidence even notes self-serve sign-in/testing was removed after a pricing shift, reinforcing the absence of a documented sandbox capability. missing for 10: dedicated sandbox/staging environment, documentation of test workspaces, isolation guarantees for AI testing without touching production data.

   • [community] “After Series A/leadership change: price hikes based on contact count (not usage), AE outreach began, forced onto annual commitment plans, se…”

   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
   Customer.io—none0/10

   Evidence shows API docs, OpenAPI spec, and Postman collections exist, but there is no mention of API versioning scheme or a documented deprecation policy anywhere in the pack. Missing for 10: explicit API version numbers/headers, changelog or migration guides, and a stated deprecation/sunset policy for older API versions.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”

   proof ↗⚑ 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
   Customer.io—none0/10

   The evidence covers Track/Pipelines APIs for sending data in, broadcast triggering, and MCP for listing automations, but there is no mention of a Reporting/Analytics API or documented endpoints for pulling campaign or flow performance metrics (opens, clicks, conversions, etc.) out to a warehouse or BI tool. Missing for 10: any reporting/metrics API documentation, export/webhook mechanism for performance data, or dashboard-sync examples.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “List all active automations in my workspace.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”

   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
   Customer.io—none0/10

   The evidence pack covers messaging setup, broadcasts, segments, APIs, and MCP/AI tooling, but contains no mention of conversion/revenue attribution reporting tied to specific emails or flows beyond opens/clicks. Missing for 10: any documentation of conversion goals, revenue tracking, or attribution reports linking signups/revenue to specific campaigns or flows.

   ⚑ 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
   Customer.io—none0/10

   The evidence pack contains no documentation of campaign/automation reporting dashboards, open/click/unsubscribe/conversion metrics, or time-series analytics views—only references to triggers, segments, and messaging setup. Missing for 10: any mention of a reporting/analytics UI, per-step conversion tracking, or historical metrics API/export.

   ⚑ 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 Customer.io
   Customer.io~partialprobed4/10

   Customer.io has an MCP server and programmatic APIs (Pipelines/Track) that could plausibly let an AI agent create segments, and docs show natural-language MCP commands like listing automations or drafting emails, but no evidence explicitly shows an agent translating a plain-language description into a created segment via API/MCP. missing for 10: a concrete example of segment creation through the API/MCP, documentation of segment-definition endpoints, and independent confirmation this works end-to-end.

   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”
   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”

   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 Customer.io
   Customer.io~partialprobed6/10

   Docs confirm the Pipelines/Track API for creating/updating profiles with custom properties, plus a documented pattern for suppression (sending a 'Suppress Person' event) and deletion, and an OpenAPI spec/Postman collection support production integration. However, there is no explicit evidence of rate limits, batch/bulk endpoints, or production-scale guarantees, and one community report cites bugs with the system as a reason for switching providers. missing for 10: explicit production-scale/rate-limit documentation, independent verification of suppression at scale, and confirmation that the 'delete/suppress via event' pattern is robust in practice.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “We've generated a Postman collection to help you get started with our APIs.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.customer.io/openapi.json — contains "openapi" key”
   • [community] “'We used customer.io for the past few months but due to bugs with the system, we switched to sendwithus with sendgrid as our ESP. We've been…”

   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 to Customer.io
   Customer.io~partialcommunity3/10

   Docs confirm segments exist as a concept (docs-11) and that objects/relationships can be managed via the Track/Pipelines API's /group endpoint (docs-6, docs-7), implying some programmatic control over customer data groupings, but there is no direct evidence of an API to create/update segments, tags, or lists, nor any documented way to read back exact membership. A community report even cites 'lack of code-based flexibility for defining segments' as a driver for building an alternative (comm-3), suggesting real limitations in programmatic segment management. missing for 10: explicit API endpoints for segment/tag/list CRUD, membership read-back examples, and independent confirmation that these work as described.

   • [claimed-docs] “The Pipelines API natively supports objects and relationships through the /group endpoint.”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”

   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 to Customer.io
   Customer.io✓fullcommunity7/10

   Docs describe building segments (e.g., 'Paying Customers', 'Have not logged in recently') from attribute conditions and events, and automations can trigger when profiles join segments, implying live-updating segment membership as data changes. However, tags-based segmentation isn't explicitly documented, and one community post notes frustration with 'lack of code-based flexibility for defining segments,' suggesting some limitations in segment logic sophistication. Missing for 10: explicit tag-criteria documentation, independent confirmation of real-time segment recalculation, and rebuttal to the code-flexibility complaint.

   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”

   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 drawn
   Customer.io~partialclaimed5/10

   Customer.io supports bulk-style actions like triggering a Broadcast to an entire list of recipients at once and triggering automations when profiles join a Segment (docs-4, docs-13, docs-12), which are genuine bulk operations. However there's no explicit evidence of a bulk/batch API endpoint for mass profile updates, imports, or deletions, nor of the MCP/CLI AI tools performing multi-item bulk actions in one command. Missing for 10: documented bulk/batch API endpoints (e.g. batch import, bulk update/delete), evidence of AI assistant executing bulk operations across many items via MCP/CLI, and independent confirmation of bulk operation reliability at scale.

   • [claimed-docs] “Trigger broadcasts: you'll set up a broadcast in our UI and then trigger it with a single call.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “The Pipelines API natively supports objects and relationships through the /group endpoint.”

   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 Customer.io
   Customer.io✓fullclaimed8/10

   Customer.io's journeys/automations natively trigger actions when profiles perform events or join segments, with rich workflow features like Wait Until delays and branching, and this is fully documented as core product functionality. missing for 10: independent/hands-on verification of automation reliability at scale, and more detail on complex multi-condition rule logic beyond events/segments.

   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [claimed-docs] “Chain multiple delays together in a single _Wait Until_ block”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Transactional messages are ideal for: Purchase receipts, Registration confirmations, Password resets, Event reminders, Shipping updates”

   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 to Customer.io
   Customer.io~partialprobed6/10

   Customer.io's core platform natively supports recurring/triggered workflows (automations triggered by events/segments, chained Wait Until delays, scheduled broadcasts) and docs claim AI can 'build automations' via the CLI/MCP, with MCP able to list active automations. However, there is no concrete evidence of an AI agent actually creating or scheduling a new recurring workflow end-to-end (writes/deletes require separate approval, and only read/list and draft-email examples are shown). missing for 10: a documented example of AI creating/editing a recurring automation via MCP or CLI, independent confirmation of AI-driven automation authoring succeeding.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Chain multiple delays together in a single _Wait Until_ block”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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
   Customer.io—none0/10

   No evidence of version control, review/approval workflows for automation changes, or rollback of automations. The MCP docs mention read/write approval separation for actions but nothing about versioning or reverting automation states over time.

   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”

   proof ↗⚑ 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
   Customer.io~partialprobed5/10

   Customer.io's MCP server explicitly separates reads from writes/deletes so a human can approve each category independently, and docs show AI drafting content (welcome emails, automations) and broadcasts being queued to send at a specified time to a defined recipient list/segment — this supports an approval-gated, agent-drafted campaign workflow. However, there's no direct evidence of an agent drafting a full campaign against a segment specifically and leaving it in a 'scheduled/queued pending human approval' state as one integrated flow; the approval mechanism (read/write separation) and scheduled broadcast feature are documented separately, not as a combined AI-driven approval-to-send pipeline. missing for 10: an end-to-end example of an agent creating a segment-targeted campaign draft and explicitly queuing it for human approval before send, and independent/hands-on confirmation this works as described.

   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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
   Customer.io~partialclaimed3/10

   Customer.io's own docs state that broadcasts must first be configured in the UI and can then only be triggered via a single API call, directly contradicting the 'entirely through API' requirement; there is no documented endpoint to create or schedule a broadcast/campaign purely programmatically. Missing for 10: a documented API endpoint for creating/scheduling broadcasts or campaigns (not just triggering pre-built ones), and confirmation that campaign scheduling doesn't require dashboard configuration.

   • [claimed-docs] “Trigger broadcasts: you'll set up a broadcast in our UI and then trigger it with a single call.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”

   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
   Customer.io✓fullclaimed7/10

   Docs show the core loop: segments for audience selection (docs-11), broadcasts queued to defined recipients at a specified time (docs-13), UI-based broadcast setup with trigger API (docs-4), and Design Studio/drag-and-drop editor for composing messages (docs-16, docs-17). This covers compose, pick audience, and send/schedule as table-stakes. Missing for 10: independent hands-on corroboration of the end-to-end flow and explicit UI screenshots/docs of a scheduling calendar interface (only inferred from 'time you specify').

   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Trigger broadcasts: you'll set up a broadcast in our UI and then trigger it with a single call.”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [claimed-docs] “Drag-and-drop visual editor Included Included Included Code editor Included”

   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
   Customer.io—none0/10

   No evidence in the pack mentions A/B testing of subject lines or content variants, nor any mechanism for automatically selecting a winner based on engagement metrics; broadcasts, transactional messages, and automations are described but split-testing is never referenced.

   ⚑ 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
   Customer.io—none0/10

   No evidence in the pack mentions bounce, complaint, or blocklist tracking, deliverability dashboards, or actionable guidance for degraded sending reputation; the docs focus on automations, broadcasts, AI/MCP tooling, and pricing features unrelated to deliverability signals.

   ⚑ 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
   Customer.io—none0/10

   No evidence in the pack addresses domain authentication (SPF/DKIM/DMARC) setup, guided DNS configuration, or verification workflows for sending domains — all evidence concerns AI/MCP integrations, APIs, journeys, and pricing.

   ⚑ 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 to Customer.io
   Customer.io~partialclaimed3/10

   Docs mention a 'Suppress Person' event and an 'Unsubscribed' segment, implying some suppression capability, but there is no evidence describing automatic bounce or spam-complaint suppression, nor confirmation that suppression is honored uniformly across broadcasts, transactional, and journey sends. Missing for 10: documented bounce/spam-complaint auto-suppression, explicit cross-send-type enforcement, and any compliance (CAN-SPAM/GDPR) framing.

   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”

   proof ↗⚑ 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 to Customer.io
   Customer.io~partialclaimed4/10

   Docs confirm Customer.io has a Pipelines/Track API that 'most of our integrations are based on' and note users can 'use your preferred tools and sources to transit data through Customer.io,' implying an integrations ecosystem exists, but no evidence names or documents maintained first-party connectors for Stripe, Shopify, Segment, or a product database specifically. missing for 10: explicit documentation of named Stripe/Shopify/Segment/CDP integrations, integration marketplace listing, maintenance/versioning details for these connectors.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “you can also use your preferred tools and sources to transit data through Customer.io. It's up to you!”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”

   proof ↗⚑ 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
   Customer.io—none0/10

   The evidence pack covers inbound APIs (Track/Pipelines API), MCP tooling, and broadcast/journey features, but contains no mention of outbound webhooks for delivery/engagement events (sends, opens, clicks, bounces, unsubscribes) or of signed payload verification. missing for 10: documentation of webhook subscription endpoints/UI, event types supported, payload signing/verification mechanism, and any independent confirmation of reliability.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”

   proof ↗⚑ 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 to Customer.io
   Customer.io~partialcommunity6/10

   Docs confirm core lifecycle-automation building blocks: triggering journeys off events/segments (docs-12), chaining multiple delays in a Wait Until block (docs-18), listing active automations (docs-9), and segment-based audience targeting (docs-11). However, the evidence pack never explicitly documents branching logic or exit-rule configuration, the two specific mechanics named in the story, and one community report cites frustration with limited flexibility in defining email flows (customer-io-comm-3). Missing for 10: explicit documentation of conditional branch splits and exit-rule/goal settings within a journey, plus independent hands-on confirmation of multi-step welcome/onboarding/winback builds.

   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “Chain multiple delays together in a single _Wait Until_ block”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”

   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 Customer.io
   Customer.io✓fullclaimed8/10

   Docs clearly describe sending real-time custom events via the Track/Pipelines API (docs-3, docs-7) and triggering automations specifically when a profile performs an event (docs-12), which directly matches the developer story of firing an event to trigger a person-specific automation. Missing for 10: independent/hands-on confirmation that per-person triggering works reliably at scale, and more detail on event payload/attribute matching nuances.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “you can also use your preferred tools and sources to transit data through Customer.io. It's up to you!”

   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
   Customer.io—none0/10

   No evidence describes a per-person view of automation/journey progress or an ops action to pull or re-enter a profile without breaking the flow; docs cover triggering automations, segments, and broadcasts but not individual journey-state visibility or manual re-entry controls.

   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”

   proof ↗⚑ 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
   Customer.io—none0/10

   The evidence pack only documents APIs for sending data INTO Customer.io (Track API, Pipelines API, suppression via events) and MCP-based automation reads, but contains no mention of a bulk data export, audience/contact export tool, or open-format download of engagement history and suppression lists. No self-serve export capability is evidenced anywhere in the pack. Missing for 10: any documentation of an export/download feature, open-format (CSV/JSON) audience export, or bulk API read endpoint for full contact/tag/engagement/suppression data.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”

   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
   Customer.io—none0/10

   No evidence of a guided migration tool or import wizard that preserves tags, custom fields, and unsubscribe state from another ESP. Docs discuss general data ingestion via Track/Pipelines API and profile suppression events, but nothing about a dedicated migration/import feature for list portability.

   ⚑ 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 Customer.io
   Customer.io~partialprobed6/10

   Customer.io ships an official MCP server (customer-io-probe-3) that lets an AI list automations (customer-io-docs-9) and separates reads from writes for safe automated access (customer-io-docs-10); docs also describe segments/audiences (customer-io-docs-11) and broadcast/automation structures (customer-io-docs-12, customer-io-docs-13) that an agent could query. However, the story also asks for 'recent campaign results' reporting, and evidence only vaguely claims AI can 'analyze performance' (customer-io-docs-1) without showing a concrete reporting/analytics API or MCP tool for campaign metrics. Missing for 10: explicit documentation of a reporting/analytics endpoint or MCP tool for campaign results, and independent/hands-on confirmation that an agent can actually pull full program state (audiences+automations+results) end-to-end.

   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”
   • [claimed-docs] “List all active automations in my workspace.”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”
   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”

   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
   Customer.io—none0/10

   The evidence pack covers sending data in (Track/Pipelines API), triggering broadcasts, and AI/MCP automation management, but contains no documentation of an API endpoint for reading a contact's engagement history (messages sent, opened, clicked). Missing for 10: any mention of an Activities/Customer Journey read API, endpoint docs for per-person message history, or examples returning open/click events for a contact.

   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”

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

   The evidence shows Customer.io's MCP integration separates reads from writes for AI-action approval (customer-io-docs-10), but there is no evidence of an admin-configurable mechanism to mint scoped or read-only API keys/credentials for external agents or contractors to access analytics data without send capability.

   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”

   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 to Kit
   Customer.io!disputedcontradicted4/10

   Customer.io explicitly claims 'Your AI can do anything you'd do by clicking or typing' (docs-1) and ships a Pipelines/Track API plus MCP server, but its own docs contradict full parity: broadcasts must be set up in the UI and only triggered via API (docs-4), and segments/journeys are shown as UI-defined constructs (docs-11, docs-12). Independent evidence reinforces this gap—a developer built an open-source alternative specifically due to 'lack of code-based flexibility for defining segments and email flows' (customer-io-comm-3). missing for 10: API-only creation of broadcasts/segments/email flows without prior UI setup, and independent confirmation that MCP/API coverage matches 100% of UI functionality.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “Trigger broadcasts: you'll set up a broadcast in our UI and then trigger it with a single call.”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”
   • [claimed-docs] “You can trigger automations when profiles perform events, when they join Segments (e.g. they meet attribute conditions), and so on.”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”
   • [probe] “official MCP server documented at https://docs.customer.io/ai/mcp/get-started/”

   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
   Customer.io—none0/10

   Evidence shows APIs for getting data in and out (Track/Pipelines API) but no documented bulk data export tool or open-format full account export/portability feature, nor any 'leave with your data' guarantee. No mention of GDPR-style export or data portability commitments.

   ⚑ 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
   Customer.io—none0/10

   No evidence in the pack mentions data residency options, regional storage selection, or EU/US hosting choices for Customer.io.

   ⚑ 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
   Customer.io—none0/10

   No evidence in the pack addresses AI-model training opt-out or data usage controls for Customer.io; all citations concern messaging automation, APIs, and MCP tooling, not AI training data policy.

   ⚑ 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 to Customer.io
   Customer.io~partialclaimed6/10

   Customer.io documents explicit mechanisms to delete or suppress profile data via the Track API (Delete Person / Suppress Person events), and its MCP server separates delete operations from reads/writes for explicit approval, giving AI-native users some control over data removal. However, there's no documented retention-policy settings, automated data expiry, bulk/GDPR-scale deletion tooling, or audit trail for deletions. Missing for 10: configurable retention periods, bulk/automated deletion workflows, compliance/audit documentation, independent verification that deletion requests are honored.

   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “Reads are separated from writes and deletes... so you can approve each category independently.”

   proof ↗⚑ 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
   Customer.io—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out settings for AI features or the product itself; the docs focus on API/MCP capabilities, not privacy controls. missing for 10: any mention of telemetry collection, opt-out mechanism, or usage-tracking settings.

   ⚑ 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 to Customer.io
   Customer.io~partialclaimed5/10

   Docs confirm broad AI drafting ability ('draft messages', 'Draft a welcome email in Design Studio', 'AI-generated global styles') and an AI assistant reachable via MCP/CLI/Slack, implying some copy-generation capability, but none of the evidence specifically describes subject-line drafting/refinement or copy editing embedded directly inside the message composer UI. Missing for 10: explicit documentation of an in-composer AI subject-line/body-copy assistant, a described 'brief-to-draft' workflow, and independent/hands-on confirmation of this specific feature.

   • [claimed-docs] “Your AI can do anything you'd do by clicking or typing in Customer.io. That means you can have it build automations, draft messages, analyze…”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [claimed-docs] “AI-generated global styles”
   • [claimed-docs] “Use Customer.io AI in Slack”

   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 Customer.io
   Customer.io~partialclaimed5/10

   Docs confirm a drag-and-drop visual editor, code editor, AI-generated global styles, and a Design Studio for drafting emails, showing on-brand visual design tooling. However, there is no explicit evidence of reusable template libraries, personalization token syntax, or cross-email-client rendering/testing guarantees, which are core parts of this story. Missing for 10: reusable template management, personalization token documentation, cross-client rendering testing/preview evidence.

   • [claimed-docs] “AI-generated global styles”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [claimed-docs] “Drag-and-drop visual editor Included Included Included Code editor Included”

   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 to Customer.io
   Customer.io~partialcommunity3/10

   Docs mention a 'Code editor' included in the Design Studio for building emails (docs-17) and a Pipelines/Track API for data, but there is no evidence of dedicated template CRUD API endpoints, MJML support, or a documented git/version-control workflow for templates; a community developer even built an OSS alternative citing lack of code-based flexibility for email flows (customer-io-comm-3). missing for 10: template API endpoints with variable substitution docs, MJML/HTML-as-code workflow, version-control integration or CLI template sync.

   • [claimed-docs] “Drag-and-drop visual editor Included Included Included Code editor Included”
   • [claimed-docs] “Draft a welcome email in Design Studio.”
   • [community] “Developer built an open-source alternative 'after getting frustrated with Customer.io's limitations,' citing lack of code-based flexibility …”

   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 to Customer.io
   Customer.io~partialclaimed6/10

   Docs confirm transactional message use cases (receipts, password resets, shipping updates) and a Track/Pipelines API for sending real-time customer data and events, alongside the same platform's broadcast/marketing capabilities, supporting one-to-one and marketing sends via one API. However, there is no explicit developer-facing example of sending a single transactional message via API call (e.g., a dedicated Transactional API endpoint with code sample) or confirmation of independent/hands-on verification of transactional deliverability. missing for 10: explicit Transactional API code example/endpoint documentation, independent hands-on confirmation of transactional send reliability, clarification on rate/latency guarantees for one-to-one sends.

   • [claimed-docs] “Transactional messages are ideal for: Purchase receipts, Registration confirmations, Password resets, Event reminders, Shipping updates”
   • [claimed-docs] “Our Track API provides ways to send real-time customer data to your Customer.io workspace including customer identification and event tracki…”
   • [claimed-docs] “To get data into Customer.io, use an SDK or the Pipelines API. This is the API that most of our integrations are based on and likely the API…”
   • [claimed-docs] “Broadcasts send a message to a list of recipients. Broadcast messages are queued to send to all the defined recipients at a time you specify…”

   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 to Customer.io
   Customer.io~partialclaimed5/10

   Docs confirm transactional messaging exists for receipts, confirmations, password resets, etc. (customer-io-docs-14), and separate suppression events can be sent via API (customer-io-docs-5), but there is no explicit documentation of separate deliverability/reputation isolation between transactional and marketing sending, nor confirmation that suppressing a marketing contact does not block transactional receipts. missing for 10: explicit statement that transactional sending reputation/IP pool is isolated from marketing, documented suppression-list scoping (transactional vs marketing), and independent/hands-on confirmation that an unsubscribed contact still receives a transactional receipt.

   • [claimed-docs] “Transactional messages are ideal for: Purchase receipts, Registration confirmations, Password resets, Event reminders, Shipping updates”
   • [claimed-docs] “if you wanted to delete a profile, you'd send a track event with a name parameter called Delete Person. If you want to suppress a profile, y…”
   • [claimed-docs] “If you go to the Segments page, you'll see segments like "Paying Customers", "Have not logged in recently" and "Unsubscribed".”

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