Cloudflare Setup for WooCommerce + IGFirstERP Sync (No 403 Errors)

Problem #

Many WooCommerce businesses turn on too many Cloudflare protections at once. The site looks secure, but IGFirstERP stock and order sync starts failing with blocked responses.

A common failure pattern is:

• Woo API call returns HTTP 403
• Response is not valid JSON
• ERP logs show JSON ERROR: Syntax error
• Stock sync jobs retry and queue pressure increases

Who this is for #

• Founders running WooCommerce with IGFirstERP
• Operations teams managing stock sync reliability
• Technical support teams configuring Cloudflare rules

Prerequisites #

• WooCommerce store is live behind Cloudflare
• IGFirstERP Woo integration is active
• You can edit Cloudflare WAF, Rate Limiting, and Cache Rules
• You can test Woo API health from ERP after rule changes

Steps #

In simple terms #

Cloudflare should filter abuse, not block business traffic. If Cloudflare challenges real API calls, IGFirstERP gets HTML challenge pages instead of JSON, and sync breaks.

1. Why this 403 + JSON syntax error happens #

IGFirstERP Woo sync jobs expect JSON responses from Woo endpoints. When Cloudflare blocks or challenges these calls, the response body can become HTML. ERP then logs JSON parse failures like JSON ERROR: Syntax error with HTTP 4xx/5xx.

2. Keep these controls ON (Do This) #

3. Keep these controls OFF (Avoid This) #

4. Free-plan-safe Cloudflare expressions (step cards) #

These expressions avoid the matches operator and work on free plans.

(http.host eq "example.com" or http.host eq "www.example.com")
and not cf.client.bot
and (
  starts_with(lower(http.request.uri.path), "/.env")
  or starts_with(lower(http.request.uri.path), "/.git")
  or starts_with(lower(http.request.uri.path), "/.svn")
  or lower(http.request.uri.path) eq "/wp-config.php"
  or lower(http.request.uri.path) eq "/phpinfo.php"
  or lower(http.request.uri.path) eq "/composer.json"
  or lower(http.request.uri.path) eq "/composer.lock"
  or lower(http.request.uri.path) contains "/vendor/"
)

(http.host eq "example.com" or http.host eq "www.example.com")
and not cf.client.bot
and (
  lower(http.request.uri.path) eq "/wp-json/wp/v2/users"
  or starts_with(lower(http.request.uri.query), "author=")
  or lower(http.request.uri.query) contains "&author="
  or lower(http.request.uri.query) contains "rest_route=/wp/v2/users"
)

(http.host eq "example.com" or http.host eq "www.example.com")
and (http.request.method in {"GET" "HEAD"})
and (
  starts_with(lower(http.request.uri.path), "/shop")
  or starts_with(lower(http.request.uri.path), "/product-category/")
)
and (
  lower(http.request.uri.query) contains "min_price="
  or lower(http.request.uri.query) contains "max_price="
  or lower(http.request.uri.query) contains "orderby="
  or lower(http.request.uri.query) contains "filter_"
  or lower(http.request.uri.query) contains "s="
)
and not cf.client.bot
and not (lower(http.request.uri.query) contains "wc-ajax=")
and not (http.cookie contains "wordpress_logged_in_")
and not (http.cookie contains "woocommerce_items_in_cart")
and not (http.cookie contains "woocommerce_cart_hash")

(http.host eq "example.com" or http.host eq "www.example.com")
and (
  starts_with(lower(http.request.uri.path), "/wp-admin/")
  or lower(http.request.uri.path) eq "/wp-login.php"
  or starts_with(lower(http.request.uri.path), "/cart")
  or starts_with(lower(http.request.uri.path), "/checkout")
  or starts_with(lower(http.request.uri.path), "/my-account")
  or lower(http.request.uri.query) contains "wc-ajax="
  or lower(http.request.uri.query) contains "add-to-cart="
)

(http.user_agent contains "WooCommerce")
or (http.user_agent contains "wc-ios")
or (http.user_agent contains "wc-android")

Security note: user-agent exceptions are convenience controls. Keep them narrow, monitor logs, and do not broaden skip scope unless a tested business flow requires it.

5. Optional Pro/Business upgrades #

• Bot score-driven traffic handling
• Finer endpoint-level WAF tuning with advanced expressions
• More granular catalog abuse controls for very large stores

Apply these only after the free-plan-safe baseline is stable.

6. If sync breaks, recover in 5 minutes #

1. Pause new security experiments immediately.
2. Disable the newest WAF or rate-limit rule first.
3. Confirm Woo API endpoints return JSON, not challenge HTML.
4. Run a small IGFirstERP stock sync test.
5. Check logs for repeated HTTP 403 and JSON syntax errors.
6. Re-enable protection gradually with tested exceptions.

7. ERP sync allowlist note #

For strict allowlist designs, do not hardcode public docs with a fixed production IP. Use this placeholder and confirm current values with support:

<IGFIRST_SYNC_EGRESS_IP>

Common mistakes #

• Turning on many Cloudflare controls at once without staged testing
• Protecting API and checkout routes with generic challenge policies
• Caching dynamic Woo pages to improve speed
• Not validating response body type after WAF changes
• Assuming storefront page loads means sync traffic is healthy

Verification checklist #

• Woo dynamic routes bypass cache
• WAF and rate-limit rules are targeted, not blanket
• IGFirstERP sync test updates stock successfully
• No fresh 403 + JSON ERROR: Syntax error entries after rollout
• Checkout, cart, login, and account flows remain normal

Escalation #

Escalate to IGFirstERP Support if:

• Blocked non-JSON sync failures continue after rollback
• Queue failures continue after disabling recent Cloudflare rules
• You need strict IP allowlist enforcement with current confirmed egress values

Related workflow links #

• Fixing Stock Mismatches (Daily Reconciliation)
• Preventing Website Stock Issues from Transfers
• Founder Weekly Control Reports

CTA #

Book an Operations Fit Call

View Pricing

Last reviewed #

2026-03-12

Review cadence: every 45 days or immediately after a Cloudflare-related sync incident.