Firewall and security plugin conflicts

WordPress security plugins routinely block requests to /wp-json/* by default because that endpoint is a common attack surface. Hubbee uses exactly that endpoint to talk to your site, so a default-config Wordfence install will silently break the connection. The fix in every case is to add an allowlist rule for /wp-json/bz/v1/* — Hubbee’s namespaced subset, not the entire REST API.

How to recognise the problem

The Hubbee dashboard shows your site as Offline within 15 minutes of activation, and the Run diagnostic button on the Connect step reports one of:

• wordfence_blocked — Wordfence challenge or lockout page in the response body
• rest_api_blocked — HTTP 403/406 on /wp-json/ with a vendor-branded body
• unreachable — request times out (Sucuri sometimes silently drops)

If you have access to the WP-Admin → Hubbee → Diagnostics panel, the Self-Test card runs the same probes locally.

Wordfence

1. WP-Admin → Wordfence → Firewall → All Firewall Options
2. Scroll to Allowlisted URLs
3. Add: */wp-json/bz/v1/*
4. Save. Wait 60 seconds, then click Retry connection in Hubbee.

If you also see “Locked out” notices in Wordfence → Tools → Live Traffic:

1. Wordfence → Tools → Live Traffic
2. Filter by IP-or-user. Find any blocked entry whose URL starts with /wp-json/bz/.
3. Click Unblock and add the source IP to Allowlisted IP Addresses (Wordfence → Firewall → All Firewall Options → Allowlist IP addresses).

Hubbee’s request sources are documented at https://hubbee.io/legal/datenschutz under “Infrastructure providers”. The set is small and stable — once whitelisted, it does not rotate.

Sucuri

Sucuri WAF blocks REST calls from IPs not on its allowlist. Two-step fix:

1. Sucuri Dashboard (cloud panel) → Settings → Whitelist → add Hubbee infrastructure IPs (from the privacy policy link above)
2. WP plugin → Sucuri → Settings → API → Reset API key if the connection still fails after the IP whitelist. Sucuri caches block state for ~15 minutes.

iThemes Security (now “Solid Security”)

1. WP-Admin → Security → Settings → Advanced → Hide Backend → Disable (or change the slug — see below)
2. Security → Settings → REST API → Default Access → Available to everyone (the Restricted access preset blocks our endpoint)
3. If you keep Hide Backend enabled with a custom slug, you must also map the slug for REST so /wp-json/bz/v1/* continues to resolve. See iThemes docs for the slug-aware REST workaround.

All In One WP Security & Firewall

1. WP Security → Firewall → Disable trace and track (leave Disable WP REST API off — this is the most common silent block)
2. Firewall → 6G Firewall Rules → Enable is fine; the 6G ruleset does not block /wp-json/* patterns.
3. Firewall → Brute Force → Login Captcha is fine; CAPTCHA does not affect REST.

Cloudflare Bot Fight Mode

Cloudflare’s Bot Fight Mode interprets Hubbee polling as bot traffic and serves a challenge page. See the dedicated Cloudflare setup article — the fix is a Skip rule on the /wp-json/* path.

What the allowlist rule actually does

*/wp-json/bz/v1/* allows:

• Hubbee’s outbound calls (POST /wp-json/bz/v1/push, GET /wp-json/bz/v1/status, etc.)
• All other /wp-json/* namespaces (/wp/v2/*, /wc/v3/*, …) remain protected by your security plugin’s default rules.

This is the least-privilege allowlist — narrower than whitelisting all of /wp-json/*. If your security plugin only supports IP-based allowlisting (no URL pattern), use the Hubbee IP set from the privacy policy and combine it with a host-level wp-json rule for defence-in-depth.

When you still cannot connect

Run WP-Admin → Hubbee → Diagnostics → Self-Test with the offending plugin temporarily disabled. If the self-test now succeeds:

• Re-enable the security plugin
• Re-run the self-test — confirm it now fails
• Identify which exact setting flipped the result by toggling rules one at a time

If you cannot disable the security plugin (managed hosting, production constraint), email info@hubbee.io with the failed self-test output. We have working configs for most major security stacks.