Customer.io vs Bento

Agent access

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

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

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

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

   proof ↗⚑ flag

   Bento✓fullprobed9/10

   Bento has a live, confirmed llms.txt (HTTP 200) and a docs.md agent-friendly documentation file, directly enabling an AI agent to be pointed at agent-oriented docs, plus a documented MCP server for deeper agent integration. Missing for 10: independent third-party confirmation that agents actually consume these files effectively in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://bentonow.com/llms.txt # Bento (bentonow.com) — An Email Marketing and Automation Platform ## Overview B…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bentonow.com/docs.md # Bento Documentation Complete documentation for Bento email marketing platform. AP…”
   • [claimed-docs] “Dedicated IP address options for high-volume senders”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Bento~partialprobed3/10

   Bento exposes REST-style APIs (events, subscribers) that could be scripted, and one marketing line mentions scripting a weekly job, but there is no documented CLI, headless mode, or CI/automation guide, and no OpenAPI spec was found (404s). missing for 10: explicit CI/headless documentation, CLI tool, and API spec/reference for automated pipelines.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Customer.io—none0/10

   The story asks whether Customer.io lets a user plug external MCP servers into it so its AI can use their tools (Customer.io acting as an MCP client). The evidence only shows the reverse: Customer.io ships its own official MCP server (customer-io-probe-3, customer-io-docs-9/10/16) for other agents to connect to and call its tools, which is a different capability. No evidence shows Customer.io's AI assistant/CLI/Slack integration can consume arbitrary external MCP servers.

   ⚑ flag

   Bento—none0/10

   Evidence only shows Bento exposes its own MCP server so external AI assistants can call Bento's tools (bento-docs-5, bento-probe-4) — the reverse of what this story asks. There is no evidence Bento itself can act as an MCP client and plug in external MCP servers to use their tools.

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Customer.io✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Bento✓fullprobed8/10

   Bento documents an official MCP server that gives AI assistants direct access to the account (subscriber lookup, broadcast creation, event tracking) via natural conversation, confirmed by both docs and a probe hit on the integration page. Missing for 10: independent/hands-on corroboration beyond first-party docs and more detail on setup/auth specifics.

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Customer.io
   Customer.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of an official CLI tool for Bento; documentation focuses on APIs, MCP server, and email marketing features but never mentions a command-line interface. Missing for 10: any mention of a CLI product, install instructions, or command reference.

   ⚑ flag

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

   weight 3 · round to Customer.io
   Customer.io✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Bento✓fullprobed7/10

   Bento documents multiple REST-style APIs (events, subscribers, transactional email) and provides machine-readable docs (llms.txt, docs.md) explicitly aimed at AI agents, plus an MCP server for natural-language control of the account. This satisfies the 'documented public API' story, though no formal OpenAPI/Swagger spec was found (404s on all candidate paths). Missing for 10: a discoverable OpenAPI/Swagger schema and independent third-party confirmation of programmatic API usage.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://bentonow.com/llms.txt # Bento (bentonow.com) — An Email Marketing and Automation Platform ## Overview B…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bentonow.com/docs.md # Bento Documentation Complete documentation for Bento email marketing platform. AP…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”

   proof ↗⚑ flag

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

   weight 2 · round to Customer.io
   Customer.io~partialprobed5/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   Evidence shows an MCP server and general API docs but no mention of scoped or least-privilege API keys/credentials, token permission levels, or role-based access control for agents. No documentation of credential scoping mechanism exists in the pack.

   ⚑ flag

8. ai-native userBuild against official SDKs

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

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

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

   proof ↗⚑ flag

   Bento~partialprobed3/10

   Docs.md teaser mentions 'API guides, SDK references' but the evidence pack never names specific official SDKs, languages, or repos, only a generic mention plus an MCP server for AI assistants. Missing for 10: explicit list of official SDKs (e.g., language libraries), links to SDK documentation/repos, code samples, and independent developer corroboration of SDK usage.

   • [probe] “PROBE docs-md: HTTP 200 at https://bentonow.com/docs.md # Bento Documentation Complete documentation for Bento email marketing platform. AP…”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   Evidence covers Bento's Events API (tracking inbound events), subscriber management, and an MCP server, but there is no mention of outbound webhook subscriptions that would let an AI-native user subscribe to Bento events. Missing for 10: any documentation of a webhooks feature, webhook endpoint configuration, or event subscription mechanism.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Customer.io
   Customer.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Bento~partialprobed4/10

   Bento advertises AI that can 'build' flows/segments from plain text and an MCP server letting an AI assistant query subscriber/event data conversationally, which implies some AI-data interaction, but there is no explicit documentation of AI-generated insights, analytics summaries, or proactive suggestions derived from the user's data. Missing for 10: dedicated AI insights/reporting feature, evidence of proactive suggestions, and independent confirmation of this capability in use.

   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Customer.io
   Customer.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Bento✓fullclaimed7/10

   Bento's docs describe building automation flows triggered by user behavior, events, and tags, with the events API able to trigger automations, and even AI-assisted flow building — this directly supports autonomous background automations for an AI-native marketing use case. Missing for 10: independent/hands-on corroboration of automations running unattended, and more detail on monitoring/error-handling of long-running flows.

   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”

   proof ↗⚑ flag

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

   weight 3 · round to Customer.io
   Customer.io~partialprobed6/10

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

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

   proof ↗⚑ flag

   Bento~partialclaimed3/10

   Bento markets an in-product AI ('Describe what you want in plain text and let Bento's powerful AI build it for you') suggesting a built-in assistant for flow creation, but there's no detailed documentation of scope, task types, or interaction model beyond this marketing line. The MCP server evidence is about external AI assistants accessing Bento, not a built-in assistant, so it doesn't count here. Missing for 10: detailed docs/UI showing the built-in assistant's task range, hands-on usage examples, and independent corroboration of its capabilities.

   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”

   proof ↗⚑ flag

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

   weight 2 · round to Customer.io
   Customer.io✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Bento✓fullprobed7/10

   Bento ships an official MCP server documented to let an AI assistant look up subscribers, create broadcasts, track events, etc. 'through natural conversation,' and separately advertises a plain-text AI builder for flows, directly supporting natural-language operation. Missing for 10: independent/hands-on corroboration of the MCP server's reliability and broader coverage of natural-language commands beyond the examples given.

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Customer.io
   Customer.io~partialprobed5/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   Evidence shows only static docs (events/subscribers/transactional-email pages) and an llms.txt/docs.md text dump; explicit probes for OpenAPI/Swagger specs returned 404s, and no mention of an interactive, runnable API console or sandbox exists anywhere in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://bentonow.com/llms.txt # Bento (bentonow.com) — An Email Marketing and Automation Platform ## Overview B…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bentonow.com/docs.md # Bento Documentation Complete documentation for Bento email marketing platform. AP…”

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Bento—none0/10

   A direct probe for OpenAPI/Swagger specs at all standard paths returned 404, and no evidence pack item shows a downloadable machine-readable API spec; only human-readable docs and an MCP server are documented.

   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of a sandbox/test environment or staging mode separate from production data; docs cover subscribers, transactional email, MCP integration, and pricing but nothing about sandbox testing.

   ⚑ flag

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

   weight 2 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of API versioning scheme or documented deprecation policy; OpenAPI spec probe returned 404s and no docs mention version numbers or deprecation timelines.

   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

Api metrics

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

   weight 2 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   Evidence shows Bento has an Events API and Subscribers API, and mentions revenue attribution to email/flows as a feature, but no documentation describes an API endpoint for pulling campaign or flow performance metrics (opens, clicks, conversions) into an external warehouse or dashboard. An OpenAPI spec search also returned 404s, giving no confirmation of such an endpoint's existence or schema. Missing for 10: documented performance/metrics API endpoint, example payload for campaign/flow stats, evidence of warehouse/dashboard export support.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Tie sales and recurring revenue back to the email or flow that came before.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

Attribution

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

   weight 2 · round to Bento
   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

   Bento~partialclaimed6/10

   Bento's marketing explicitly claims revenue attribution to specific emails/flows (bento-docs-6) and supports event tracking (bento-docs-1) and flow building from events/behavior (bento-docs-9), which are prerequisites for such attribution. However, there is no documentation detail on how attribution reporting/dashboards actually work, no independent or hands-on confirmation of accuracy, and no mention of signup attribution specifically. missing for 10: detailed attribution reporting docs/UI evidence, signup-specific attribution mechanics, independent verification of revenue attribution accuracy.

   • [claimed-docs] “Tie sales and recurring revenue back to the email or flow that came before.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   proof ↗⚑ flag

Reporting core

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

   weight 3 · round to Bento
   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

   Bento~partialclaimed4/10

   Evidence shows Bento tracks events, ties revenue to campaigns/flows, and lets you filter subscribers by tags/segments/dates, implying some analytics capability, but there is no documentation of a dedicated per-campaign or per-automation-step dashboard showing opens, clicks, unsubscribes, and conversions over time. missing for 10: explicit reporting/analytics documentation showing opens/clicks/unsubscribes/conversions broken out per campaign and per automation step over time, and any independent or hands-on confirmation of such reporting UI.

   • [claimed-docs] “Tie sales and recurring revenue back to the email or flow that came before.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”

   proof ↗⚑ flag

Agent segments

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

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

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

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

   proof ↗⚑ flag

   Bento—none0/10

   Evidence shows Bento's MCP server can look up subscribers, create broadcasts, and track events (bento-docs-5), and a generic 'describe what you want, AI will build it' feature (bento-docs-10), but no documentation ties this to translating a plain-language description into an actual audience segment via the API/MCP surface — segment filtering is described only as manual tag/date-based filters (bento-docs-8).

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”

   proof ↗⚑ flag

Api contacts

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

   weight 3 · round to Customer.io
   Customer.io~partialprobed6/10

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

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

   proof ↗⚑ flag

   Bento~partialprobed5/10

   Docs confirm a Subscribers API supporting batch create/update (1-1000 per request) and an Events API for tracking activity and updating profile fields, plus filtering by tags/segment/date, which implies some custom-field handling. However there is no explicit documentation of a suppression/unsubscribe endpoint, no explicit mention of arbitrary custom properties support, and no OpenAPI spec or rate-limit/production-scale guarantees (openapi probe returned 404s). missing for 10: explicit suppression/unsubscribe API endpoint, explicit custom-properties schema support, documented rate limits or production-scale guarantees.

   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   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 Bento
   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

   Bento~partialprobed6/10

   Docs confirm subscriber API supports adding/updating tags and profile fields (bento-docs-1, bento-docs-4) and filtering/reading back subscribers by tag, segment, or date range (bento-docs-8), showing read/write access to tag membership. However, there's no explicit evidence of an API endpoint to programmatically create or update segment/list definitions themselves (segments appear to be built via filters/UI), and no OpenAPI spec was found to confirm full CRUD coverage (bento-probe-3). Missing for 10: explicit segment-creation/update API endpoint, documented list CRUD operations, and independent confirmation of read-back accuracy.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

Segment core

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

   weight 3 · round drawn
   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

   Bento✓fullclaimed7/10

   Docs show segmentation via tags, saved segments, and date-range filters on subscriber fields (bento-docs-8), combined with behavioral event tracking (bento-docs-1) and flows built from behavior/events/tags (bento-docs-9), which together enable dynamic, attribute+behavior-based audience segments. Missing for 10: explicit documentation stating segments automatically re-evaluate/update in real time as data changes, and independent/hands-on corroboration of live segment behavior.

   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   proof ↗⚑ flag

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

   weight 2 · round to Bento
   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

   Bento~partialclaimed6/10

   Bento's API explicitly supports batch operations on subscribers (1–1000 per request), bulk import, and filtering/segmenting for bulk targeting, and the MCP server exposes some of this to AI assistants. However, evidence doesn't show bulk operations beyond subscriber records (e.g., bulk broadcast sends, bulk event batch limits) or independent confirmation of scale/performance. Missing for 10: evidence of bulk operations across other object types (broadcasts, tags, flows), documented rate/size limits beyond subscribers, and independent/hands-on verification.

   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”

   proof ↗⚑ flag

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

   weight 3 · round to Customer.io
   Customer.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Bento✓fullclaimed7/10

   Bento supports building automation flows triggered by behavior, events, and tags, with branch validation before running ('Build flows from behavior, events, and tags. Check every branch before it runs.'), plus an Events API to track activity and trigger automations. Missing for 10: independent hands-on verification of rule complexity/reliability, and detailed documentation of conditional logic depth beyond marketing copy.

   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

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

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

   proof ↗⚑ flag

   Bento~partialclaimed3/10

   Bento supports event/tag-triggered automation flows and scripting API jobs (e.g. 'script the job you run every week'), which implies some recurring automation capability, but there is no explicit documentation of a scheduler, cron-like recurring job configuration, or AI-driven scheduling of workflows. Missing for 10: explicit recurring/scheduled job feature, AI-native interface for setting schedules, and independent confirmation of time-based (not just event-based) automation triggers.

   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of version history, review/diff, or rollback capability for Bento automations/flows; docs mention building flows and checking branches before running, but nothing about versioning or reverting automations.

   ⚑ 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 Customer.io
   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

   Bento~partialprobed4/10

   The MCP server can create broadcasts via natural language, implying a draft/queued campaign can be produced by an agent, but there is no documented approval/hold-for-human-review workflow or explicit 'scheduled pending approval' state before send. missing for 10: explicit approval-gating or human-review-before-send workflow, documentation of a queued/pending state distinct from immediate send, evidence of segment-targeted broadcast drafting via the agent.

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   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 Customer.io
   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

   Bento—none0/10

   Evidence documents APIs for events, subscribers, and transactional email, plus an MCP server that can 'create broadcasts' via AI assistant — but there is no documented public REST API endpoint for creating or scheduling campaigns/broadcasts, and OpenAPI spec probes returned 404s. Missing for 10: a documented broadcast/campaign creation and scheduling endpoint in the public API reference.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, …”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

Campaign core

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

   weight 3 · round to Customer.io
   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

   Bento~partialclaimed5/10

   Evidence confirms subscriber segmentation (tags/segments/date filters) and broadcast creation (including via MCP), which are core pieces of the campaign-sending loop, but there is no direct documentation of the actual campaign composition UI or a 'schedule send' feature. Missing for 10: explicit docs/screenshots of composing an email campaign, choosing send-now vs schedule-for-later, and confirmation of the full end-to-end send flow.

   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   proof ↗⚑ flag

Experiments

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

   weight 2 · round drawn
   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

   Bento—none0/10

   No evidence in the pack mentions A/B testing, subject line testing, or automatic winner selection based on engagement; the docs cover events, subscribers, transactional email, flows, and MCP integration but nothing about split testing campaigns.

   ⚑ flag

Deliverability signals

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

   weight 2 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   The evidence pack shows subscriber/event tracking, dedicated IPs, and general email automation features, but there is no mention of per-send bounce/complaint/blocklist reporting or deliverability health guidance. missing for 10: bounce/complaint/blocklist reporting per send, deliverability health dashboard, actionable degradation alerts/guidance.

   • [claimed-docs] “Dedicated IP address options for high-volume senders”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”

   proof ↗⚑ flag

Domain auth

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

   weight 3 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   The evidence pack contains no mention of SPF/DKIM/DMARC domain authentication, guided DNS setup, or verification flows — only unrelated features like dedicated IPs, transactional email, and subscriber management. Domain authentication is a standard, fair-to-expect capability for an email marketing platform, so its absence is 'none' rather than 'na'. missing for 10: any documentation of SPF/DKIM/DMARC setup, DNS record guidance, or domain verification UI.

   • [claimed-docs] “Dedicated IP address options for high-volume senders”

   proof ↗⚑ flag

Suppression

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

   weight 3 · round to Customer.io
   Customer.io~partialclaimed3/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence pack item documents automatic suppression of unsubscribes, bounces, or spam complaints, nor honoring suppression across transactional and broadcast/flow sends; docs mention filtering by unsubscribe time and dedicated IPs but nothing about compliance suppression logic.

   ⚑ flag

First party integrations

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

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

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

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

   proof ↗⚑ flag

   Bento—none0/10

   The evidence pack shows generic Events/Subscribers APIs, an MCP server, and marketing copy, but no mention of maintained first-party integrations with Stripe, Shopify, Segment, or a product database — nothing names a specific connector or integrations marketplace.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [probe] “PROBE docs-md: HTTP 200 at https://bentonow.com/docs.md # Bento Documentation Complete documentation for Bento email marketing platform. AP…”

   proof ↗⚑ flag

Webhooks

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

   weight 3 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence pack item documents an outbound webhooks feature for delivery/engagement events (sends, opens, clicks, bounces, unsubscribes) with signed payloads; the closest items reference an inbound Events API for tracking user activity, not outbound webhook subscriptions. OpenAPI/spec probes turned up nothing, and no webhook-specific docs appear anywhere in the pack.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

Automation core

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

   weight 3 · round drawn
   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

   Bento~partialclaimed6/10

   Docs confirm flow-building based on behavior, events, and tags with branch checking (bento-docs-9) and event/activity tracking to trigger automations (bento-docs-1), supporting core lifecycle automation building blocks, but there is no explicit documentation of delays, timed waits, or exit rules, nor named templates like welcome/onboarding/winback series. missing for 10: explicit delay/wait-step documentation, explicit exit-rule/goal documentation, named use-case templates (welcome, onboarding, winback), independent hands-on corroboration.

   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Tie sales and recurring revenue back to the email or flow that came before.”

   proof ↗⚑ flag

Event triggers

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

   weight 3 · round to Customer.io
   Customer.io✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Bento✓fullclaimed7/10

   Docs confirm an Events API that tracks user activity per subscriber and can trigger automations, and flows explicitly built from 'behavior, events, and tags' with per-branch checks, matching the story of firing a custom event to trigger an automation for a specific person. missing for 10: no hands-on/independent confirmation of exact event-to-person targeting behavior, and no code sample showing the custom event payload triggering a single-subscriber automation.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”

   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
   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

   Bento—none0/10

   Evidence only shows generic flow-building and event/segment filtering (bento-docs-9, bento-docs-8) but nothing about viewing an individual subscriber's current position inside a running automation or safely pulling/re-entering them without breaking the flow.

   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”

   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 to Bento
   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

   Bento~partialclaimed3/10

   Bento's docs mention a Subscribers API that can filter by tags, segments, and dates and can be scripted to run exports (bento-docs-2, bento-docs-4, bento-docs-8), implying some self-serve data extraction is possible via API, but there is no explicit documentation of a full audience export covering suppression list, full engagement history, or a one-click open-format (CSV/JSON) export tool. Missing for 10: documented bulk export/download feature, explicit suppression list export, engagement history export, and confirmation of an open standard export format.

   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”

   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 Bento
   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

   Bento~partialcommunity5/10

   Bento documents subscriber import (bulk import, 1-1000 per request), filtering by tags/segments and unsubscribe timestamps, and explicitly lists 'Migration help when you switch' on its pricing page plus testimonials of users moving from Mailchimp/Hubspot. However there is no dedicated guided-migration wizard or documentation detailing how custom fields and unsubscribe state are specifically preserved during a platform switch. Missing for 10: a documented step-by-step migration/import wizard, explicit confirmation that unsubscribe status and custom fields are mapped/preserved on import, and independent evidence of successful full-data migrations.

   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Migration help when you switch”
   • [claimed-docs] “Moved to Bento from Hubspot and never looked back!”
   • [community] “I started out on MailChimp, but recently switched to Bento (bentonow.com). I really like it.”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   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

   Bento~partialprobed6/10

   Bento ships an official MCP server plus REST APIs (events, subscribers) that let an AI assistant look up subscribers, create broadcasts, and track events 'through natural conversation,' which supports programmatic access to audiences and automations triggers. However, there is no direct evidence of an API/MCP capability for pulling campaign performance metrics or automation run reports (the closest is generic revenue-attribution copy), so full 'report on what's working' analytics access isn't demonstrated. Missing for 10: explicit API/MCP endpoints for campaign/broadcast analytics or automation performance reporting, and independent confirmation of MCP reliability for this reporting use case.

   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Tie sales and recurring revenue back to the email or flow that came before.”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

Api access

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

   weight 3 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   Evidence covers Bento's Events API (tracking activity, updating fields, triggering automations) and Subscribers API filters (tags, segments, last-event/date ranges), but nothing documents a way to retrieve per-contact history of what was sent, opened, and clicked via the API. No endpoint or field for message-level engagement history is described.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”

   proof ↗⚑ flag

Scoped access

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

   weight 2 · round drawn
   Customer.io—none0/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of scoped or read-only API key/credential management in Bento's docs; API references only cover events, subscribers, and transactional email without mention of permission levels or credential scoping for third parties like contractors or agents.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”

   proof ↗⚑ flag

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

   weight 2 · round to Bento
   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

   Bento~partialprobed5/10

   Bento's docs show a broad API/events/subscribers/transactional-email surface (bento-docs-1,2,3,8) and an MCP server exposing subscriber lookup, broadcast creation, and event tracking via natural language (bento-docs-5, bento-probe-4), suggesting substantial API parity with the UI. However, no public OpenAPI/swagger spec was found (bento-probe-3), and UI-only features like AI-driven flow building from plain text (bento-docs-10) and flow branch testing (bento-docs-9) aren't shown as API-accessible. Missing for 10: a full OpenAPI reference, explicit API endpoints for flow/automation creation and testing, and confirmation that all UI actions (flows, broadcasts, deliverability settings) have API equivalents.

   • [claimed-docs] “Track user activity, update profile fields, and trigger automations.”
   • [claimed-docs] “Request supports 1 to 1000 subscribers per post.”
   • [claimed-docs] “Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, …”
   • [claimed-docs] “The Bento MCP server gives your AI assistant direct access to your Bento account. It can look up subscribers, create broadcasts, track event…”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Build flows from behavior, events, and tags. Check every branch before it runs.”
   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bentonow.com/openapi.json, https://bentonow.com/swagger.json, https://bentonow.com/api/opena…”
   • [probe] “official MCP server documented at https://bentonow.com/docs/integrations/mcp”

   proof ↗⚑ flag

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

   weight 3 · round to Bento
   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

   Bento~partialclaimed3/10

   Bento offers a subscribers API for querying/importing records and mentions 'migration help when you switch,' implying some data portability, but there is no explicit documentation of a full data export feature or open-format (CSV/JSON) bulk export for all account data. missing for 10: explicit bulk export endpoint/tool, documented open export formats, and independent confirmation that a full account export is possible.

   • [claimed-docs] “Import subscribers, find a record, or script the job you run every week.”
   • [claimed-docs] “Filter by tags, a segment, or by date ranges on creation, update, last event, and unsubscribe times.”
   • [claimed-docs] “Migration help when you switch”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location options for Bento; the only infrastructure-related item is a dedicated IP address feature for sending, unrelated to data residency. missing for 10: any mention of regional data hosting, residency guarantees, or data storage location controls.

   • [claimed-docs] “Dedicated IP address options for high-volume senders”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   No evidence in the pack addresses AI-training data usage, opt-out controls, or privacy commitments regarding model training; Bento's evidence focuses on email marketing features, pricing, and MCP integration.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Customer.io
   Customer.io~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence pack items describe data retention policies, subscriber deletion/export controls, or privacy/GDPR compliance tooling; the docs focus on subscriber import/filtering/automation, not on how AI-native users can control or delete stored data. Missing for 10: documented data deletion/export APIs, retention policy settings, GDPR/CCPA compliance statements.

   ⚑ flag

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

   weight 2 · round drawn
   Customer.io—none0/10

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

   ⚑ flag

   Bento—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out for Bento itself (as opposed to its email/marketing tracking features for end customers); this is a fair privacy-posture question for any AI-native tool but no documentation or community evidence confirms such a control exists.

   ⚑ flag

Ai content

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

   weight 2 · round to Customer.io
   Customer.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   The only AI-related claim (bento-docs-10) is generic ('let Bento's powerful AI build it for you') and appears tied to flow/segment building, not to drafting or refining subject lines and email copy inside a composer. No evidence describes an AI copywriting assistant for email content.

   • [claimed-docs] “Describe what you want in plain text and let Bento's powerful AI build it for you.”

   proof ↗⚑ flag

Editor

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

   weight 2 · round to Customer.io
   Customer.io~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   The evidence pack covers transactional email, subscriber/segment management, flows/automations, and an MCP integration, but contains no mention of a visual email editor, reusable templates, personalization tokens, or cross-client rendering testing — all core to this story for an email marketing platform.

   ⚑ flag

Templates as code

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

   weight 2 · round to Customer.io
   Customer.io~partialcommunity3/10

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

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

   proof ↗⚑ flag

   Bento—none0/10

   No evidence of managing email templates as code (HTML/MJML files, template versioning, or API-managed templates with variable substitution under version control); evidence only covers subscriber management, events, transactional email use-cases, and MCP integration.

   ⚑ 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 Bento
   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

   Bento✓fullclaimed8/10

   Bento's docs explicitly describe a dedicated transactional email feature for one-to-one messages like password resets, receipts, login codes, and order confirmations, sent via the same platform used for marketing, and note dedicated IP options for high-volume senders. Missing for 10: explicit confirmation this uses the same unified API endpoint as marketing sends, and independent/hands-on corroboration of transactional delivery in practice.

   • [claimed-docs] “Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, …”
   • [claimed-docs] “Dedicated IP address options for high-volume senders”

   proof ↗⚑ flag

Transactional hygiene

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

   weight 2 · round drawn
   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

   Bento~partialclaimed5/10

   Bento explicitly documents transactional email as a distinct category (password resets, receipts, order confirmations) separate from marketing sends, and mentions dedicated IP options for high-volume senders. However, there is no explicit documentation confirming that suppression/unsubscribe rules are bypassed for transactional messages, that transactional templates are managed separately from marketing templates, or that transactional sending reputation/IP is isolated from marketing reputation. Missing for 10: explicit suppression-list bypass behavior for transactional sends, dedicated transactional template system, and documented separate sending reputation/domain infrastructure.

   • [claimed-docs] “Transactional email is for messages a person needs because of an action, request, or account state: password resets, receipts, login codes, …”
   • [claimed-docs] “Dedicated IP address options for high-volume senders”

   proof ↗⚑ flag