The integration is listed on the website and it still doesn't work

The logo on an integrations page tells you one thing: someone has written a connector against some version of that vendor's API. It does not tell you which version, which endpoints are covered, whether your plan tier exposes the scopes you need, or whether the docs match live behaviour. This is a recurring complaint from people who build these flows for a living. One builder on r/n8n listed the walls they hit rebuilding a single sub-account user creation flow, listed one per line: 'n8n: Trying to rebuild. Hit every possible API issue:' / 'v1 API keys → Support ending' / 'v2 API keys → "Insufficient scopes" errors' / 'Private Integration Token → Sub-accounts work, user creation fails' / 'Different endpoints → Mixed results' / 'GHL docs → Outdated/confusing'. Read that as a project plan and it is four unplanned investigations: an auth migration, a permissions problem, an endpoint-coverage problem and a documentation problem. None were visible when the connector was chosen. That builder was rebuilding their own flow after Zapier's monthly cost climbed, but the same four investigations land inside the timeline when a supplier has quoted the job as connecting A to B. The connector list is a marketing artefact. The API is a moving product with its own roadmap, deprecations and rate limits, and your flow sits downstream of all of it.

Five failure classes account for most of the stalled builds described in these threads. API version churn: v1 keys deprecated, v2 keys behave differently, discovered mid-build or months later when the flow silently dies. Scope and permission gaps: insufficient scopes, admin-only endpoints, plan-tier limits, found on the first real auth attempt. Partial endpoint coverage: read works, write does not, found when you try the step that matters. Stale or wrong docs: documented field names differ from live responses. Non-functional plumbing: retries, rate limits, error logging and idempotency, which surface under production volume rather than in testing. That last class is the one left out of quotes most often. As one r/n8n post put it: "This isn’t just a Google Sheets integration. We’re talking about 7 different APIs such as booking systems and passport verification. Even with tools like n8n someone still has to handle authentication retries rate limits and error logging. These things aren’t plug and play." Authentication retries, rate limits and error logging are the difference between a flow that runs on demo day and one that runs in month four when the vendor throttles you.

Even when the connection works, the flow can still fail, because a flow is only as good as the records moving through it. A builder on r/zapier described the underlying condition: "Unless your client is unusually organized, their data is a mess. If they’re early-stage, it’s even worse." And what that does to a job: "You quote a simple flow. Then spend three days cleaning spreadsheets, reverse-engineering broken fields, and discovering their 'CRM' is a bunch of Google Docs and chaos." If your CRM is a shared drive, a spreadsheet and one person's memory, an integration has nothing stable to write to. There is no reliable unique key, so the same customer arrives three times under three spellings. Fields are populated when someone remembered. Free-text notes carry meaning that should have been structured. If your systems of record were never designed, cleaning them is the project, not a prerequisite you wave through so the real work can start. Deciding what a customer record is, which system owns it, what makes it unique and which fields are mandatory is the work. The connector is the easy half.

Because the quote is written against the visible surface and the cost sits in the invisible one. A quote for syncing website enquiries into the CRM and notifying the team describes three steps. The actual job includes confirming the API version and plan tier, obtaining credentials with the right scopes, discovering how many duplicate contacts the CRM holds, agreeing a deduplication rule, deciding what happens when a required field is empty, building retry and alerting behaviour, and testing against real messy records rather than clean test data. None of that is scope creep in the dishonest sense. It is discovery that was never funded, so it gets absorbed by whoever is cheapest to blame. The predictable outcome is a half-finished build and a manual step that survives intact. The same r/n8n post put it plainly: "Still manually creating users. We're 50% automated." Half automated is often worse than not automated, because now there is a system to maintain and a human step nobody has documented.

A discovery is a short, paid, fixed-scope investigation that ends in a written quote you can trust. Run it against the real accounts and the real data, not a sandbox. At minimum it should prove six things. One, auth works all the way through, using real credentials and scopes on the actual plan tier, with the API version and any scheduled deprecation confirmed. Two, the required endpoints exist and are writable, including create, update and the specific sub-objects the flow needs. Three, field-level data quality: for every field the flow depends on, how many records have it populated, in what formats, with what junk values. Four, record uniqueness: how many duplicates exist today, what the matching key will be and what happens on collision. Five, volume and failure behaviour against published rate limits, including what should happen when a call fails at 2am. Six, the exception path: what the humans do with records the flow cannot handle. If the answer is that your data needs cleaning up first, that is a useful result to buy, and far cheaper before the build than during it.

That is a fair objection and it is sometimes true. Plenty of vendors have rebadged a scoping call as paid work and delivered a slide deck. The test is whether the discovery produces artefacts you keep and could hand to a different supplier: a working authentication test, a list of endpoints verified against your account, a field-level data-quality report, a duplicate count with a proposed matching rule, and a fixed-price quote for the build. If it produces only a proposal, you bought a sales call. The other fair objection is that some integrations really are simple, and paying for discovery on a two-step flow between two well-documented modern APIs is overkill. That is correct. Scale the discovery to the risk. The signals for a full one are more than two systems, a legacy or trades-specific tool, an API you have never authenticated against, or a system of record nobody designed.

Whoever will be standing there when the vendor deprecates the API. That is the argument for capability transfer over a retainer. API churn is permanent. Scopes change, endpoints get versioned, and field meanings drift as the business changes its process. If the only person who understood why the deduplication rule exists left with the invoice, the flow becomes undebuggable the first time it breaks, and it will break. The transferable skill is not node-dragging. It is diagnosis and process-mapping: reading an error and knowing whether it is auth, scope, rate limit or bad data; knowing what a record is and which system owns it; being able to open the logs. Two or three of your own staff with that skill will outlast any connector.

Does a connector on a vendor's integrations page mean my flow will work? No. It means an API exists and someone has written a connector against some version of it. Your plan tier, required scopes, writable endpoints and rate limits are all separate questions. Verify auth against your real account before anyone quotes the build. Why do integration quotes blow out? Because the quote prices the visible steps and the cost sits in the invisible ones: auth migrations, scope errors, undocumented field behaviour, duplicate records and missing data. That work is real and unavoidable. When it is not funded up front it gets absorbed mid-build, which is where timelines fail. Should we clean our data before starting an integration project? Cleaning is usually the project, not a prerequisite. Deciding what a record is, which system owns it, what makes it unique and which fields are mandatory has to happen before any flow can be reliable. Fund it as scoped work rather than assuming it happens for free. What should a paid discovery deliver? A working authentication test on your real account, a list of verified endpoints, a field-level data-quality report, a duplicate count with a proposed matching rule, an exception-handling plan and a fixed-price build quote. If you only receive a proposal document, you bought a sales call. Is this problem specific to Australian businesses? No. The complaints quoted here come from global builder communities, and API churn and messy systems of record are universal. Australian businesses often add trades and finance tools such as ServiceM8, simPRO, Tradify, Xero and MYOB, each with their own API constraints worth verifying individually. Why does the manual step never disappear? Because the build stalls partway and the human fills the gap. A half-finished flow leaves a system to maintain plus an undocumented manual step. Either finish the flow including its exception path, or decide deliberately which records stay manual and write that down.

Quotes are reproduced verbatim from public Reddit threads and attributed to the subreddit, not to individuals. r/n8n: https://www.reddit.com/r/n8n/comments/1pz5hha/help_ghl_subaccount_user_creation_automation/ and https://www.reddit.com/r/n8n/comments/1mzurpv/enough_customers_no_devs/. r/zapier: https://www.reddit.com/r/zapier/comments/1mfvdpa/everything_youtube_gurus_didnt_tell_you_about/. No statistics are cited in this article. Where evidence is described as a recurring complaint, that reflects repeated reports in these communities, not a survey.