The API Connection Reality: What Actually Plugs Into What

Every automation platform's marketing page has a number. Zapier says 6,000+ apps. Make says 1,800+. n8n says 400+. These numbers do real work in purchasing decisions. They shouldn't. The number of integrations a platform supports tells you almost nothing about whether it can do the specific thing you need with the specific app you use. It's like choosing a restaurant because it has 200 items on the menu — a menu that large is a warning, not a feature.

This article is about what "integration" actually means across the automation landscape, why the number on the marketing page is nearly useless, and how to evaluate whether a platform can actually do what you need before you've committed three hours to finding out the hard way.

What It Actually Does

An "integration" is not a binary thing. It's a spectrum, and the spectrum runs from "full API coverage with every endpoint, trigger, and action" to "we can read the name field from this app and nothing else." Most integrations live closer to the second end than the first, and the marketing page doesn't tell you which.

Let's break this into tiers, because the tiers are where the useful information lives.

Tier 1 integrations are deep, well-maintained, and cover most of what the underlying API can do. On Zapier, this is Google Sheets, Slack, Gmail, HubSpot, Salesforce — the apps that thousands of customers use daily. These integrations have dozens of triggers and actions, handle authentication cleanly, get updated when the API changes, and generally work the way you expect. Every platform has maybe 20-50 of these. They are the integrations the demos use, and they're genuinely good.

Tier 2 integrations are functional but limited. They cover the most common triggers and actions — maybe "new record created" and "update record" — but skip the endpoints you actually need. You can create a contact in the CRM but can't update a custom field. You can trigger on a new order but can't access line item details. These integrations work fine for basic use cases and become walls the moment your use case is specific. Most integrations on every platform are Tier 2. You'll discover this after you've chosen the platform and started building, which is the worst possible time to discover it.

Tier 3 integrations are the long tail — community-built, minimally maintained, or quietly abandoned. n8n's community nodes fall here, as do many of Zapier's less popular app connections. They might work. They might work today and break next month when the API changes and nobody updates the connector. They might have been built against a beta API that no longer exists. The listing page shows the app logo and a checkmark, same as Tier 1. There's no visual distinction between "battle-tested integration used by 50,000 customers" and "some developer built this over a weekend in 2023 and hasn't touched it since."

The practical consequence: before you choose a platform based on whether it lists your app, you need to check what the integration actually does. Go to the integration page. Read the specific triggers and actions. If the action you need isn't listed, assume it doesn't exist — because it probably doesn't, and "they'll probably add it" is a bet you'll lose more often than you'll win.

What The Demo Makes You Think

The demo makes you think that "connects to 6,000+ apps" means you can do anything with any app. It makes you think integration is a solved problem — just pick your apps, wire them together, and data flows.

Here's the reality behind the number.

A large percentage of those 6,000 apps are Tier 2 or Tier 3. They exist so the number can be 6,000. The actual set of apps with deep, reliable integrations is closer to 50-100 on any platform. The rest have a listing, a logo, and somewhere between one and five basic actions that may or may not cover your use case.

The demos never show you the integration that almost works. The one that lets you create a record but not with the fields you need. The one that triggers on "new item" but not "updated item." The one that reads data but can't write it back. These near-misses are more frustrating than outright missing integrations because you get halfway through building your workflow before you hit the wall.

And the demos never show you the HTTP/webhook fallback — which is what you actually use when the native integration doesn't cut it. Every platform has an HTTP request node or a webhook trigger. This is how you connect to apps that don't have native integrations, or fill in gaps where the native integration is too limited. It works. It's also just making raw API calls with a visual wrapper, which means you need to read API documentation, handle authentication manually, parse JSON responses, and manage error cases yourself. At that point, you're programming. You're just doing it in a less ergonomic environment than an actual code editor.

The HTTP fallback is the escape hatch that makes any platform technically able to connect to any API. But if you're using it for more than one or two connections in a workflow, you should ask yourself whether the automation platform is adding value or just adding a layer between you and curl.

Authentication: The Part That Actually Breaks

The integration listing doesn't tell you about authentication, and authentication is where integrations actually fail in practice.

OAuth flows are the standard for modern APIs, and they work fine — until the token expires. Most automation platforms handle token refresh automatically for Tier 1 integrations. For Tier 2 and 3, refresh handling is inconsistent. Your workflow runs great for 30 days, the OAuth token expires, the platform fails to refresh it, and your automation silently stops working. You find out when the output disappears. On Zapier, you'll get an email notification. On n8n self-hosted, you'll get nothing unless you've set up monitoring yourself.

API keys are simpler but have their own problems. Keys get rotated by security-conscious teams. Keys hit rate limits. Keys get revoked when someone leaves the company and their account gets deactivated. The automation stops, and unless you're watching, nobody notices.

The rate limit problem is particularly insidious. Most APIs limit how many requests you can make per minute or per hour. A workflow that runs fine at 10 executions per day might start failing at 100 because it's hitting the API's rate ceiling. The error messages for rate limiting are inconsistent across APIs — some return a clear 429 status, others return cryptic errors that don't obviously mean "slow down." Automation platforms vary widely in how they handle this. Some retry automatically with backoff. Some just fail and log an error. Some retry immediately, which makes the rate limiting worse.

The worst authentication scenario is the one that changes. If an API migrates from v1 to v2, or switches authentication methods, or deprecates an endpoint your integration uses, the integration breaks. For Tier 1 integrations, the platform usually updates the connector relatively quickly. For everything else, you're waiting on a community contributor or building a workaround yourself. The "it used to work" problem is the most time-consuming category of automation debugging because you're not building something new — you're forensically reconstructing why something that was working stopped, often with minimal error context.

How To Evaluate Before You Commit

There is a process for this, and almost nobody follows it because it's boring and the platform's marketing page is right there with its satisfying checkmarks.

Step one: list the specific apps you need to connect. Not "CRM" — the specific CRM. Not "email marketing" — the specific platform. Write them down.

Step two: for each app, list the specific triggers and actions you need. "When a new deal is created in HubSpot, create a row in Google Sheets with the deal name, amount, and close date." Not "connect HubSpot to Google Sheets" — the specific fields and events.

Step three: go to the integration page on each platform you're considering. For each app, check whether the specific triggers and actions you listed exist. Not whether the app is listed. Whether your specific use case is supported. If the integration page says "New Deal" as a trigger and "Create Spreadsheet Row" as an action, you're probably fine. If it says "New Contact" but not "New Deal," you're not.

Step four: for any gap, check whether the HTTP/webhook module can fill it. This means reading the target app's API documentation to confirm the endpoint exists, the authentication method is supported, and the data format is something the automation platform can handle. If you can't read API documentation, this step will feel impossible — which is useful information about whether you should be building this automation yourself.

Step five: search the platform's community forum for your specific apps. Look for recent posts. If the last post about your app's integration is from 2024 and says "this is broken," factor that into your evaluation.

This process takes 30-60 minutes and will save you 3-6 hours of building a workflow on a platform that can't actually do what you need. Nobody does it because it doesn't feel like progress. Building the workflow feels like progress. Evaluating whether you can build the workflow feels like overthinking. It's not.

The Platform-Specific Reality

Zapier has the most integrations by count and the most Tier 1 integrations by count. If your workflow uses popular, mainstream apps, Zapier is the safest bet for "it just works" connectivity. The tradeoff is that when a Zapier integration is limited, your only options are the HTTP module (decent but basic) or accepting the limitation. The per-task pricing also means that using the HTTP module for polling costs you tasks, which costs you money.

Make has fewer integrations but a significantly better HTTP module. The built-in JSON parsing, data transformation tools, and ability to chain multiple HTTP calls make Make the stronger choice when you know you'll be working with APIs directly. The operations pricing model also means HTTP calls aren't disproportionately expensive. [VERIFY: Make's current integration count relative to Zapier's]

n8n has the fewest native integrations but the most flexibility through community nodes and the HTTP Request node. If you're comfortable with JavaScript, you can build any integration yourself using the Function node. The self-hosted option means you can install community nodes that aren't available on n8n Cloud, which widens the effective integration library. The risk is that community nodes have no maintenance guarantees.

Pipedream sidesteps the whole integration model by letting you write code. If you can use the npm package for an API, you can integrate with it in Pipedream. This makes the "integration count" metric irrelevant but limits the platform to people who can write JavaScript or Python.

The Verdict

The number of integrations a platform supports is a marketing metric, not a technical one. What matters is whether your specific apps, with your specific triggers and actions, are supported at a depth that actually covers your use case. This is boring to check and essential to check.

Before you commit to a platform, do the evaluation. Check the specific triggers and actions, not the app logo on the integration page. Search the community forum for your apps. Test the authentication flow before you build the workflow around it. If the native integration is Tier 2 or 3, decide whether you're comfortable with the HTTP fallback for the gaps — and whether that's worth doing inside an automation platform versus just writing a script.

The honest truth about API connections in 2026: the popular apps work well everywhere. The less popular apps work inconsistently everywhere. And the long tail — the niche tools, the industry-specific platforms, the internal APIs — will always require manual HTTP configuration regardless of which platform you choose. Plan for that, and you'll choose more wisely.

This is part of CustomClanker's Automation series — reality checks on every major workflow tool.