Loops vs Kit

Agent access

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

   weight 2 · round drawn
   Loops✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Kit✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Loops
   Loops~partialprobed6/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed3/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Loops✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Kit✓fullprobed8/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Loops
   Loops✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Loops
   Loops✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Kit✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Loops
   Loops✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Agentic features

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

   weight 2 · round to Kit
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Loops
   Loops✓fullclaimed6/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Kit
   Loops~partialprobed6/10

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

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

   proof ↗⚑ flag

   Kit✓fullprobed7/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Loops
   Loops~partialprobed4/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Loops
   Loops✓fullprobed9/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

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

   weight 2 · round to Loops
   Loops~partialprobed3/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Api metrics

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Attribution

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

   weight 2 · round to Loops
   Loops~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Reporting core

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Agent segments

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Api contacts

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

   weight 3 · round to Loops
   Loops~partialprobed4/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Api segments

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

   weight 3 · round to Loops
   Loops~partialprobed4/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Segment core

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

   weight 3 · round to Loops
   Loops~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Kit~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Kit
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Loops
   Loops~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Kit~partialclaimed4/10

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

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Loops
   Loops~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Kit~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

Agent campaigns

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

   weight 3 · round drawn
   Loops~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Kit~partialclaimed6/10

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

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

   proof ↗⚑ flag

Api campaigns

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

   weight 3 · round to Kit
   Loops~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Kit✓fullprobed7/10

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

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

   proof ↗⚑ flag

Campaign core

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

   weight 3 · round to Kit
   Loops✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Kit✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Experiments

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

   weight 2 · round to Kit
   Loops—none0/10

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

   ⚑ flag

   Kit~partialclaimed4/10

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

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

   proof ↗⚑ flag

Deliverability signals

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Domain auth

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Suppression

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

First party integrations

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

   weight 2 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Webhooks

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

   weight 3 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

Automation core

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

   weight 3 · round to Loops
   Loops~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Kit~partialclaimed4/10

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

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

Event triggers

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

   weight 3 · round to Loops
   Loops✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Flow operations

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   • [claimed-docs] “Unlimited Visual Automations”

   proof ↗⚑ flag

Export

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Import migration

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

   weight 2 · round to Loops
   Loops~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Loops
   Loops~partialprobed5/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed4/10

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

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

   proof ↗⚑ flag

Api access

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

   weight 3 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Scoped access

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

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

   weight 2 · round to Loops
   Loops~partialprobed6/10

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

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

   proof ↗⚑ flag

   Kit~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

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

   weight 2 · round drawn
   Loops—none0/10

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

   ⚑ flag

   Kit—none0/10

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

   ⚑ flag

Ai content

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

   weight 2 · round drawn
   Loops—none0/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Editor

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

   weight 2 · round to Loops
   Loops~partialcommunity6/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Templates as code

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

   weight 2 · round to Loops
   Loops~partialcommunity6/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag

Transactional api

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

   weight 3 · round to Loops
   Loops✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

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

   proof ↗⚑ flag

Transactional hygiene

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

   weight 2 · round to Loops
   Loops~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Kit—none0/10

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

   ⚑ flag