Loops vs Customer.io

Agent access

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

   weight 2 · round drawn
   Loops✓fullprobed9/10

   Loops has a live, probe-confirmed llms.txt (loops-probe-1) with dedicated agent-oriented docs at /agents and /agents/api, plus an OpenAPI spec (loops-probe-3) and MCP server for agent connectivity (loops-docs-6, loops-probe-4). Missing for 10: independent hands-on confirmation that an agent successfully consumes llms.txt end-to-end rather than just server availability.

   • [probe] “PROBE llms.txt: HTTP 200 at https://loops.so/llms.txt # Loops > Loops is an email platform for software companies. Send transactional and m…”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Loops~partialprobed6/10

   Loops exposes a REST API with Bearer-token auth, an OpenAPI spec, and a CLI for terminal-based contact/event/email management, which supports scripted/CI usage. However, evidence doesn't explicitly confirm a headless automation workflow (e.g., CI pipeline examples, non-interactive auth for automation, or documented CI recipes) beyond API/CLI existence. Missing for 10: explicit CI/CD examples or automation-pipeline documentation, evidence of non-interactive/service-account auth flow, and independent confirmation of headless use in production automation.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Manage contacts, send events, and test transactional email from your terminal”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Loops✓fullprobed8/10

   Loops documents an official MCP server ('Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.') with a dedicated docs page, backed by a first-party API and CLI/skills for agent integration. Missing for 10: independent/hands-on verification of the MCP server working end-to-end and more detail on setup/auth for MCP specifically.

   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round to Loops
   Loops✓fullclaimed8/10

   Loops documents an official CLI ('Manage contacts, send events, and test transactional email from your terminal' and 'Install the CLI and skills with one command so your coding agent can use Loops for you'), explicitly positioned for AI-native/agentic workflows. Missing for 10: independent hands-on verification of the CLI's functionality and no detailed command reference in the evidence pack.

   • [claimed-docs] “Manage contacts, send events, and test transactional email from your terminal”
   • [claimed-docs] “Install the CLI and skills with one command so your coding agent can use Loops for you.”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Loops✓fullprobed9/10

   Loops provides a documented public REST API with authentication (Bearer token), endpoints for events, contacts, campaigns, and email sending, plus an OpenAPI spec (confirmed live at /openapi.json) and SDKs/CLI for programmatic access. This clearly enables an AI-native user to drive the product entirely via API. Missing for 10: independent third-party developer corroboration of API robustness/versioning in practice beyond founder claims.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Add Loops to your application in minutes with our SDKs.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Customer.io
   Loops—none0/10

   Evidence shows a single Bearer-token API key auth model with no mention of scoped, restricted-permission, or per-agent credentials — only a full-access API key pattern is documented across docs, MCP, and CLI. No evidence of least-privilege or scoped token issuance.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Loops
   Loops✓fullprobed8/10

   Loops documents official SDKs plus a REST API with Bearer auth, an OpenAPI spec, and a CLI/skills installer for coding agents, indicating strong AI-native SDK support beyond just docs. missing for 10: independent hands-on developer confirmation of SDK reliability/coverage across languages, and no explicit list of supported languages beyond generic 'SDKs' mention.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “Add Loops to your application in minutes with our SDKs.”
   • [claimed-docs] “Install the CLI and skills with one command so your coding agent can use Loops for you.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Loops—none0/10

   Evidence shows Loops lets users send events INTO Loops (POST /events/send) and use APIs/MCP/CLI to manage contacts and campaigns, but there is no mention of Loops emitting outbound webhooks that a user's system could subscribe to for platform events (e.g., opens, bounces, unsubscribes). Missing for 10: any documentation of a webhook subscription/callback mechanism, webhook payload schema, or webhook management endpoint.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Customer.io
   Loops—none0/10

   Loops documents analytics/segmentation (loops-docs-16), campaign drafting via API, and an email 'Guardian' check (loops-docs-19), but none of this evidence describes AI-generated insights or suggestions derived from a customer's data (e.g., predictive recommendations, anomaly detection, or AI-surfaced trends). The agent/API/MCP features are about enabling external agents to act on Loops, not the product itself surfacing AI insights.

   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [claimed-docs] “Run Guardian checks on an email message”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Customer.io
   Loops✓fullclaimed6/10

   Loops supports event-triggered workflows (POST /events/send triggers workflows) and lifecycle automations (onboarding, activation, upgrade, winback emails) that are 'set up once' and run autonomously over time, which is the core of background automation for an email/lifecycle platform. Missing for 10: detailed documentation of workflow logic (branching, delays, conditions), and independent/hands-on corroboration that these automations reliably run unattended long-term.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “Reach users after they close the tab. Set up onboarding, activation, upgrade, and winback emails once, then improve them over time.”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Customer.io
   Loops—none0/10

   Loops' 'agents' materials describe APIs/MCP/CLI/skills that let external coding agents (Claude, Cursor, etc.) act on Loops on the user's behalf — this is Loops being consumed by an agent, not a built-in AI assistant living inside the Loops product that a user delegates tasks to. No evidence of an in-app assistant (e.g., an AI chat/copilot embedded in the Loops dashboard) exists in the pack.

   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “Install the CLI and skills with one command so your coding agent can use Loops for you.”
   • [claimed-docs] “I scanned your codebase and found every send, template, and webhook. Each one maps to a Loops equivalent, so I swapped the API calls and reb…”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Customer.io
   Loops~partialprobed6/10

   Loops provides an MCP server and CLI/skills that let an AI agent operate Loops via natural-language-driven tool calls (create contacts, send events, draft campaigns, run Guardian checks) rather than requiring manual API scripting, which supports agentic/natural-language operation. However, the evidence is all vendor docs describing agent-facing surfaces (MCP, CLI, API) rather than a chat/NL command interface for end-users themselves, and there's no independent/hands-on confirmation of how well natural-language control actually works. Missing for 10: independent verification of natural-language command execution, evidence of an end-user-facing NL/chat interface (not just agent APIs/MCP), and confirmation of reliability/quality of agent-driven actions in practice.

   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “Install the CLI and skills with one command so your coding agent can use Loops for you.”
   • [claimed-docs] “Run Guardian checks on an email message”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round to Customer.io
   Loops~partialprobed4/10

   Loops documents API endpoints (contacts, events, Guardian checks) and exposes a valid openapi.json spec, suggesting a structured API reference exists, but there's no evidence of an interactive 'try it now' console or runnable code examples within the docs themselves. Missing for 10: explicit interactive/try-it API console, runnable code snippets in docs, independent confirmation of the reference UI's interactivity.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Run Guardian checks on an email message”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Loops✓fullprobed9/10

   A probe confirms a valid OpenAPI spec is served at https://loops.so/openapi.json (contains an 'openapi' key, HTTP 200), and this is complemented by full API reference docs. Missing for 10: independent third-party confirmation that the spec is complete/versioned or widely used by external tooling.

   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Loops—none0/10

   No evidence of a sandbox/test environment, test API keys, or staging mode separate from production data; docs cover API auth, SDKs, MCP, and migration guides but nothing about sandboxing. Missing for 10: dedicated sandbox/test-mode environment, test API keys or data isolation guarantees, documentation of a non-production testing workflow.

   ⚑ flag

   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

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

   weight 2 · round to Loops
   Loops~partialprobed3/10

   A founder comment mentions the API has versioning ('performant API with versioning for transactional email') and an OpenAPI spec is exposed, but there is no documented deprecation policy, version lifecycle, or migration guidance anywhere in the evidence. Missing for 10: documented deprecation/sunset policy, versioning scheme details, migration guides between API versions.

   • [community] “Founder describes Loops' approach: simplified pricing (no tables, one metric), performant API with versioning for transactional email, text-…”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

Api metrics

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

   weight 2 · round drawn
   Loops—none0/10

   Evidence covers API endpoints for creating contacts, sending events, drafting campaign content, and MCP integration, but nothing documents an endpoint for retrieving campaign or flow performance metrics (opens, clicks, conversions, revenue) via API for warehousing or BI use. The analytics mentioned (e.g., 'see which emails lead to upgrades') appear to be dashboard-only features, not exposed via API.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

Attribution

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

   weight 2 · round to Loops
   Loops~partialclaimed5/10

   Loops explicitly markets seeing 'which emails lead to upgrades, lower churn, and add revenue' with dynamic segments, suggesting some revenue/conversion attribution beyond opens/clicks, but this is a single marketing-page claim with no detail on methodology, dashboards, or per-flow attribution granularity, and no independent or hands-on corroboration exists in the evidence pack. Missing for 10: detailed docs on how revenue/signup attribution is computed, screenshots or hands-on reports of attribution reporting, and third-party validation.

   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”

   proof ↗⚑ flag

   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

Reporting core

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

   weight 3 · round drawn
   Loops—none0/10

   Evidence covers Loops' API, SDKs, CLI, MCP, and migration tooling, plus a generic mention of segmentation revenue impact, but there is no documentation of an analytics dashboard or API reporting opens, clicks, unsubscribes, and conversions per campaign or per automation step over time. Missing for 10: any analytics/reporting endpoint or dashboard docs showing per-campaign/per-step metrics, time-series breakdowns, or conversion attribution.

   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”

   proof ↗⚑ flag

   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

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

   While Loops exposes API endpoints for contacts, events, and campaign content (loops-docs-3, loops-docs-4, loops-docs-6), and mentions segments only as a dashboard feature that stays dynamic (loops-docs-16), there is no documented endpoint or MCP tool for creating or defining an audience segment programmatically from a natural-language description. No evidence shows an agent can translate plain-language criteria into a real segment via the API or MCP surface.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”

   proof ↗⚑ flag

   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

Api contacts

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

   weight 3 · round to Customer.io
   Loops~partialprobed4/10

   Evidence confirms a REST API with bearer-token auth and a POST /contacts/create endpoint plus an OpenAPI spec, and dynamic segment properties are mentioned, implying custom contact properties exist. However, there is no explicit documentation of contact update or suppression endpoints, nor any mention of rate limits, bulk operations, or production-scale guarantees. Missing for 10: explicit contacts/update and suppression API endpoints, documented custom-property schema support, and evidence of production-scale throughput/rate limits.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

Api segments

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

   weight 3 · round to Loops
   Loops~partialprobed4/10

   Loops' API supports creating/updating contacts and triggering events (loops-docs-4, loops-docs-3), and segments are described as dynamic (loops-docs-16), but no evidence shows an endpoint to read back which contacts belong to a segment, tag, or list. Missing for 10: documented GET/list endpoints for contacts by segment/tag/list, and confirmation that programmatic tag/list membership queries are supported.

   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   Loops explicitly claims segments are built from profile properties and stay dynamic as data changes (loops-docs-16), and the API supports contacts with properties and events that trigger workflows (loops-docs-3, loops-docs-4), suggesting behavioral/event-based segmentation is possible. However, there's no explicit documentation of tag-based segmentation or a dedicated segment-builder UI walkthrough, and no independent/hands-on confirmation of live segment updates. Missing for 10: explicit tag-attribute mention, segment-builder UI documentation, and independent corroboration of segments staying live.

   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Customer.io
   Loops—none0/10

   Evidence shows only single-item API operations (create one contact, send one event, send one transactional email) and no documented bulk/batch endpoints, CSV import, or bulk update/segment operations for AI agents to invoke at scale.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Send transactional emails with dynamic data variables, right from your backend.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Customer.io
   Loops~partialclaimed6/10

   Loops' event API explicitly triggers workflows ('Send an event to trigger workflows') and marketing copy references onboarding/activation/winback flows set up once and running automatically, matching the rule-on-event automation pattern. However, the evidence pack lacks detail on how rules/conditions are authored (branching logic, if/then rules, workflow builder specifics) beyond the event-trigger primitive. Missing for 10: documentation of conditional rule logic/branching in workflows, independent hands-on confirmation of workflow automation depth.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “Reach users after they close the tab. Set up onboarding, activation, upgrade, and winback emails once, then improve them over time.”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”

   proof ↗⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Customer.io
   Loops~partialclaimed4/10

   Loops supports event-triggered workflows (POST /events/send) and lifecycle emails (onboarding, winback, etc.) that run automatically once set up, which touches on workflow automation, but there is no evidence of an API or agent-facing capability to schedule recurring jobs/crons directly — workflow triggers are event-based and configured largely via the dashboard. missing for 10: explicit recurring/cron scheduling API, agent-driven workflow creation beyond event triggers, independent confirmation of automation depth.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “Reach users after they close the tab. Set up onboarding, activation, upgrade, and winback emails once, then improve them over time.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Loops—none0/10

   Loops evidence covers email campaign creation, API/MCP integration, and content authoring, but there is no mention of versioning, reviewing changes, or rolling back automations/workflows — the closest is draft campaigns reviewed before sending, which is not version history or rollback.

   ⚑ flag

   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

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

   Loops explicitly supports agents creating draft campaigns via API that are then reviewed/sent from the dashboard (loops-docs-5, loops-docs-9), and has API/MCP access for contacts, events, and content (loops-docs-3,4,6). However, there's no explicit evidence of segment targeting being part of the drafted campaign creation flow, nor of a 'scheduled/queued' state distinct from 'draft awaiting dashboard review' — the described flow is draft-then-manual-send rather than draft-then-schedule-with-approval-gate. missing for 10: explicit mention of segment-targeted campaign creation via API, a distinct 'scheduled pending approval' state vs plain draft, and independent/hands-on confirmation of this human-approval workflow.

   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”

   proof ↗⚑ flag

   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

Api campaigns

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

   weight 3 · round to Loops
   Loops~partialclaimed4/10

   Loops documents a Content API that lets developers create draft campaigns via API, but its own docs explicitly state that review and sending happen from the dashboard ('Create draft campaigns... Review and send from the dashboard'), directly contradicting the 'without touching the dashboard' requirement for sending/scheduling. Missing for 10: documented API endpoints for scheduling/sending a campaign, evidence of full campaign lifecycle (create+schedule+send) without dashboard interaction, and independent confirmation of this workflow.

   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”

   proof ↗⚑ flag

   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

Campaign core

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

   weight 3 · round drawn
   Loops✓fullclaimed7/10

   Docs describe composing campaigns via editor or Content API, segmenting/targeting dynamic audiences, and sending from the dashboard, covering the core compose→audience→send loop (loops-docs-5, loops-docs-9, loops-docs-16, loops-docs-17, loops-docs-18). Missing for 10: explicit documentation of a 'schedule for later' feature and independent/hands-on confirmation of the end-to-end campaign flow (community evidence only covers pricing/editor tech, not campaign sending itself).

   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [claimed-docs] “Set your colors, type, and spacing in one place. Every email you send picks them up automatically, so your brand stays consistent without an…”
   • [claimed-docs] “How to craft an email using our editor”

   proof ↗⚑ flag

   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

Experiments

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

   weight 2 · round drawn
   Loops—none0/10

   No evidence in the pack mentions A/B testing of subject lines or content, nor any automated winner-selection based on engagement metrics; docs cover campaigns, transactional email, contacts, and API/MCP integration but not split-testing functionality.

   ⚑ flag

   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

Deliverability signals

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

   weight 2 · round drawn
   Loops—none0/10

   The evidence pack has no mention of bounce, complaint, or blocklist tracking per send, nor any deliverability health dashboard or actionable guidance when deliverability degrades; the closest item ('Guardian checks on an email message') is vague and not tied to bounce/complaint/blocklist metrics. Missing for 10: per-send bounce/complaint/blocklist reporting, deliverability health dashboard, automated alerts or actionable remediation guidance.

   • [claimed-docs] “Run Guardian checks on an email message”

   proof ↗⚑ flag

   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

Domain auth

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

   weight 3 · round drawn
   Loops—none0/10

   No evidence in the pack describes domain authentication setup (SPF/DKIM/DMARC), DNS record guidance, or verification tooling; one migration doc merely mentions 'verify your domain' as a step without detail. missing for 10: DNS setup guide, SPF/DKIM/DMARC record instructions, verification status UI or API, any deliverability-domain documentation.

   • [claimed-docs] “Move transactional email, contacts, and lists from Brevo to Loops: swap the SDK, map each call, verify your domain, and cut over one email t…”

   proof ↗⚑ flag

   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

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

   No evidence pack items describe automatic suppression of unsubscribes, bounces, or spam complaints, nor honoring suppression lists across transactional and marketing sends; the community thread even raises a concern about pricing encouraging unlimited sends without addressing suppression handling. Missing for 10: documentation of automatic unsubscribe/bounce/complaint suppression, cross-send-type enforcement, and CAN-SPAM/GDPR compliance details.

   • [community] “Concern raised: 'your service seems priced in a way that encourages spam (send unlimited emails to an address)' regarding deliverability/ded…”

   proof ↗⚑ flag

   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

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

   Evidence only shows generic API/SDK/events/contacts endpoints and migration guides from competing ESPs (Brevo, Customer.io) — there is no mention of maintained first-party integrations with Stripe, Shopify, Segment, or a product database. Ops users would need to build custom API/webhook connections themselves rather than use a documented native integration.

   ⚑ flag

   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

Webhooks

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

   weight 3 · round drawn
   Loops—none0/10

   No evidence pack item mentions webhooks for delivery/engagement events (sends, opens, clicks, bounces, unsubscribes) or signed payloads; the docs focus on REST API, MCP, CLI, and events for triggering workflows, not outbound webhook subscriptions. Missing for 10: any webhook subscription endpoint, event types list, and payload signing/verification documentation.

   ⚑ flag

   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

Automation core

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

   weight 3 · round to Customer.io
   Loops~partialclaimed5/10

   Evidence confirms Loops supports lifecycle email use cases like onboarding, activation, upgrade, and winback sequences (loops-docs-15) and event-triggered workflows via API (loops-docs-3), but there is no documentation of branching logic, time-based delays, or exit-rule conditions within a visual automation builder. missing for 10: explicit branch/condition support, delay/wait-step configuration, exit-rule mechanics, and independent confirmation of a multi-step workflow builder.

   • [claimed-docs] “Reach users after they close the tab. Set up onboarding, activation, upgrade, and winback emails once, then improve them over time.”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”

   proof ↗⚑ flag

   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

Event triggers

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

   weight 3 · round drawn
   Loops✓fullprobed8/10

   Loops' API includes a documented POST /events/send endpoint explicitly for triggering workflows per contact, alongside contact identification via API key/email, matching the story of firing a custom event to trigger a targeted automation. This is corroborated by an OpenAPI spec and SDK/docs references, though there's no independent hands-on report specifically testing event-triggered automation reliability. missing for 10: independent/hands-on verification of event-to-automation triggering, more detail on per-contact targeting semantics.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “Add Loops to your application in minutes with our SDKs.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [claimed-docs] “Manage contacts, send events, and test transactional email from your terminal”

   proof ↗⚑ flag

   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

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

   The evidence shows Loops can trigger workflows via events and manage contacts via API, but there is no documentation of viewing an individual contact's position within a live automation/workflow or safely pulling/re-entering them without disrupting the flow. Missing for 10: workflow visualization UI, per-contact automation status view, documented pull/re-enter mechanics.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”

   proof ↗⚑ flag

   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

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

   The evidence pack shows API endpoints for creating contacts and sending events, migration guides for moving data INTO Loops from other providers, and CLI/SDK/MCP tooling, but no documented export endpoint, bulk-export feature, or self-serve mechanism to pull contacts, tags, engagement history, or suppression lists OUT of Loops in an open format. Missing for 10: a documented export/download API or dashboard feature, evidence of tags/engagement/suppression data being included in any export, and confirmation of an open file format (CSV/JSON) for full audience export.

   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Move transactional email, contacts, and lists from Brevo to Loops: swap the SDK, map each call, verify your domain, and cut over one email t…”
   • [claimed-docs] “A guide to moving contacts, events, workflows, and transactional email from Customer.io to Loops, with before and after code and a cutover c…”
   • [claimed-docs] “Add marketing, lifecycle, and transactional email to your SaaS from one product. Keep your current transactional provider while you migrate.”

   proof ↗⚑ flag

   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

Import migration

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

   weight 2 · round to Loops
   Loops~partialclaimed5/10

   Loops publishes migration guides for moving contacts, lists, events, and transactional email from platforms like Brevo and Customer.io with 'before and after code and a cutover checklist,' indicating some list-portability support, but these are developer-facing API migration guides rather than a marketer-friendly guided import wizard. No evidence explicitly confirms preservation of tags, custom fields, or unsubscribe state during import. Missing for 10: explicit UI-based guided import flow for marketers, confirmation that tags/custom fields/unsubscribe status are preserved, and independent evidence of successful migrations.

   • [claimed-docs] “Move transactional email, contacts, and lists from Brevo to Loops: swap the SDK, map each call, verify your domain, and cut over one email t…”
   • [claimed-docs] “A guide to moving contacts, events, workflows, and transactional email from Customer.io to Loops, with before and after code and a cutover c…”
   • [claimed-docs] “Add marketing, lifecycle, and transactional email to your SaaS from one product. Keep your current transactional provider while you migrate.”

   proof ↗⚑ flag

   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

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
   Loops~partialprobed5/10

   Loops exposes API/MCP access to contacts (audiences), events (automation triggers), and campaign content creation, and dashboard analytics on which emails drive upgrades/churn exist, but there's no documented endpoint or MCP capability for pulling campaign performance/results data programmatically — the 'report on what's working' analytics piece is not evidenced as API-accessible. missing for 10: an API/MCP endpoint for campaign performance metrics, evidence of reading analytics/results data programmatically rather than just creating content or contacts.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “See which emails lead to upgrades, lower churn, and add revenue. Segments are dynamic and stay current as properties change.”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”

   proof ↗⚑ flag

   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

Api access

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

   weight 3 · round drawn
   Loops—none0/10

   The evidence pack documents contact creation, event sending, campaign drafting, and transactional email APIs, but nowhere shows an endpoint or documentation for retrieving per-contact engagement history (sends, opens, clicks) via the API. This is a fair capability to expect from an email marketing platform, but no evidence confirms it exists.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Run Guardian checks on an email message”

   proof ↗⚑ flag

   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

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

   Evidence shows only a single Bearer-token API key auth model with no mention of scoped, read-only, or per-agent/contractor credentials; nothing indicates permission tiers or restricted-scope keys.

   • [claimed-docs] “add an Authorization header and set the API key as a Bearer token”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Loops
   Loops~partialprobed6/10

   Loops exposes a broad API (contacts, events, transactional email, content/campaign drafting, Guardian checks) plus an OpenAPI spec, CLI, and MCP server, letting AI-native users perform most workflows programmatically (loops-docs-3, loops-docs-4, loops-docs-5, loops-docs-19, loops-probe-3, loops-probe-4). However, campaign creation explicitly notes 'Review and send from the dashboard,' meaning the final send step is UI-only, and analytics/segmentation dashboards have no documented API equivalent. Missing for 10: API parity for sending/publishing campaigns, API access to analytics/segments, independent confirmation of full UI-API parity.

   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “POST /contacts/create Add a contact to your audience”
   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “Run Guardian checks on an email message”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://loops.so/agents/mcp”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Loops—none0/10

   Evidence shows API endpoints for creating/writing contacts and events, migration guides for moving data INTO Loops from other providers, and an OpenAPI spec, but nothing documents a bulk export feature or open-format data portability for users wanting to leave Loops with their data.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Loops—none0/10

   No evidence in the pack mentions data residency, regional storage options, or compliance controls letting users choose where data is stored; Loops' documentation focuses on email API, agents, and pricing, not data residency.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Loops—none0/10

   No evidence in the pack addresses AI-training data usage, opt-outs, or privacy commitments regarding model training; Loops' materials focus on email/marketing API features, not data-privacy policy toward AI training. Missing for 10: any privacy policy statement, opt-out mechanism, or documentation about AI training data usage.

   ⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round to Customer.io
   Loops—none0/10

   No evidence pack items address data retention policies, deletion controls, data export, or GDPR/CCPA-style deletion APIs for contacts/events. The docs focus on sending email, API/SDK usage, and migration, with nothing on how a user or agent controls retention or deletion of stored data. Missing for 10: documented data retention policy, contact/event deletion API or endpoint, data export/erasure workflow, and any privacy compliance certification.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Loops—none0/10

   No evidence in the pack mentions telemetry, analytics opt-out, or usage tracking controls for Loops as a product/tool; the evidence focuses on email API/agent features and pricing/UX community feedback. missing for 10: any documentation of telemetry collection or an opt-out mechanism, privacy settings, or data-collection disclosure.

   ⚑ flag

   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

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

   Evidence shows API-driven draft campaign creation, agent/MCP integrations, and a text-based editor, but there is no mention of a built-in AI feature inside the composer that drafts or refines subject lines/email copy from a brief — the 'AI drafting' capability described is done by external coding agents via API/MCP, not a native in-app AI assistant.

   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “Connect your agent to Loops over MCP. Read and write contacts, events, and content from any client.”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “I scanned your codebase and found every send, template, and webhook. Each one maps to a Loops equivalent, so I swapped the API calls and reb…”
   • [claimed-docs] “How to craft an email using our editor”

   proof ↗⚑ flag

   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

Editor

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

   weight 2 · round to Loops
   Loops~partialcommunity6/10

   Loops documents an email editor, brand-consistency settings (colors/type/spacing applied automatically), dynamic personalization variables, and reusable content built via templates/Content API (loops-docs-17, loops-docs-18, loops-docs-2, loops-docs-9, loops-docs-14). Community evidence confirms the editor is a customizable, text-based system built on extended MJML (loops-comm-7), which supports templating but is not a classic drag-and-drop visual builder, and no evidence addresses cross-client rendering testing or guarantees. missing for 10: explicit cross-email-client rendering validation, confirmation of a fully visual (non-code) editor experience, independent hands-on review of template reuse in practice.

   • [claimed-docs] “Set your colors, type, and spacing in one place. Every email you send picks them up automatically, so your brand stays consistent without an…”
   • [claimed-docs] “How to craft an email using our editor”
   • [claimed-docs] “Send transactional emails with dynamic data variables, right from your backend.”
   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “I scanned your codebase and found every send, template, and webhook. Each one maps to a Loops equivalent, so I swapped the API calls and reb…”
   • [community] “Founder explains editor was rewritten using Lexical (switched from Slate.js) to power their text-based, customizable email editor, built on …”

   proof ↗⚑ flag

   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

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 Loops
   Loops~partialcommunity6/10

   Loops offers a Content API to author campaigns in code (loops-docs-9), transactional emails with dynamic data variables (loops-docs-2), and an editor built on extended MJML (loops-comm-7), which together enable API-managed templates with variable substitution that a developer could store in their own repo. However, there's no first-party feature for native version-control integration, template diffing, or a documented HTML/MJML file-based workflow — the API/editor split still centers editing in the dashboard. Missing for 10: explicit git/version-control integration or CLI-based template push/pull workflow, and independent confirmation that Content API templates round-trip cleanly with raw MJML/HTML files.

   • [claimed-docs] “Author campaigns in code with the Content API and keep editing visually in Loops.”
   • [claimed-docs] “Send transactional emails with dynamic data variables, right from your backend.”
   • [community] “Founder explains editor was rewritten using Lexical (switched from Slate.js) to power their text-based, customizable email editor, built on …”
   • [claimed-docs] “Create draft campaigns, content and all, straight from the API. Review and send from the dashboard.”
   • [claimed-docs] “I scanned your codebase and found every send, template, and webhook. Each one maps to a Loops equivalent, so I swapped the API calls and reb…”

   proof ↗⚑ flag

   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

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

   Loops explicitly documents sending transactional emails with dynamic data via API/SDK alongside marketing/lifecycle sends from the same platform, with an OpenAPI spec and events API to trigger workflows, and this is corroborated by community mention of a 'performant API with versioning for transactional email.' Missing for 10: no hands-on developer report of using the transactional send endpoint specifically (e.g. receipts/magic links) beyond docs framing, and no independent deliverability benchmark for transactional use.

   • [claimed-docs] “Send transactional emails with dynamic data variables, right from your backend.”
   • [claimed-docs] “POST /events/send Send an event to trigger workflows”
   • [claimed-docs] “Add marketing, lifecycle, and transactional email to your SaaS from one product. Keep your current transactional provider while you migrate.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://loops.so/llms.txt # Loops > Loops is an email platform for software companies. Send transactional and m…”
   • [probe] “PROBE openapi: HTTP 200 at https://loops.so/openapi.json — contains "openapi" key”
   • [community] “Founder describes Loops' approach: simplified pricing (no tables, one metric), performant API with versioning for transactional email, text-…”

   proof ↗⚑ flag

   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

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

   Docs confirm Loops offers distinct transactional email sending (its own API/backend calls) separate from marketing/lifecycle campaigns, and migration guides note transactional vs marketing distinctions, but there is no explicit documentation of separate suppression-list logic or dedicated sending reputation ensuring transactional mail still reaches unsubscribed contacts. Missing for 10: explicit suppression-rule separation, reputation isolation, and confirmation that unsubscribe status doesn't block transactional sends.

   • [claimed-docs] “Send transactional emails with dynamic data variables, right from your backend.”
   • [claimed-docs] “Add marketing, lifecycle, and transactional email to your SaaS from one product. Keep your current transactional provider while you migrate.”
   • [claimed-docs] “Move transactional email, contacts, and lists from Brevo to Loops: swap the SDK, map each call, verify your domain, and cut over one email t…”
   • [claimed-docs] “A guide to moving contacts, events, workflows, and transactional email from Customer.io to Loops, with before and after code and a cutover c…”

   proof ↗⚑ flag

   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