Skip to main content

LeadConnector Connection Troubleshooting SOP

Overview​

  • What: Diagnose and fix the failure mode where the LeadConnector WordPress plugin reports the site as connected (and the OAuth handshake completes) but the plugin admin is stuck on the "Your website is now successfully connected" onboarding splash — clicking Continue loops back to the splash, the Funnels / Forms / Dashboard tabs never load, and funnel pages embedded via the plugin go blank.
  • When: Triggered by (a) the splash-loop symptom above, (b) the connection-health check in WordPress Setup SOP §5.4, or (c) a previously-working funnel embed suddenly serving an empty page.
  • Who: Implementation lead or WordPress technician. Requires WordPress admin access, the GHL sub-account, and a browser with DevTools.
  • Time Required: 10–30 minutes depending on which step resolves it.

Prerequisites​

  • WordPress admin access to the affected site (<domain>/wp-admin).
  • Access to the GHL sub-account the plugin should be connected to (to disconnect/re-authorize).
  • A Chromium browser with DevTools (for the diagnostic signal below).
  • The LeadConnector plugin is installed and was previously authorized. (If it was never installed, run WordPress Setup SOP §5.4 first — this SOP doesn't cover first install.)

Diagnostic signal (the LeadConnector proxy validation calls)​

The plugin admin decides whether to show the dashboard or the onboarding splash based on two REST proxy calls it makes on load. These responses are the primary diagnostic — they tell you whether a "connected" plugin is actually healthy, without guessing.

Capture them: open DevTools → Network, tick Preserve log, reload the LeadConnector admin page, filter for proxy, click each request, and read the Response tab.

Proxy endpointKey fieldsHealthyMeaning
...proxy?endpoint=wp_validate_auth_stateis_connection_status_activetrueThe flag that gates the dashboard. If false, the plugin shows the onboarding splash regardless of stored credentials.
has_access_tokentrueA live OAuth access token exists. false = no working OAuth token (often a stale api_key-only state).
connection_methodoauthHow the plugin is authenticating. api_key with has_access_token:false is a degraded/half-connected state.
funnelFetchResponse.http_code200Result of the plugin's test fetch of the funnel list. A non-200 here (commonly 404) makes is_connection_status_active false even though credentials are stored.
...proxy?endpoint=wp_get_lc_optionshas_api_key, has_oauth_access_token, location_idset / correctThe credentials the plugin has stored, and which location it points at.

A healthy wp_validate_auth_state response looks like:

{ "is_connection_status_active": true, "has_connected_auth": true,
  "connection_method": "oauth", "has_access_token": true,
  "funnelFetchResponse": { "error": false, "http_code": 200 } }

The failure mode this SOP fixes looks like:

{ "is_connection_status_active": false, "has_connected_auth": true,
  "connection_method": "api_key", "authorized_location_id": "<LOCATION_ID>",
  "has_api_key": true, "has_access_token": false,
  "funnelFetchResponse": { "error": true, "http_code": 404, "from": "wp_remote_get_api" } }

Read this as: credentials are stored, but the plugin's test fetch of the funnel list fails (404), so it concludes the connection isn't truly active and throws you back to the splash. Both proxy calls return HTTP 200 themselves — the problem is the content, specifically funnelFetchResponse, not a blocked request.

Re-capture wp_validate_auth_state after each step below. Stop when is_connection_status_active flips to true.

Procedure (remediation ladder)​

Step 0 — Confirm the OAuth handshake actually completed​

After authorizing, the return URL contains &code=...&lc_code=.... If those params are present, the handshake itself worked and the problem is downstream (state/validation), not the login. If authorization never returns a code, the issue is the OAuth login itself — check third-party cookies (Step 2) first.

Step 1 — Bypass the splash directly​

Navigate to <domain>/wp-admin/admin.php?page=leadconnector-plugin&tab=dashboard, or click Dashboard in the left LeadConnector submenu. A healthy connection loads the dashboard at this &tab=dashboard URL; the splash is only the onboarding view. If it still shows the splash, continue.

Step 2 — Clear caches and cookies; rule out third-party-cookie blocking​

  • Purge the CDN cache (GHL hosting: CDN Cache button in the WP admin top bar) and any WP object cache.
  • Hard-refresh, then retry in an incognito window.
  • The connection handshake uses an embedded OAuth flow to app.leadconnectorhq.com (or the agency white-label domain); blocked third-party cookies break it. Test in a profile that allows third-party cookies.

Re-capture. If is_connection_status_active is still false, continue.

Step 3 — Disconnect, then re-authorize via OAuth to the correct sub-account​

This is the key step when the diagnostic shows connection_method: api_key / has_access_token: false. Fully disconnect the connection (from the plugin's connection menu, or revoke the WordPress integration from the GHL sub-account side if the splash blocks the menu), then run Authorize again and select the correct sub-account.

Goal: flip has_access_token to true and is_connection_status_active to true. A clean reconnect clears a half-saved api_key state.

Re-capture. If funnelFetchResponse.http_code is still non-200, continue.

Step 4 — Run the LeadConnector troubleshooter companion plugin​

If installed, leadconnector-wordpress-troubleshooter provides a built-in connection diagnostic. Run it and apply any fix it suggests, then re-capture.

Step 5 — Clean reinstall of the plugin​

Deactivate → Delete the LeadConnector plugin → reinstall the latest version → reconnect (Step 3). Deleting clears the plugin's stored options, which resolves a corrupted/stuck onboarding state.

Caveat: while the plugin is deactivated, any funnel pages it serves at WordPress URLs (e.g., /pricing) go blank/404 until you reconnect and re-map them. Schedule accordingly.

Re-capture. If still failing, escalate (below).

Gate: do not change Page Display Method on an unhealthy connection​

While is_connection_status_active is false, the Funnels → Edit Page dialog is unreachable, so the Page Display Method (Native HTML Embed vs iframe) cannot be changed. Restore the connection first; only then perform any Native HTML Embed switch. (Analogous to not submitting a 404 URL to Search Console.)

Verification​

The connection is healthy when all hold:

  • The LeadConnector dashboard loads at ...&tab=dashboard with the Funnels / Forms / Email tabs visible.
  • The Funnels list populates (not blank) — this is the real "connected" signal, not the green "Connected" label.
  • wp_validate_auth_state returns is_connection_status_active: true and has_access_token: true.
  • funnelFetchResponse.http_code is 200.

Escalation​

If Steps 0–5 don't flip is_connection_status_active to true — especially if funnelFetchResponse keeps returning 404 after a clean OAuth reconnect — the issue is on the GHL/account side (a 404 on the funnel fetch can indicate the connection lacks Funnels/Sites access, or the API call is being routed through the agency white-label domain rather than the LeadConnector API host). This is not a WordPress toggle. Open a HighLevel support ticket including:

  • The full wp_validate_auth_state response JSON (and wp_get_lc_options).
  • The location_id / authorized sub-account.
  • The summary: "funnel fetch returns 404 → is_connection_status_active false → onboarding-splash loop."
  • Steps already tried: cache + cookies cleared, WP REST API and leadconnector_api/v1 routes confirmed live, OAuth handshake completes (code/lc_code returned).

Pending vendor response, do not attempt funnel-embed changes — the connection must be healthy first.