The Integration Fantasy

The landing page has a section called "Integrations" with a grid of 47 logos. Slack, Notion, Google Sheets, Salesforce, HubSpot, Jira, Linear, Airtable, Zapier, Make, GitHub — the whole constellation. You look at that grid and your brain does something automatic: it imagines your workflow, connected, data flowing between all the tools you already use, orchestrated by this new thing that apparently talks to everything. That image is worth more than any feature list. It's the promise that you won't have to change how you work. You'll just add this tool and it'll slot right in.

I tested integrations across a dozen AI tools over the past year. The grid of logos on the landing page and the reality of what those integrations actually do are so far apart that calling them "integrations" in both cases feels like a category error. There's a spectrum from "native, bidirectional, maintained data connection" to "technically, someone once got this to work through three intermediary services and a custom webhook," and most landing page integrations live much closer to the second end than the first.

The Pattern

"It connects to everything" is the most consistently misleading claim in the AI tools industry, and it persists because the word "integration" is doing an enormous amount of unearned work. There is no standard definition. When a tool says it "integrates with Slack," that could mean any of the following, in descending order of usefulness:

Native integration — built by the tool's own team, bidirectional, maintained as both tools update, handles errors gracefully, documented. This is what you imagine when you see the logo.

Official API connection — the tool uses Slack's API to send or receive data. Usually one direction. Works reliably but may lack features. Often requires configuration that the landing page doesn't mention.

Third-party connector — Zapier, Make, or n8n has a community-built trigger or action for this tool, and that connector sends data to Slack. Two hops instead of one. Adds latency, adds a failure point, adds a subscription cost. Can break when either tool updates its API.

"Technically possible" — the tool has a webhook or API endpoint, Slack has a webhook or API endpoint, and theoretically you could connect them. With custom code. And ongoing maintenance. The logo is on the landing page because the connection is technically achievable, not because anyone has packaged it.

Coming soon — the logo is there. The integration is not. There might be a waitlist. According to the landing page, this has been "coming soon" for seven months [VERIFY — common pattern, no specific tool cited].

The landing page treats all of these the same. Same logo size, same grid position, same implied capability. The user treats them the same too, because the landing page gives them no reason not to. This is not accidental. It's a design choice that benefits the tool maker and costs the user — but only after they've signed up.

The Zapier Distinction

This deserves its own section because it's the source of more confusion than any other integration claim. When a tool says "connects to 5,000+ apps via Zapier," that's technically true and practically misleading. Zapier connects to 5,000+ apps. The tool connects to Zapier. Those are different statements with different implications.

A Zapier integration means your data takes an extra hop. Tool A fires a trigger, Zapier catches it, Zapier fires an action in Tool B. This adds latency — sometimes seconds, sometimes minutes depending on your Zapier plan. Free and lower-tier Zapier plans poll for triggers every 15 minutes, not in real time. That means "instant integration" is actually "up to 15 minutes of latency" unless you're paying for Zapier's higher tiers.

It also means your integration has three failure points instead of one. If Tool A's trigger breaks, the integration breaks. If Zapier has an outage (and per Zapier's status page history, they have brief outages regularly enough that anyone running critical workflows through them has stories), the integration breaks. If Tool B's API changes, the integration breaks. Users on r/zapier report debugging failures where the root cause is ambiguous — was it the source tool, Zapier, or the destination tool? You often can't tell without checking all three.

Make (formerly Integromat) and n8n have the same fundamental issue, though their execution models differ. Make runs scenarios on schedules or webhooks with more granular error handling. n8n gives you self-hosted control but requires you to maintain the infrastructure. None of them are the same as a native integration, and a landing page that lists "Zapier" as an integration logo alongside "Slack" and "Google Sheets" is conflating a platform with a connection.

What Integration Should Mean

A real integration — the kind worth putting on a landing page without qualifiers — has specific properties. It's bidirectional: data flows from Tool A to Tool B and back, or at minimum, both tools stay in sync. It handles errors: when something fails, you get a useful error message, not silent data loss. It's maintained: when either tool updates its API, the integration is updated too, ideally before or shortly after the change. And it's documented: there's a page somewhere that tells you exactly what data syncs, in which direction, with what latency, and what the known limitations are.

By that standard, most tools integrate well with two or three things. Maybe five, for the larger platforms. Notion's integration with Slack is genuinely good — you can create database items from Slack messages, get notifications in Slack when database properties change, and the connection is maintained by Notion's team. According to Notion's API documentation, they also have solid integrations with a handful of other tools. But Notion's landing page lists dozens of integrations, and most of them are through Zapier or community-built connections that Notion doesn't maintain.

Linear has a similar pattern. Their GitHub integration is excellent — bidirectional issue linking, automatic status updates, branch tracking. Their Slack integration is good. Beyond that, you're in Zapier territory. The core integrations that the team actually maintains are a small fraction of the logos on the page. This isn't unique to Linear or Notion. It's the industry standard, and that's the problem.

The Real Cost

The integration fantasy doesn't just waste time during evaluation. It creates ongoing maintenance burden that doesn't show up in the pricing comparison. When you rely on a Zapier-mediated integration for something important — say, syncing customer data between your CRM and your AI analysis tool — you're now maintaining that Zap. You're checking that it ran. You're debugging it when it fails. You're paying Zapier's monthly fee on top of both tools' fees. You're updating it when either tool changes its API. That's operational overhead, and it's invisible during the demo.

I tested an AI writing tool that claimed Wordpress integration. The landing page showed a "Publish to Wordpress" button. In practice, what happens is: the tool generates HTML, you copy it, you paste it into Wordpress's HTML editor, and you manually fix the formatting issues that result from the tool's HTML not matching your theme's CSS expectations. That's not an integration. That's a clipboard. But "Wordpress integration" on the landing page sounds like one-click publishing, and there's nothing technically false about calling it an integration if you define integration loosely enough.

The pattern repeats across the industry. "Google Sheets integration" might mean "exports a CSV you can open in Sheets." "CRM integration" might mean "we have a Salesforce connector that syncs contact names but not custom fields." "API available" might mean "we have REST endpoints but no SDK, no rate limit documentation, and the API changes without notice." Each of these is a version of the truth that happens to be useless for the use case you imagined when you saw the logo.

The Fix

Before you buy a tool because of its integrations, test the specific integration you need. Not the concept of it. The actual connection, with your actual accounts, pushing your actual data. This takes 15 minutes and will save you from discovering six weeks later that the "Notion integration" is a one-way export that doesn't sync updates.

Here's the protocol. First, identify the one or two integrations that matter for your workflow. Not "it would be nice if it connected to Airtable." The connections without which the tool is useless to you. Second, find the documentation for those specific integrations. If there's no documentation beyond a logo on the landing page, that tells you something. Third, set it up during your trial period. Connect both accounts, push test data through, verify it arrives correctly on the other side. Then change the data on the other side and see if it syncs back. Fourth, break it on purpose — send malformed data, disconnect one side, see what happens. Does it retry? Does it notify you? Does it silently drop the data?

If the integration you need is through Zapier or Make, factor that into your cost calculation and your reliability expectations. A Zapier-mediated workflow is a fine solution for non-critical, low-frequency tasks. It is not a fine solution for anything that needs to work every time, in real time, without babysitting. Know which category your use case falls into before you commit.

The honest version of every tool's integration page would have three tiers: "we built and maintain this," "this works through Zapier/Make," and "this is technically possible and we wish you luck." Until that's the standard, the evaluation burden falls on you.

This article is part of the Demo vs. Delivery series at CustomClanker.