Getting started

Firewalls, DNS and security products

Last modified:

1 September, 2026

In short: Kroconnect calls your store from its own servers, machine to machine. Anything that stands between the internet and your store — Cloudflare, a WAF at your host, a WordPress security plugin — has to let those calls through. Kroconnect identifies itself with the User-Agent Kroconnect, and it does not call from a fixed IP address.

Most integration problems that appear “out of nowhere” are of this kind. Nothing changed in Kroconnect and nothing changed in your store — a bot protection setting was switched on, a security plugin updated its rules, or your host tightened its firewall, and Kroconnect’s requests stopped arriving.

Why this happens

Kroconnect is not a browser and not a visitor. It is a server that calls your store’s REST API over HTTPS, reads JSON, and writes JSON back. It cannot run JavaScript, it cannot store cookies between attempts, and it cannot solve a CAPTCHA or a “prove you are human” challenge.

Bot protection is built on the assumption that a real visitor is on the other end and can be challenged. Kroconnect can’t answer such a challenge, so a challenge is the same thing as a block: the workflow fails, and the order, product or stock update it was carrying doesn’t go through.

How to recognise it

The clearest signal is a response that is HTML instead of JSON. Kroconnect’s requests always expect JSON back, so an HTML body in the logs means something in front of WooCommerce answered instead of WooCommerce.

The most common one by far is a Cloudflare challenge page, returned with status 403:

<!DOCTYPE html><html lang="en-US"><head><title>Just a moment...</title>
...
window._cf_chl_opt = { ... cRay: 'a33b173dc8e656d3', cType: 'managed', cZone: 'example.com', ...

Reading that page: Just a moment... is Cloudflare’s interstitial, cType: 'managed' means a managed challenge was issued, and cRay is the Ray ID of that specific event — keep it, it is the fastest way to find the rule that fired (see Find out which rule blocked the request).

Other symptoms with the same underlying cause:

What you see in the logs	Usually means
`403` with an HTML body — Just a moment…, Attention Required, Access Denied, Forbidden	A challenge or a WAF rule, at Cloudflare or at your host.
`403` with a short JSON or text body naming a plugin	A WordPress security plugin blocked the request.
`401` on brand new, correct credentials	The authorization header was stripped before it reached WooCommerce — by a security plugin, or by a redirect between `http`/`https` or `www`/non-`www`.
`429`, or failures that come in bursts during busy periods	Rate limiting is counting Kroconnect’s calls as an attack.
`503` with an HTML body	Under Attack mode, or the host’s WAF.
Nothing at all — the run fails before any HTTP status	The store isn’t reachable: DNS, an IP allowlist, HTTP authentication, or a firewall that drops the connection.
Works sometimes, fails at other times	Almost always bot protection or rate limiting — a fixed misconfiguration fails every time, a challenge fails intermittently.

See Searching the logs for a product for how to find the run and read the response body Kroconnect received.

How to identify Kroconnect’s requests

When you or your host need to write a rule, this is what the traffic looks like:


User-Agent	`Kroconnect`
Protocol	HTTPS to your store’s public address, the same one on the Connection’s Endpoint.
Paths	`/wp-json/wc/v3/…` (the WooCommerce REST API) and `/wp-json/kroconnect/…` (added by the Kroconnect WooCommerce Connector).
Authentication	WooCommerce consumer key and secret.
Source IP	Not fixed. See below.

There is no IP address to allowlist

Kroconnect runs on cloud infrastructure without a static outbound IP, and the addresses change without notice. An IP allowlist is therefore not a workable way to let Kroconnect in — a list that works today will silently start blocking next week, and the symptom will look exactly like the one you just fixed.

Write your rules against the User-Agent and the path instead. A rule scoped to /wp-json/ limits what it can ever expose, and the WooCommerce API key still has to authenticate on top of it — the rule decides who may reach WooCommerce, not who may read your data.

Cloudflare

Cloudflare is the single most common cause. In order of likelihood:

1. Bot Fight Mode / Super Bot Fight Mode. Under Security → Bots. This challenges anything it does not recognise as a browser, which includes every legitimate API client. It is the usual culprit behind the Just a moment… page. Either turn it off, or add the skip rule below — with Super Bot Fight Mode, make sure Definitely automated is not set to Block.

2. A WAF custom rule or managed ruleset. Under Security → WAF. Rules aimed at /wp-json/ or at WordPress in general catch Kroconnect along with everything else.

3. Rate limiting. A busy sync makes many calls in a short time, which can look like abuse. Exclude Kroconnect’s requests from rate limiting rules.

*4. Security Level set to I’m Under Attack. Under Security → Settings*. This challenges everything, and no API integration survives it.

The rule to add

In Security → WAF → Custom rules, create a rule with the action Skip:

(http.request.uri.path contains "/wp-json/" and http.user_agent contains "Kroconnect")

Set it to skip All remaining custom rules, Super Bot Fight Mode, Rate limiting rules and Managed rules, and place it first in the rule order — Cloudflare evaluates custom rules top to bottom, and a skip rule below a block rule never runs.

Don’t cache /wp-json/. A cached API response makes Kroconnect read stale data — old stock levels, an order status that has already changed. If you have a page rule or cache rule covering the whole site, exclude /wp-json/ from it and set it to Bypass cache.

Find out which rule blocked the request

Take the Ray ID from the blocked response — cRay in the HTML above, a33b173dc8e656d3 in that example — and look it up in Security → Events in the Cloudflare dashboard. The event names the exact service and rule that fired, which turns guesswork into a single change. Events are kept for a limited period, so do this while the failure is recent.

WordPress security plugins

Wordfence, Solid Security (formerly iThemes), All In One WP Security, Sucuri, WP Cerber, NinjaFirewall and similar plugins all have settings that stop Kroconnect. What to check:

Blocking by User-Agent or “fake bot” detection. Add Kroconnect to the allowlist rather than removing the protection.
Rate limiting and login/404 lockouts. A sync that fetches many products in sequence can trip a threshold meant for scrapers, and the block then applies to whatever IP Kroconnect happened to use.
Country blocking. Kroconnect’s servers are not where your customers are. If you block by country, Kroconnect’s requests may originate from a country you have blocked — and because the IP is not fixed, the country can change too.
REST API restrictions. Some security plugins, and a number of “disable REST API” plugins, close /wp-json/ to anyone not logged in, or require a nonce. WooCommerce’s own key-and-secret authentication must keep working.
Stripping the Authorization header. This shows up as 401 on credentials you know are correct. It is also caused by redirects, so make sure the Endpoint on the Connection matches your store exactly, including https:// and www.

Two-factor authentication, admin-area hardening and login protection are all fine — they don’t touch REST API traffic. It is the firewall and bot-blocking parts that need the exception.

Your host, DNS and the server

Host-level WAF / ModSecurity. Many WordPress hosts run one, and its rules are not visible in the WordPress admin. If Cloudflare and your plugins are clear, ask your host to check their firewall log for blocks on /wp-json/ and to allowlist the Kroconnect User-Agent.
The store must be reachable from the internet. A local or staging site, a site behind HTTP authentication (.htpasswd), a maintenance-mode plugin, or an IP allowlist at the server can’t be called from outside.
DNS must resolve publicly for the domain on the Connection’s Endpoint, and point at the live store.
A valid TLS certificate, with the full chain. A certificate that a browser accepts can still fail server-to-server if an intermediate certificate is missing, because browsers work around that and API clients do not. Expired certificates fail immediately.
Don’t geo-block your own API. Same reasoning as above: Kroconnect does not call from your customers’ country.

Verify the fix

From any machine, make the same call Kroconnect makes and check that JSON comes back:

curl -i -A "Kroconnect" \
  -u "ck_your_consumer_key:cs_your_consumer_secret" \
  "https://example.com/wp-json/wc/v3/orders?per_page=1"

200 and a JSON body — the path is open.
403 and HTML — still blocked; the Ray ID in the response tells you by what.
401 and JSON — the request got through to WooCommerce, and it is the credentials that are the problem. See Connections.

Run the same command without -A "Kroconnect" as a control. If the plain call is challenged and the Kroconnect one is not, your exception works.

Then trigger a real run — send one order, or sync one product — and confirm in the app that the request to your store comes back 200 OK.

Before you contact support

Kroconnect can see the response your store returned, but not the rule that produced it — that is visible only from inside your Cloudflare account, your security plugin and your host’s firewall. Having these ready makes it quick:

the Ray ID from the blocked response, if it is a Cloudflare page;
who sits in front of the store — Cloudflare or another CDN, which security plugins are active, which host;
when it started, and what changed around then — a plugin update, a new Cloudflare setting, a migration.