Store connection blocked by Cloudflare, a WAF, or a security plugin

Webanto calls your store from our servers, not from a browser. Bot-protection products classify server-to-server traffic as automated — which it is — and some are configured to challenge or block it. When that happens, Webanto never reaches your store's software at all.

This is not a credentials problem. The tell-tale sign is that your API keys work perfectly when you test them from your own computer, but fail from Webanto.

Symptoms

• A connection test fails at the Site reachable stage with HTTP 403
• The result mentions a response came from cloudflare rather than your application, often with the page title Just a moment...
• Product sync never completes, and Last full reconcile stays at Never
• Nothing appears in your site's own error logs, because the request never arrived

Why it happens

A bot challenge asks the client to run JavaScript and solve a browser check. A real browser passes it invisibly. An API client cannot execute JavaScript at all, so it fails the challenge and receives a 403.

Two consequences that surprise people:

• A "managed challenge" is not gentler than a block. For API traffic the two are identical — both result in a 403.
• Search engines are usually unaffected. Googlebot and Bingbot are handled as verified bots, a separate category. A rule blocking automated traffic will stop Webanto without touching your search rankings.

How to identify Webanto's requests

Webanto reads /wp-json/ itself, unauthenticated, as its first check. That request confirms your site is reachable before any credentials are tried — so any allow rule must cover /wp-json/ itself, not just the sub-paths.

Fix: Cloudflare

If you use Super Bot Fight Mode (Pro plan and above), add a WAF custom rule.

Security → WAF → Custom rules → Create rule

Set the expression to:

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

Then choose action Skip, and tick All Super Bot Fight Mode Rules.

You can leave your bot protection set to Block or Managed Challenge for everything else. Only requests identifying as Webanto, and only on your REST API path, are exempted.

Four mistakes that make the rule silently do nothing

1. Choosing the field "URI Query String" instead of "URI Path." The query string is only the part after the ?. A path can never appear in it, so the rule matches no requests at all. This is the most common error.
2. Scoping the path to /wp-json/wc/v3/ only. That misses the /wp-json/ reachability check, so the connection test still fails at its very first stage.
3. Placing the rule below another custom rule that blocks first. Custom rules are evaluated in order — move the skip rule to the top.
4. Using the free plan's Bot Fight Mode. It does not run on Cloudflare's Ruleset Engine, so Skip, Bypass, and Allow actions have no effect on it whatsoever. Your options there are to disable Bot Fight Mode under Security → Bots, or upgrade to a plan with Super Bot Fight Mode.

Confirming Cloudflare is the culprit

Open Security → Events and filter to the last hour. The Service column names the exact product that acted — Bot Fight Mode, Super Bot Fight Mode, Managed Rules, or a custom rule. If no matching events appear at all, Cloudflare is not blocking you and the cause is at your origin.

Fix: Wordfence

In Wordfence → Firewall → All Firewall Options, add Webanto under allowlisted user agents, or allowlist the REST API path from blocking rules. Check Wordfence → Tools → Live Traffic to confirm whether Wordfence is the component blocking the request.

Fix: your host's firewall

Managed WordPress hosts frequently run ModSecurity or Imunify360. These block at the server, so nothing appears in Cloudflare or Wordfence. Ask your host to allow requests to /wp-json/ from the Webanto user agent, and to check their ModSecurity audit log for the rule ID that fired.

Verifying the fix

Open the integration's settings page in Webanto and press Test Connection. The test runs three stages in order, and which one fails tells you where the problem is:

All three green means scheduled syncs and background jobs will reach your store too — the test uses exactly the same credentials and network path they do.

Is allowing Webanto through safe?

The rule above removes only the bot challenge, and only for requests identifying as Webanto on your REST API path. It does not grant access to anything.

Your store still authenticates every request independently: WooCommerce validates the consumer key and secret, WordPress validates the application password. Someone copying the user agent gains the ability to reach an endpoint that will then reject them for having no credentials.

Webanto's product sync is also strictly read-only. Content is written back to your store only when you explicitly choose to push it.