Connecting to ClickFunnels: which integration should I use?

Which one do I use?

Find the row that matches what you are trying to do. If two rows look close, the surface named in the more specific row is the right one.

The four surfaces, and where each one runs

REST API v2 — your server calls ClickFunnels

The base layer, and the surface most integrations should use. Contacts and tags, orders and transactions, products and prices, subscriptions, funnels and pages, courses, communities, workflows, email broadcasts, opportunities, appointments, stats, webhooks, teams and workspaces.

There is no generic api. host. Workspace data always lives on the workspace subdomain:

https://{workspace-subdomain}.myclickfunnels.com/api/v2/...

Two auth models. An API access token, created inside a platform application under Team Settings → Developer Portal, is issued per team — it reaches every workspace on that team and every team admin can see it. Treat it as a team-wide secret. OAuth 2.0 is the path for acting on other users' accounts.

ClickFunnels documents a dynamic rate limit with a generous quota, but publishes no numbers. Plan for retries rather than for a specific ceiling.

Webhooks — ClickFunnels calls your server

Register an outgoing webhook endpoint through the API, then verify the HMAC signature on every delivery. Prefer this over polling for anything event-shaped: a purchase, an opt-in, a form submission, a course enrollment.

The Page SDK — a browser script for a page you host

The Page SDK makes a page on your domain behave like a native ClickFunnels funnel step: visit tracking, opt-in capture, contact and visit identity carried across funnel steps on different domains, and checkout — products, order bumps, and one-click one-time offers.

The entire public surface is a script tag, a meta tag carrying a page token, and data-cf-element attributes on your form fields:

<script src="https://sdk.myclickfunnels.com/sdk.js" defer></script>
<meta name="cf-page-token" content="cfp_...">

The page is registered either through the funnel builder's External page step or by creating an external page via the REST API, which returns the cfp_ token. External SDK pages are in closed alpha — see status and gating before you plan work around this.

The MCP server — an AI assistant acting for one person

ClickFunnels runs an MCP server that lets an AI assistant read and change a workspace on a signed-in human's behalf. Auth is interactive OAuth; it is user-scoped, and the workspace is scoped per call. It is a layer over the same API the REST reference documents, so it unlocks no capability the REST API lacks — what it removes is the need to hand-maintain a tool wrapper.

Two things worth knowing before you plan around it. It requires a ClickFunnels Scale plan and is offered as a Labs / technical preview. And as of this page's verification date it is not documented on ClickFunnels' public developer site at all, so there is no published contract to build against.

"SDK" does not mean what you probably think

This is the single most expensive misunderstanding in ClickFunnels integration work. A developer searching for "the ClickFunnels SDK for Node" finds a browser tag for externally-hosted pages and an unofficial npm package, with nothing telling them that ClickFunnels publishes no server-side client. If that is what you came here for: you want the REST API.

Community and no-code tooling does exist and is genuinely useful — n8n, Activepieces, Pipedream, and Zapier all ship ClickFunnels connectors. Use them as connectors, not as an API client you build a product on.

What each surface cannot do

This is the part that saves you a week.

• The REST API cannot take a payment. There is no "charge this card" endpoint for a checkout UI you built. Selling from your own page means the Page SDK.
• The Page SDK cannot run server-side. It is browser-only, tied to one specific registered page, and it owns form submission on that page.
• The Page SDK cannot see shadow DOM. Fields inside a web component's shadow root are invisible to it — and because it cannot see them, it cannot warn you either. Use plain HTML forms in the regular DOM.
• MCP is not a multi-tenant integration path. Consent is granted per workspace by a human inside their own AI assistant. If you are building a product that acts for many ClickFunnels users, that is REST plus OAuth 2.0.
• MCP consent is all-or-nothing. There is no read-only mode and no per-tool scoping. Approving the connector approves everything for that workspace.

Status and gating: what you can actually use today

Authentication at a glance

What this means for an Overskill app

An Overskill app is already an externally-hosted page running on its own domain, with its own forms, its own database, and its own auth. That is precisely the shape the Page SDK was built for — the SDK's whole premise is a page the funnel does not host.

The supported path today: the built-in ClickFunnels integration

Every Overskill app can talk to a connected ClickFunnels workspace over the REST API without your app holding a credential. You connect ClickFunnels once from your app's chat; the platform holds the connection and makes the call. No API key, no OAuth application, no environment variables, and nothing to rotate.

What the built-in integration covers:

• Create or update a contact by email, with names, phone, and custom fields.
• Apply and remove tags by name, creating the tag if it doesn't exist. Tagging is additive — existing ClickFunnels tags are never removed.
• Look up a contact and list the workspace's tags.
• List courses and enroll a contact in one.
• Receive ClickFunnels webhooks — the platform verifies the signature and de-duplicates retries, then forwards each event to a handler in your app.

Contact upsert and tag-apply work for logged-out visitors, which is what makes an opt-in form or a quiz work at all. The rest require a signed-in user. The public lead-capture path is rate-limited per workspace per day.

Ask the AI in your app's chat to wire this up, and click Connect ClickFunnels on the card it shows you. If the integration isn't available on your account yet, it will tell you rather than guess.

When to escalate off the built-in integration

Reach for the ClickFunnels REST API with your own credentials when you need something the built-in integration doesn't cover: orders and fulfillment, building pages or funnels, or reading data that isn't contacts, tags, or courses. Connecting to the ClickFunnels API walks through both the API-key and OAuth paths, including where the workspace subdomain and workspace ID come from.

Gotchas that bite everyone

• There is no generic API host. Every workspace call goes to that workspace's own subdomain.
• A webhook's signing secret is returned once, at creation. It cannot be read back.
• One SDK page token per page. Sharing a token between pages fails silently.
• A registered SDK page URL must match exactly — origin and path. A mismatch means submissions are rejected.
• The meta tag identifies the SDK page, not the URL. A single-page app has to update the tag's content on every route change.
• SDK checkout and form submission fail until the page is a funnel step. Before that they return page_not_in_funnel.
• Writing page markup replaces the whole page tree, and PML covers only a subset of what the visual editor can build. Get explicit approval before overwriting a page someone may have edited in the builder.
• Contact upsert will not clear a field. Matching is on email; passing an empty value or an empty tag list does not null anything out. Use the update-contact endpoint for that.
• An API token's reach is wider than it looks. It is issued per team, spans every workspace on that team, and is visible to every team admin.