Klaviyo Not Connecting To Woocommerce

Recently we were trying the Klaviyo plugin on one of our customer's WooCommerce stores, and it would not connect to Klaviyo. After debugging, we found that the site's Cloudflare protection was challenging or blocking the requests between the store and Klaviyo. Klaviyo's own help article lists the same cause: a firewall blocking Klaviyo's requests, or Cloudflare Bot Fight Mode being enabled, can produce the "We can't complete your setup" message (see Troubleshooting your WooCommerce integration, checked 3 October 2026).

This guide shows how to confirm that diagnosis first and how to fix it with the narrowest change that works. It does not guarantee a result: connection failures have other common causes too.

1. Confirm that Cloudflare is the cause

Do not change security settings on a guess. In the Cloudflare dashboard, open the security analytics events for your domain (Cloudflare documents this under Security > Analytics, Events tab) and look at what happened to the requests at the time you tried to connect. Requests challenged by Bot Fight Mode show "Bot Fight Mode" as the service, and rule matches show the rule that fired. If nothing was blocked, the problem is probably elsewhere (see step 4). Menu names change over time, so use Cloudflare's current documentation if your dashboard looks different.

2. Allow Klaviyo's integration traffic by IP address

Klaviyo recommends allowlisting its integration traffic IP addresses in your firewall, and publishes the current ranges in How to allowlist Klaviyo integration traffic IP addresses. Use that page for the values rather than copying them from a blog post, because Klaviyo notes the ranges may change over time. That page also says Cloudflare does not accept allowlisting /20 ranges, so the /20 range must be entered as individual /24 ranges, and that webhook traffic triggered by Klaviyo flows uses different IP addresses.

We no longer recommend our original approach of allowing requests by the user agent value alone. A user agent string is trivial for anyone to copy, so a rule that trusts it can let unwanted traffic past your protection. If you do use a user agent condition, combine it with the IP ranges rather than relying on it by itself.

3. Bot Fight Mode: understand the trade-off before changing it

Cloudflare's documentation states that Bot Fight Mode (the free option) does not use the ruleset engine, so custom rules with Skip, Bypass or Allow actions cannot exempt requests from it. Super Bot Fight Mode, available on paid plans, can be bypassed for specific requests using the Skip action in custom rules (see Bot Fight Mode and WAF feature interoperability).

Cloudflare also documents one other interaction: Bot Fight Mode can still trigger when an IP Access rule is present, but it does not trigger on a request that an IP Access rule matches first (see the Limitations section of the Bot Fight Mode page). That gives you these options, from narrowest to broadest:

• Confirm first. Check the security events to see whether the Klaviyo integration's own requests were actually challenged, and use the current ranges Klaviyo publishes rather than copied values.
• If your plan supports it, use Super Bot Fight Mode or Bot Management with a narrow Skip rule limited to Klaviyo's allowlisted IP ranges and to the specific store paths involved, instead of weakening protection for the whole site.
• If you are on the free Bot Fight Mode, Cloudflare's documented alternative to turning it off is an IP Access rule for the provider's published ranges, matched before Bot Fight Mode. An IP Access rule applies to the whole zone for those addresses and cannot be limited to particular paths, so it can have a wider security effect than a narrow Skip rule. Have whoever owns the site's security review it, note the ranges and the date you added them, and revisit it when Klaviyo updates its list. Do not assume a custom Skip or Bypass rule exempts the free Bot Fight Mode: Cloudflare says it does not.
• Turning Bot Fight Mode off is what Klaviyo's help article lists as a step. Treat it as a last resort and a temporary, deliberate security trade-off: write down the change, switch it off only for the time needed to complete the connection, then switch it back on and check that the integration keeps working. If it stops working again, plan a plan upgrade or a different protection design rather than leaving the site unprotected.

4. Rule out the other common causes

Klaviyo's troubleshooting article also points to these checks:

• The WooCommerce REST API key used by the integration needs Read/Write permissions (WooCommerce > Settings > Advanced > REST API).
• WordPress permalinks must not be set to "Plain" (Settings > Permalinks), because the WooCommerce REST API authentication needs pretty permalinks.
• Klaviyo expects the store URL to use HTTPS.
• Caching and redirect plugins can interfere with the setup, so Klaviyo advises disabling them while you connect.
• If webhook events are not reaching Klaviyo, some firewalls and security plugins block the DELETE method on /wp-json/ requests, which Klaviyo says should be allowed on /wp-json/wc/v3/webhooks/.

5. Retest the connection

After any change, purge the Cloudflare cache and any caching plugin cache, wait a minute or two, then try connecting again. Check the Cloudflare events again if it still fails, so you can see which setting is responsible. If you are still stuck, contact Klaviyo support with the exact error text, or contact us for help with the WooCommerce side.